Creating and learning

Over the last few days I've had a bit of time to think.

It's the holiday season and that's meant time to spend with family and friends.

My brain, however, can't help but continue to iterate on ideas.

Over the last year my friend and I have been discussing what it takes to make an idea functional. We launched our first app a few months ago, and loved the process of creating it.

We're in the middle of getting another app idea out, and have given ourselves a deadline to ship it. I'll share an update once that's ready.

We're trying to ship in cycles, getting as many in as possible.

Instead of putting all of our limited time into a single idea, we want to test small ideas and ship, learn and repeat.

That's led to a new idea. Well, candidly the ideas are endless, but with the nearing launch of our second app, I've come to believe we can actually ship, and so it's worth thinking ahead for where we'll go next.

For a long time I've wanted to build a game. I love games, still play them in my late thirties, and think often about the idea of making an interaction fun.

But the concept has been daunting.

I've built it up in my mind as this perfect thing that should exist, and haven't taken to heart the lessons learned from building software. Namely that we should break things down into vertical slices¹, learn from those, and iterate and repeat and learn and keep building.

So, with a challenge from Nathan I've started thinking about a game concept we could build.

I like roguelike (and roguelite) games, sim games, strategy games, and many other genres. In particular I'm a huge fan of Harvest Moon and Stardew Valley, along with games like Age of Empires and Civilization.

For years I've thought of building something along those lines, but with my own particular twist (but not necessarily original) inspired by an old game called SimAnt. I even discussed this game with my brother years ago and we talked about what it could look like.

But I'm not a developer, and so the idea sat.

Then today, I realized that I'm completely unblocked to take the concept and run with it. I can design it out (it's not with ants, but another animal responsible for reshaping its environment), and work with Nathan to create a prototype.

And so I've started doing just that.

All that's led into a whole other question we've been debating.

As founders, should we prioritize building great ideas and finding people to use them, or think more about building a wait list and validating use cases first?

Do we dogfood ideas, scratch our own itches, and build software that solves our problems, or do we test and see what the market wants, and react accordingly?

The answer is yes on both counts. And that's been a particular challenge worth wrestling with.

Both of us have experience creating products within teams, along with some experience of doing it on our own as well. But at this stage we have a single resource—our limited time—and we want to use that carefully.

And so we had a particular revelation—in a few days (hopefully) we'll have shipped two apps, representing a lot of evenings and tinkering with concepts over months. That's fantastic, and we couldn't be prouder. But, our user base will likely be measured in single or double digits.

That's probably fine, and we should definitely keep tinkering and testing new ideas.

But we've started to wonder if it'd be better to share ideas, see if they stick, and then build them out based on feedback from real people. That sounds like an obvious thing, and it's a concept I've heard about for years. But when it comes to the time we have to build, it's hard to pause and really think about what the market needs, versus trying to tinker away on the things we care about.

All that's to say—this stuff is really hard, but worth it. It's challenging in all the right ways, it stretches the mind and both creates opportunity and frustration.

So, we'll probably keep trying ideas, but we may also start focusing on asking what people want, and see if we can meet their needs.

1. Vertical slices are a concept I learned from building software, where you want to take a thin area of functionality within an app and make it work well, as opposed to trying to build out the entire app all at once.