How we decide what to build next

We get more ideas than we can build, which means the important skill is not generating ideas but discarding them. This is the filter we apply, written down partly so we hold ourselves to it.

Test 1: is there a problem we personally hit, repeatedly?

Every app we have shipped or started began as an annoyance one of us had on a specific day. Prayer reminders that arrived late. Preparing for an interview and realising that reading question lists was doing nothing. A household where the morning routine required the same three reminders every day.

This is not a rule that the founder is always the user. It is a rule about feedback quality: when you hold the problem yourself, you can tell within an hour whether a build is going in the wrong direction. Without that, you are guessing for months.

Test 2: can we describe it in one sentence a stranger would recognise?

If the description requires "and also" three times, it is not a product yet, it is a category. The sentence has to be something a potential user would read and think that is my problem, not that is an interesting idea.

We write the store listing before we write code. If the listing is boring to write, the app will be boring to use.

Test 3: who already solved this, and are they doing it badly?

"No competitors" is usually bad news — it typically means no demand. What we look for instead is a crowded space where the existing options share a specific, fixable flaw. Ad-saturated interfaces on something you use five times a day. A permission request that no reasonable person would grant. A setup flow that takes twenty minutes before any value appears.

If we cannot articulate the flaw precisely, we do not yet understand the market well enough to enter it.

Test 4: is the first useful version small?

We ask what the smallest thing is that a real person would keep on their phone. Not a demo — something they would be mildly annoyed to lose. If that version is six months of work, the idea is too big for us and we say so early rather than discovering it in month four.

Test 5: can it work without collecting things we would rather not hold?

Every piece of personal data is a liability with a maintenance cost and a breach risk. If a feature requires a permanent copy of something sensitive, we look hard for a design that keeps it on the device. Salah Companion's tracker is local-only for exactly this reason, and the trade-off — no cloud restore — is one we chose deliberately and document plainly.

Test 6: could we support it in three years?

A small team should not ship something whose ongoing costs grow faster than its usefulness. Anything with heavy per-user infrastructure, constant data licensing or a moderation burden gets serious scrutiny, because an abandoned app is worse for users than one that was never built.

What we do before committing

• Write the store listing and the one-sentence description.
• Sketch the first screen and the single action it should invite.
• Use whatever exists today for two weeks and write down every friction point.
• Estimate the smallest useful version in weeks. If it exceeds twelve, cut scope or drop it.

Ideas we have dropped

A shared family calendar, because the smallest useful version required syncing infrastructure and everyone already has one. A habit tracker, because we could not name a flaw in the existing options that we could actually fix. A finance tracker that required bank credentials, because holding those failed test five outright.

Dropping ideas is the part of the process that produces the good version of the ones we keep. If you have a problem you think we should be looking at, tell us through the contact page — several of the tests above are much easier to run with a real person on the other end.