How We Decide What to Build

The hardest part of running an independent studio is not building things. It is deciding what not to build.

Every yes is expensive. Say yes to the wrong idea and you do not just lose the weeks — you lose them while a better idea sits untouched. So before anything reaches a design file, it has to survive four questions.

1. Is the problem real, and does it come back?

Plenty of ideas describe a real problem that someone hits once. Those make bad apps. The person solves it, deletes you, and is right to.

We look for friction that recurs — weekly, ideally daily — and that people have already built a clumsy workaround for. A spreadsheet somebody maintains by hand, a note full of pasted links, a recurring calendar reminder doing a job it was never meant to do. Those workarounds are the strongest signal there is, because someone cared enough to solve the problem badly.

What we do not treat as evidence: our own enthusiasm, a competitor raising money, or a category being described as hot.

2. Can we do it properly?

This is the question that kills the most ideas, and it is the one we are most tempted to answer with optimism.

Some problems genuinely need scale — heavy real-time infrastructure, a content library that requires licensing deals, anything where the moat is operational scale. We can build a convincing version of those. We cannot build a good one, and we cannot maintain it for years, which is the part that actually matters.

So we ask a deliberately deflating question: what does this look like in year three, when it has real users and we are still working the way we work now? If the honest answer is “underwater,” we stop there.

This filter is stricter for us than it would be for a funded studio, and we have made peace with that. Some genuinely good ideas are not good ideas for Suncraft.

3. Can we be meaningfully better, not just different?

An existing competitor is not a reason to avoid a category. It is often a reason to enter one — it proves demand, and it means someone else already paid to educate the market.

But “we would do it too, slightly differently” is not a reason to build. We need a specific, defensible answer to why would someone switch, and it has to survive being said out loud:

• Faster in a way people can feel, not just measure
• Simpler, because we are willing to leave out what the incumbent cannot
• More respectful — no ads, no data resale, no engagement traps
• Better at the one thing most people actually open the app to do

Being small is a genuine advantage here. Established apps accumulate features they can no longer remove because some segment depends on each one. We have no such debt, and simplicity is the thing we can offer that a larger competitor structurally cannot.

4. Can it pay for itself, honestly?

We are self-funded, so every app has to eventually cover its own development and maintenance. That is a constraint, and constraints are clarifying.

It rules out the business models we would not want anyway. We will not run ads, and we will not sell data — which means the only honest options left are a one-time purchase or a subscription that keeps earning its price through ongoing work.

If we cannot see a version where enough people would happily pay for something, we take that seriously. An app people like but nobody will fund is a hobby, and hobbies do not get maintained for a decade.

Free apps are rarely free. Someone is paying, and if it is not the user, it is the user’s attention or the user’s data. We would rather just be told what something costs.

What happens to the ideas we kill

They go in a document. It is much longer than our roadmap, and we reread it every few months.

Ideas fail for reasons that expire. “Too expensive to build” changes when tooling improves. “No clear wedge” changes when an incumbent makes a bad decision. A few things on our current shortlist were rejected a year ago and came back stronger.

The discipline is not permanent refusal. It is refusing now, writing down exactly why, and being honest enough to revisit it when the reason no longer holds.

Where this leaves us

Our first app cleared all four. We are not ready to describe it yet, but we can tell you it targets a small daily friction with an ugly workaround, it is something we can own for years, its advantage is what we are leaving out, and it will cost money and say so plainly.

The next post is about what happens after an idea survives this — how we actually build, and what changes once code is involved.