Why we build small apps instead of one big one

We are a small studio, and we have deliberately chosen to ship several focused apps rather than one large one. People ask why, usually with the assumption that a single app with more features would be easier to market. Here is the actual reasoning, including the parts that are inconvenient for us.

A feature has to earn its place on a screen

Every feature you add costs something on the screens that already exist. A new tab pushes an old one into an overflow menu. A new setting makes the settings list longer for everyone, including the people who will never touch it. On a phone, that cost is unusually high — you have roughly one thumb, one column and a few seconds of patience.

When a prayer times app grows a habit tracker, a reading log and a community feed, the thing it was good at gets slower to reach. We have all watched an app we liked go through that.

Different apps have genuinely different users

Salah Companion is used by someone who wants to know when Maghrib is, today, in under two seconds. TrophyTykes is used by a nine-year-old who wants to see their trophies. Employ Ready is used by a nervous adult the night before an interview.

Those three people want different defaults, different tone, different notification behaviour and different amounts of hand-holding. A single app that serves all three serves none of them well; it becomes a settings screen wearing a trench coat.

Small apps fail small

This is the part nobody puts in a manifesto. Some of our ideas will not work. If a small app does not find its users, we can retire it, learn what we learned, and the other apps are unaffected. If a monolith's fourth module fails, it still sits in the codebase, in the navigation and in the release notes forever.

Separation gives us permission to try things that might not work — and most of the interesting things might not work.

The trade-offs we accept

We do not pretend this is free:

• More overhead. Five apps means five store listings, five review queues, five sets of release notes and five support inboxes.
• Harder cross-promotion. A user who loves one app does not automatically discover the others. Our website exists partly to solve that.
• Duplicated engineering. Settings, theming, notification scheduling and data export get built more than once. We keep a shared internal library, but it is not free.
• Slower total feature velocity. Context switching between products is real.

What "small" actually means to us

Small is not a line count. It is a constraint on the product's promise. Each of our apps should be describable in one sentence that a user would recognise as their own problem:

• Salah Companion: know when to pray, and be reminded reliably.
• Mindful Assistant: protect one block of attention at a time.
• Employ Ready: rehearse for one specific interview.
• Shariah Signal: understand whether a stock lines up with your values, and why.
• TrophyTykes: make household routines something children opt into.

When a proposed feature does not fit its app's sentence, it is either a different app or it is nothing. Most of the time, honestly, it is nothing — and that is the discipline the structure buys us.

What this means if you use our apps

It means the app you installed will keep doing the thing you installed it for. Updates will make that thing better rather than adding a module you did not ask for. And if we build something new, it will arrive as its own app you can choose to install, not as a tab that appeared overnight.