Who this guide is for and how to use it
This guide is for founders, product owners and business leads who have an idea for a web or mobile product and need to decide how to build it. You do not need to be technical. You do need to know who the product is for and what would make the first release a success.
Read it in order the first time. The next chapter turns your idea into a risk. The chapters after it explain five options, the criteria that separate them and six hypothetical cases where the reasoning is applied. The later chapters cover scoping a first version, planning its exit, questioning vendors and making the call.
Some projects have a short answer, and we give it where it is honest to. Most depend on facts only you have: your deadline, your team, your customers' devices, the data you hold. The guide gives you the questions and, at the end, a checklist that turns them into a written decision.
This guide does not crown a winner. Every option here is the right answer for some product and the wrong one for another. The aim is a decision you can explain in one paragraph to a colleague, an investor or a vendor.
Start with the problem and the biggest risk
Most arguments about how to build are arguments about risk in disguise. A team afraid that nobody will use the product and a team afraid of a data breach need different first releases, even for the same idea. Name your biggest risk before you compare any technology.
The four risks
| Risk | The question behind it | What the first release should prove | Approaches that tend to fit |
|---|---|---|---|
| Demand | Will anyone want this enough to use it or pay for it? | That a specific group does a real job with your product, again and again | No-code, a configured off-the-shelf tool, a simple responsive website |
| Usability | Can people finish the main task without help? | That the core flow works for real users, in their language, on their devices | A clickable prototype first, then web or cross-platform |
| Scale | Will it hold when many people use it at once or the data grows? | That the architecture, not only the screens, survives load and growth | A custom web or mobile build with a proper back end, load tested early |
| Security and compliance | Will it protect the data and meet the rules that apply to us? | That the sensitive flows are designed, reviewed and tested before launch | A custom or carefully configured build, with a threat model before any code |
Most products carry more than one risk, but one usually dominates. A startup with an unproven idea is exposed on demand. A bank adding a mobile feature is exposed on security. A growing marketplace is exposed on scale. Rank yours, then let the top one choose the approach.
Turn the risk into a test
For each risk, write the cheapest experiment that would reduce it. For demand, that may be a landing page, a waiting list and a handful of conversations. For usability, a clickable prototype tested with real users. For security, a threat model of the core flows. Then ask whether the approach you are weighing lets you run that experiment soon and cheaply.
If you cannot say which risk matters most, that is the first piece of work. A short discovery sprint, with research, a prototype and a written roadmap, exists for this reason. It is cheaper to learn it there than halfway through a build.
The options, explained
Five families of approach cover almost every product. They overlap, and many products mix them, such as a native app with a web admin panel. Here is what each one is, what it does well and where it hurts.
Responsive web and progressive web apps
A responsive web app runs in the browser and adapts to phones, tablets and desktops. A progressive web app (PWA) adds a manifest and a service worker, so people can install it on the home screen and it gains some offline ability. Both ship by publishing to a URL: no store review, and everyone is on the latest version as soon as you deploy.
The limits are device access and platform polish. Browsers expose a growing set of capabilities, but support differs by browser and operating system, and iPhones have historically offered fewer than Android phones. Check current support for every feature you depend on, such as push notifications, background work, Bluetooth or file access. We build these with Next.js, React and TypeScript: see web development, Next.js development and SaaS platforms.
Native iOS and Android
A native app is written separately for each platform in its own language and tools: Swift for iOS, Kotlin for Android. You get the best access to device features the day a new system version arrives, the smoothest animation and the most predictable background behaviour. You also get two codebases to build, test and maintain, and usually two skill sets to hire.
Native is the right call when the device is the product: heavy camera or sensor use, advanced graphics, tight links to wallets, watches or health data, or strict performance targets. See iOS and Android development and the glossary entry on a native app.
Cross-platform with Flutter or React Native
Cross-platform frameworks let one team write most of an app once and ship it to iOS and Android. Flutter (Dart) draws its own interface with its own rendering engine, so screens look the same everywhere. React Native (JavaScript or TypeScript) maps your components to the platform's real interface elements and suits teams that already work in React. Both can reach native code when a feature needs it.
For most business apps, such as accounts, forms, lists, maps, payments and notifications, cross-platform delivers a product users cannot tell from native, with one codebase to maintain. The cost is a layer between you and the platform: a new system feature may wait for plugin support, and unusual performance needs may call for native modules. Read the comparison of Flutter and React Native and the wider piece on native or cross-platform. Our pages on Flutter and React Native describe how we build, and the glossary explains a cross-platform app.
No-code and low-code
No-code platforms let you assemble a product from visual building blocks with little or no programming. Low-code adds the option to write code where the blocks run out. Tools we work with include Webflow for marketing and content sites, Bubble and FlutterFlow for web and mobile apps, and Airtable and Zapier for data and automations. The glossary explains no-code.
No-code is strongest when speed and cheap change matter more than control: testing an idea, internal tools, content sites, simple marketplaces. It gets harder when you need unusual logic, heavy data, fine control of performance or the right to take the product elsewhere. Each platform has its own limits on code export, so check before you commit. The article on when no-code is the smart first version covers the trade-offs.
Buy and configure
The fifth option is to build nothing. A booking system, store platform, helpdesk or learning platform may already exist as a product you configure and connect to your brand and data. You spend effort on setup, integration and migration instead of on code.
Buying wins when your need is common and the product's way of working suits yours. It loses when the workflow is your edge or the vendor's model fights your process. A fair test: if you would happily run the same workflow as your competitors, buy it; if the workflow is the product, build it. The build vs buy article goes deeper, and many teams end with a hybrid of a bought core and a custom front end.
The criteria that decide it
Ten criteria separate the options. Rate each as high, medium or low importance for your product before you look at any option, otherwise the criteria drift to suit whatever you already like.
| Criterion | The question to ask | What it pushes you toward |
|---|---|---|
| Time to first release | How soon must real users have it, and what happens if it is late? | No-code, buying or web for speed; native for two platforms takes longest |
| Budget shape | Is money available up front or only monthly, and do costs grow with users? | No-code and bought tools spread cost into subscriptions that grow with use; custom code costs more up front and less per user later |
| Team skills | What can your team, or the team you can hire, maintain after launch? | The stack your people already know, such as React for React Native |
| Device features | Does it need camera, Bluetooth, NFC, background location, biometrics or widgets? | Native, or cross-platform with native modules; web only if the browser supports each feature |
| Performance | Are there heavy animations, large lists, live maps, games or video? | Native for the most demanding; cross-platform and web for typical business screens |
| Offline use | Must it work without signal, and for how long? | Native or cross-platform with a local database; a PWA for light needs |
| Distribution | How do users find it: search, a link, an app store, a company device manager? | Web for links and search; apps for store presence or device features |
| Security and compliance | What data is held, where may it live and which rules apply? | A custom or carefully configured build with a threat model; check where no-code and bought tools store data |
| Maintainability | Who updates it when the operating system, framework or a dependency changes? | Fewer codebases and fewer moving parts, with one team that owns the product |
| Vendor lock-in | Can you export your data and code, and what if the vendor changes its terms? | Open standards, code you own and exportable data |
Three rules for using the table
- Pick the two or three criteria that truly matter. A product with strict offline needs and sensor use is a different product from one that is mostly forms.
- Treat a hard requirement as a filter, not a score. If it needs background location on iPhone, a pure web app is out whatever its other merits.
- Write down what you are giving up. Every option trades something, and the decision is sound only if the trade is on purpose.
Give security extra weight
Security is the criterion teams most often leave for later, and it cannot be added at the end the way a colour can be changed. Where data lives, how people sign in, what the client exposes and how updates ship all depend on the approach. Mobile apps put code on devices you do not control, so secrets and trust decisions must stay on the server. Browser apps face their own attacks, such as cross-site scripting. No-code and bought platforms move some duties to the vendor and leave others with you, so read where each line falls. Our guide to secure app development sets out the method.
Comparing the options side by side
Use these tables as a first filter, not a verdict. They describe typical behaviour, and specific products and teams vary.
| Approach | Speed to first release | Control and capability | Main trade-off |
|---|---|---|---|
| Responsive web or PWA | Fast: one codebase, no store review | High for web features; limited device access on some platforms | Browser limits on device features and store presence |
| Native iOS and Android | Slowest: two codebases | Highest, with day-one access to new features | Two codebases to build, test and maintain |
| Cross-platform | Fast to moderate: mostly one codebase | High for most business needs, with native code for the rest | A framework layer between you and the platform |
| No-code or low-code | Fastest to a working version | Limited to what the platform offers | Lock-in, and ceilings on logic, data and performance |
| Buy and configure | Fast if the product fits | Limited to the vendor's model | Your process bends to the product, and data lives with the vendor |
| If you need | This usually fits | Think twice about |
|---|---|---|
| Camera, Bluetooth, NFC or background location | Native, or cross-platform with native modules | Web, unless every feature works in your target browsers |
| Work with weak or no signal | Native or cross-platform with a local database | Web without a service worker, and many no-code tools |
| A content, marketing or documentation site | Web, or Webflow | A native app for what is really a page |
| An internal tool for a small team | No-code, low-code or a configured product | Two native apps |
| Payments or other regulated data | A custom build with a threat model, using a licensed provider for the sensitive parts | A tool whose data location and controls you have not checked |
| Fast animation, 3D, AR or media editing | Native | Web or no-code |
What cost really means
Cost is not one number. No-code often starts cheap and grows with seats, records or runs. Custom code costs more up front and less per extra user. Native adds build and test effort for the second platform. Hosting, store fees, licences and maintenance continue after launch whichever you pick. The article on how much a mobile app costs explains the cost drivers, and the page on pricing models explains how an engagement can be structured: a discovery sprint, a fixed-scope build or a monthly dedicated team.
Six hypothetical scenarios
These cases are invented for illustration. They are not clients and not case studies. Each shows how the same questions lead to different answers.
A tutoring marketplace testing demand
Imagine a founder who wants to connect students with private tutors. The unknown is whether both sides will find each other and pay through the platform.
- Recommended path: a no-code first version, such as a Webflow site or a Bubble app, with a hosted payment service.
- Why: the risk is demand, so speed and cheap change matter most. The matching rules will change after the first dozen tutors.
- Watch for: what you can export, and which result, such as repeat bookings, tells you to move to custom code.
A delivery company with a driver app
Imagine a regional delivery firm whose drivers scan parcels, photograph proof of delivery and work in areas with poor signal.
- Recommended path: a cross-platform app in Flutter or React Native with a local database that syncs later, plus a web dashboard for dispatchers.
- Why: offline use and the camera are core, but the screens are ordinary business screens, so one codebase saves effort. See logistics.
- Watch for: background location and battery behaviour differ by device maker, so test on the real handsets. Plan how sync resolves two people changing the same record.
A wallet and payments app
Imagine a start-up building a wallet that holds balances and sends money between people.
- Recommended path: a custom build, native or cross-platform, with a threat model before any code and a licensed provider or bank partner for holding and moving money.
- Why: the risk is security and compliance. Money movement, identity checks and fraud controls belong on a hardened server side, and regulators will ask how they work. No-code suits the marketing site, not the core. See fintech.
- Watch for: your obligations depend on what you do with money. Ask counsel and your provider which licences apply before you design the product.
A restaurant group with online ordering and loyalty
Imagine a group of restaurants that wants online ordering, delivery tracking and a points scheme.
- Recommended path: buy and configure an ordering and loyalty product, behind a branded responsive website. Add custom features later only where the product is too rigid.
- Why: ordering, payments and loyalty are common needs with mature products, and building them again spends budget on what competitors already have. See e-commerce.
- Watch for: who owns the customer data, what you can export, and fees that grow with order volume.
A clinic booking and records portal
Imagine a group of clinics that wants patients to book visits and see results online.
- Recommended path: a responsive web portal on a custom back end designed around the sensitive data, or a configured scheduling product whose data location meets your rules. A mobile app can follow. See healthcare.
- Why: the risk is privacy. A web portal reaches every patient without a download, and the sensitive flows can be reviewed in one place.
- Watch for: health data is sensitive in almost every jurisdiction. Ask counsel about consent, retention and storage location before choosing any hosted tool, no-code and bought ones included.
An inspection tool for a facilities team
Imagine a facilities team that wants to replace paper checklists with forms, photos and a daily report, for a few dozen known users.
- Recommended path: a no-code or low-code app, or a PWA, with a simple database behind it.
- Why: the users and devices are known, no store listing is needed, and the value is in replacing paper, not in polish.
- Watch for: offline needs, access control by role, and what happens when the person who built it leaves.
Notice the pattern. None of the six answers began with a technology. Each began with the risk, then the constraint that could not move, then the cheapest approach that respects both.
How to scope a first version and what to defer
A first version is an experiment with a user interface. Its job is to answer your biggest risk, and everything that does not help is a candidate for later. This is the idea behind a minimum viable product. It is more disciplined than it sounds: an MVP is not a poor-quality product, it is a narrow one.
A scoping method you can run in an afternoon
- Write the one-sentence promise: who the product helps, with which job, and what changes for them.
- List the user's path from first visit to first success, and keep only the steps needed to reach it.
- Mark each feature as must, should or later. A must is a feature without which the promise is false.
- Name the single measure that tells you the first version worked, and how you will collect it.
- Check each must against your biggest risk. If it does not reduce the risk, move it down.
- Write the not-now list and share it. People accept deferral when they can see it.
Build now, defer later
| Build in the first version | Usually safe to defer |
|---|---|
| The core flow from sign-up to first value | Rarely used settings and preferences |
| Sign-in, roles and the data protections the product needs from day one | Social features, referral schemes and gamification |
| Analytics that measure your one success metric | A full admin panel: start with the database or a simple tool |
| Both languages, if your audience needs both | Further languages beyond the first two |
| Error handling and basic monitoring | Custom animation beyond what usability needs |
| A threat review of the sensitive flows | Advanced personalisation and recommendations |
Some things are cheap to include early and costly to add later: security design, accessibility, a data model that can grow, and right-to-left support if you will need it. Most features are the opposite. Spend your early effort on the first kind, and read the guide to bilingual Arabic and English products if two languages are likely.
A discovery sprint is one way to do this scoping with help: research, a clickable prototype, a technical approach, a threat model of the core flows and a written roadmap, over about two weeks. You leave with a plan on paper rather than only a conversation.
Planning the exit from a first version
Treat the first version as a stage, not the destination. The question is not whether you will outgrow it but how you will leave and what you will carry with you. An exit plan written before you start costs an hour. Discovered mid-crisis, it costs months.
What to keep, whichever approach you choose
- Your data, in a form you can export in full: users, content, transactions and the links between them.
- Your design work: research findings, flows, a design system and the prototype. Design moves between technologies; platform-specific builds do not.
- Your domain, accounts and credentials in your own name, not a vendor's or a freelancer's.
- Written rules: business logic, permissions and integrations described in plain language.
- Your analytics history, so you can compare the new version with the old.
Signs it is time to move
- You work around the platform's limits more often than you build with its strengths.
- Costs rise faster than value as users, records or automations grow.
- A requirement such as offline use, a security control or a data location cannot be met.
- Performance complaints trace to the platform, not to the design.
- Only one person understands how it works.
Migration patterns
| Pattern | How it works | Good for |
|---|---|---|
| Rebuild behind the same front | Keep the visible product and replace the data and logic layer piece by piece | No-code products with a working interface and a limiting back end |
| Strangler migration | Route one feature at a time to the new system until the old one is empty | Larger products that cannot pause |
| Parallel run | Operate both for a period and compare results before switching | Money, orders or records where mistakes are costly |
| Clean rebuild with data import | Build the new product fresh, import the exported data and redirect users | Small products with simple data |
Whatever the pattern, plan redirects so links and search visibility carry over, a message to users and a way back if something fails.
Questions to ask any vendor
These work for an agency, a freelancer, a platform vendor or an internal team. A good partner answers plainly and in writing, and the answer includes what they would not do.
About the approach
- Which of these approaches would you not recommend for this product, and why?
- What is the biggest risk in my plan, and how does your proposal reduce it?
- What is in the first release, and what have you deferred?
- What would make you change the approach halfway?
About ownership and exit
- Who owns the code, the design files, the data and the accounts at the end?
- If I leave, what can I export, in what format, and what stays behind?
- Which parts depend on a platform or paid service, and what happens if its terms change?
About security and delivery
- How do you review security before the build and before launch, and can I see an example of the output?
- Where is data stored and processed, and who can access it?
- How often will I see working software?
- What drives the cost: scope, usage, seats or time? What are the running costs after launch?
For context, our own way of working is on the how we work page: weekly demos, plain-language plans and clear estimates. Every project begins with a threat review, and the security practices page describes how we test before each release.
A decision checklist
Work through this list with the people who will own the product and write the answers down. Each answer you cannot give is a question to settle before you spend money.
- We have named our biggest risk (demand, usability, scale or security) and the experiment that would reduce it.
- We can say in one sentence who the first version is for and what success looks like.
- We have ranked the criteria and marked the hard requirements.
- We checked each device feature we need against what web, cross-platform and no-code options support today.
- We know the budget shape: what is paid up front, what recurs and what grows with use.
- We know who will maintain the product after launch, and that they know the chosen stack.
- We know what data we hold, where it may be stored and which rules apply, and we asked qualified advisers where needed.
- We know how users will find the product: a link, search, a store or a company device manager.
- We have a not-now list, and the first version fits the experiment.
- We have an exit plan: exportable data, accounts in our name and signs that it is time to move.
- We asked vendors the questions above and have the answers in writing.
If most answers are yes, you are ready to commission a build, or a discovery sprint to close the gaps. If several are no, the checklist has done its job: it has shown you where to look first.