How We Build: The Suncraft Approach to Craft

An idea that survives our four questions is not a project yet. It is permission to start one.

What follows is the part people rarely write about, because it is less a methodology than a set of stubborn habits. Here is how we actually work.

We design the boring screens first

Most teams design the hero screen first. It is the fun one, it looks good in a portfolio, and it is the screen the app is about.

We start at the other end — the empty state, the error state, the offline state, the settings screen, the moment something fails halfway through. Those screens decide whether an app feels trustworthy, and they are almost always designed last, in a hurry, by someone who has run out of time.

Doing them first has a useful side effect: it surfaces the problems that would otherwise ambush you in week nine. If you cannot describe what happens when the network drops mid-action, you do not understand the feature yet.

A performance budget, enforced on old hardware

“Fast” is not a value unless it has a number attached, so ours does. Every app gets a budget, and every build is checked against it on a mid-range phone several years old — not on the newest flagship, and not on a simulator.

• Cold start to usable: under a second
• Any tap to visible response: under 100ms, always
• The main flow: completable without a single loading spinner

Testing on old hardware is the part that matters. Developers carry good phones, so performance problems are invisible to exactly the people who could fix them. Most of our users will not be on this year’s device, and the app should feel the same for them.

When a build breaks the budget, we do not add it to a backlog. We fix it before anything new goes on top, because performance regressions compound and get exponentially harder to trace the longer you leave them.

Native on both platforms

We build for iOS and Android, and we treat them as different places rather than one market with two export targets.

Shared-everything frameworks are a legitimate choice and we are not sniffy about them. But they tend to produce apps that are subtly foreign on both platforms — navigation that behaves almost right, gestures that stop half a pixel short, system integrations that lag a year behind. Users rarely articulate this. They just say it feels off.

So we share the logic and write the interface twice. It is slower, and at our size that cost is real — it is probably the most expensive decision on this page. It is also the difference between an app that runs on your phone and one that belongs there.

We ship less than we build

Not everything we build makes it into a release. Features get cut late, after they work, which feels wasteful and is the single most valuable habit we have.

A feature earns its place by being used, not by being finished. If in testing it turns out only we care about it, it goes — even at the cost of the weeks already spent. Sunk cost is the most expensive reason to ship something, because you do not just pay for it once; you maintain it, test around it, and design future features around its existence, forever.

Every feature we keep is one we personally maintain for as long as the app exists. That keeps us honest about what actually earns its place.

The apps we admire are notable for what they left out. That is hard to do, and it is only possible if you are willing to waste work.

What we will not ship

Some things never make it in, regardless of what they would do for the numbers:

• Ads. Ever.
• Analytics that follow you off our app. We measure whether features work. We do not build a profile of you.
• Notifications you did not ask for. No re-engagement pings, no “we miss you.”
• Rating prompts mid-task. Ask when someone has just succeeded at something, or do not ask.
• Subscription flows that are easier to enter than to leave. Cancelling should take the same number of taps as subscribing.

We are writing these down publicly because that makes them expensive to break. That is the point.

Then it launches, and the real work starts

A release is not the end of a project. Version 1.0 is the first honest conversation with people who did not build the thing, and it is usually a humbling one — the flow you agonised over is fine, and the thing you nearly cut is what everyone uses.

We plan for that. Our roadmap after launch stays deliberately empty for a while, so there is room to respond to what we learn rather than executing a plan written by people who had not yet met a single user.

Next: where this is all going — our roadmap, and what we are actually aiming at over the next few years.