From Product Idea to Production Across Every Screen

Take a product from idea to production in six stages, each with one question to answer and a piece of evidence that ends it. The order matters more than the speed: each stage exists to stop you spending money on the next one too early.

Stage 3 is listed third but starts on day one. It runs underneath everything else, which is why it has its own section below.

None of these stages names a framework. Native, Flutter, React Native, Kotlin Multiplatform and the web can each be the right answer, and the right answer falls out of stages 1 and 2. Choosing the stack first, then looking for a product that suits it, is the most common way to build the wrong thing efficiently.

Find the assumption most likely to sink the product and test it in the cheapest way that gives a clear answer. Every week spent building around an untested risk is a week you may have to throw away.

Product risk comes in four kinds:

• Desirability: will people want it enough to change what they do today?
• Feasibility: can it be built to the standard the job needs? An on-device model fast enough on a mid-range phone, a Bluetooth device that stays connected, a partner API that returns data in time.
• Viability: does the business work? Unit economics, acquisition cost, and for AI features the cost of each useful result.
• Compliance: can it legally operate? Financial, health and children's data each bring obligations that shape the architecture.

Rank candidate risks by likelihood × cost of finding out late. A feasibility risk in a core integration usually ranks high, because discovering it in month four can invalidate everything built on top of it.

Then pick the cheapest test that settles it:

Time-box every test and write the decision down. "We tested on-device inference on a three-year-old phone and it took too long, so the first release uses a hosted model behind a boundary" is a valuable outcome. It is also exactly the kind of decision that later stages need on record.

The smallest valuable release is one complete journey that a real user can finish, end to end, on the surface where they do the job. It is narrow, but it is not a demo: it has real sign-in, real data, error states and a release process you can repeat.

"Minimum viable product" has come to mean almost anything, so it helps to be precise. Complete beats broad. One journey that works from sign-up to outcome teaches you more than ten half-built features, because only a finished journey shows whether people come back.

A practical way to cut scope:

1. Write the journey as steps, from the moment the user arrives to the moment they get value.
2. Mark each step must-have, could-fake or later. Could-fake steps are handled manually behind the scenes for now: an operator approves sign-ups, a spreadsheet stands in for an admin panel.
3. Write acceptance criteria for the must-haves, including what happens when things fail: no network, an expired session, a slow API.
4. Add the invisible essentials: authentication, secure storage of tokens, crash reporting, analytics and a release pipeline. Leaving them out does not make the release smaller. It makes the second release much harder.

Choose the first surface by where the job happens, not by what you can announce. Field workers, consumers and drivers usually mean a phone app. Desk-based teams and buyers researching a purchase usually mean the web. If the job genuinely spans several surfaces from the start, that is the point to weigh a shared-code approach. Our Flutter decision guide covers when sharing code pays off and when native or web-only delivery is the better call.

Launch to a limited group first: a beta track, an invite list or one market. You want enough users to learn from and few enough that every problem can be followed up personally.

Add analytics, crash reporting and performance monitoring in the first release, not after launch. Without them, every later decision about what to expand, fix or cut is an argument between opinions.

Start with a short event plan tied to the journey, and name the decision each event informs. Ten well-chosen events beat two hundred automatic ones.

``` EVENT PLAN (illustrative, for a lead-tracking app)

signup_completed -> Is onboarding losing people? first_lead_created -> Activation: did they reach first value? lead_status_changed -> Core action: are they using it for the job? payout_viewed -> Is the outcome visible to them? session_started -> Retention by weekly cohort error_shown {code} -> Which failures do users actually hit? ```

Alongside the events, set up three things:

• Crash and error reporting with release tagging, so you can see whether a new version made things worse.
• Performance traces on the journeys that matter: app start, the main screen load and the slowest API call.
• One headline metric and a few guardrails. For example, weekly active users who complete the core action, with crash-free sessions, support tickets per hundred users and the cost of each AI result as guardrails. A headline number that rises while a guardrail falls is a warning, not a win.

Respect privacy from the start. Collect the minimum, avoid personal data in event properties, honour consent where the law requires it, and write down what you collect and why. Retrofitting consent after launch is slow and often means losing history you relied on.

The test for instrumentation is simple: when someone asks "is it working?", can you answer with a dashboard rather than a guess?

Add a new surface when a different user, or the same user in a different context, needs to do a job the current product cannot serve well. Do not add one because a competitor has it or because the framework makes it possible.

The signals are usually concrete: operators asking for a tablet at a counter, administrators exporting data to spreadsheets because the phone screen is too small, partners asking for a browser link instead of an app install.

What should carry over is the domain logic and the design system: the rules, the data model, the API contracts, and the components and tokens that make the product recognisable. What should not carry over unexamined is the layout. A good expansion makes the new context feel designed for, not tolerated.

This is where early architecture decisions pay back. If business rules live in a domain layer separated from the interface, a new surface is mostly new screens. If they are tangled into phone screens, it is a partial rewrite. Our multi-platform architecture guide covers those boundaries in detail.

Add one surface at a time and instrument it like the first. A second surface launched without its own metrics is impossible to judge.

Hardening is the work that keeps a product trustworthy as more, and more varied, people use it: performance, accessibility, localisation and offline behaviour. Start it once the journey has proved its value, but design for it from the beginning so it is an extension rather than a retrofit.

Performance budgets

Write numbers down and check them in CI or before each release. The figures below are illustrative starting points to adapt to your product:

Test on the devices your users own, not the team's latest phones.

Accessibility

Treat WCAG 2.2 level AA as the working target. In practice that means screen reader labels on every control, support for the system text size, sufficient contrast, touch targets large enough to hit reliably, and journeys that work with a keyboard on web and desktop. Accessibility is far cheaper when the design system enforces it than when it is audited at the end.

Localisation

Externalise every user-facing string from the first release, even if you launch in one language. Plan for text that runs longer than English, plural rules that differ by language, right-to-left scripts if they are on your roadmap, and local formats for dates, numbers and currency.

Offline and poor connectivity

Decide per journey, not per app. Some journeys can be online-only with a clear message. Some need a read cache so recent data stays visible. A few need queued writes, which in turn need rules for conflicts when two devices change the same record. Write the choice down for each journey before building it, because offline behaviour is hard to add later.

A launch is the start of operational ownership. Operating a product means releasing routinely, knowing quickly when something breaks, and turning what users report into fixes.

Releases. Ship on a regular rhythm so releases become routine rather than events. Use staged rollouts on the app stores, starting with a small percentage of users, and watch crash and error rates before widening. Mobile binaries cannot be rolled back once installed, so build the escape hatches in early:

• Remote flags to switch off a feature without a store review.
• A minimum-version check that can prompt or require an update when an old version becomes unsafe.
• Backward-compatible APIs, because old app versions stay in use for months.

Monitoring. Alerts on crash rate, error rate and the key journey, sent to someone who will act on them. An alert nobody owns is noise. A short runbook for the most likely incidents (a bad release, a provider outage, an expiring certificate) turns a stressful hour into a routine one.

Support. Give users a clear way to report problems, and give support a way to pass them to engineering with the app version and device attached. Review the most common issues weekly alongside the analytics. Together they tell you what to fix next.

Upkeep. Plan for the work that arrives whether you want it or not: annual OS releases, store policy and target-SDK deadlines, dependency updates and certificate renewals. Put them on a calendar. If you treat them as surprises, they will keep interrupting feature work.

Operating well is also what makes the earlier stages repeatable. A team that can release safely every week can afford to test ideas in production, which brings the roadmap back to stage 1 for the next big risk.

The roadmap ends with a team that can own the product, not with a studio that has to stay. If an outside team builds any of these stages, the client should finish with more capability than they started with.

In practice that means:

• Code, accounts and release knowledge stay with the client from the first commit: repositories, cloud and store accounts, signing keys and analytics all in the client's organisation.
• Decisions are written down as short decision records, so the next hire can see why the architecture looks the way it does and which alternatives were rejected.
• Hard parts are paired on, so the client's engineers have changed the release pipeline, the domain layer and the monitoring themselves before handover.
• The operating model is documented: how to release, how to respond to an alert, and what the upkeep calendar contains.

This is how we run our own engagements, in four beats: a first conversation about fit and risk, a bounded first milestone agreed in week 1, visible work every week, and a handover the client's team can own. The roadmap above sits inside that rhythm. Stage 1 is often the first milestone itself.

The goal is not to make a team dependent on a studio. It is to make the product easier to change after the studio leaves. If you are inheriting a product rather than starting one, our takeover playbook covers the other direction.

Whatever stage you are at, the next step is small and concrete. Find your stage below and do the first thing on the list.

• You have an idea: write the riskiest assumption in one sentence and design the cheapest test that would settle it.
• You have tested the risk: write the core journey as steps, mark each must-have, could-fake or later, and add the invisible essentials.
• You are building the first release: write a ten-event plan with the decision each event informs, and add crash reporting before the first beta.
• Users are asking for another screen: write down who needs it, in what context and for which job, then check whether your domain logic can be reused without copying it.
• The product is growing: set three performance budgets and run an accessibility pass on the main journey.
• You have launched: put staged rollouts, a remote kill switch and the upkeep calendar in place before the next feature.

If you want a second opinion on where your product sits, or on the first milestone for the next stage, talk to the team. Bring the journey, the platforms you have in mind, and what is already built. For products with an AI feature at the core, the AI product development guide describes how we scope the first useful job.

What are the stages of taking a product from idea to launch?

A practical sequence is: retire the biggest risk, ship the smallest valuable release, instrument it, expand to new surfaces when users need them, harden for scale, and operate. Instrumentation starts on day one and runs through every stage. Each stage ends with evidence rather than a date.

How small should an MVP be?

Small in breadth, complete in depth. A useful first release covers one journey end to end, with real sign-in, real data, error handling and a repeatable release process, on the surface where users do the job. Steps that can be handled manually for now should be.

Should we launch on iOS, Android and the web at the same time?

Only if your users genuinely need all three for the first journey. Most products learn faster by launching on the surface where the job happens, then expanding with evidence. If several surfaces are needed early, a shared-code approach can help, provided the domain logic is kept separate from the interface.

What analytics should a new app track at launch?

Start with around ten events tied to decisions: sign-up completion, first value, the core action, retention by cohort and the errors users see. Add crash reporting with release tagging and performance traces on the main journey. Collect the minimum personal data and record what you collect and why.

When should we invest in accessibility and localisation?

Design for both from the first release and invest fully once the journey has proved its value. Externalising strings and building accessible components into the design system cost little early. Retrofitting either after launch costs far more, because it touches every screen.