Why start with a foundation
Most app projects that go wrong do so for the same reason: a team starts building before anyone has agreed what the app is. Features pile up, the budget grows and, by the time something is ready to show, nobody is sure it is what customers wanted. Mobile App Foundation is a small, fixed-scope first stage that fixes that.
It produces three things: a clear scope, a clickable prototype and a written estimate. Together they let you decide, with real information, whether to build, how much to build first and who should build it.
What is included
- A scoping workshop to capture your goal, your users and the problem the app solves.
- User flows and a screen map that show how someone moves through the app.
- A clickable prototype of the core journey, which you can open on your phone and test with real people.
- A recommendation on iOS, Android or both, and on the technology to use.
- A feature list divided into what must ship in version one and what can wait.
- A written estimate for full development, based on the agreed scope.
The prototype is a design and testing tool. It is not a working app and does not have a live backend, accounts or payments.
How the work runs
- Discovery: we talk through your idea, the people who will use it, and what success looks like.
- Scoping: we turn that into a list of screens and features and a map of the main flows.
- Prioritising: we agree what belongs in version one, using the rule that the first release should do one thing very well.
- Prototyping: we design the core screens and link them into a clickable model.
- Review: you try the prototype, share it with others and give feedback, and we adjust.
- Estimate: we deliver the scope, the prototype and a written estimate for full development.
Each stage ends with something you can see and approve, so you stay in control of direction.
Choosing iOS, Android or both
The first question is where your users are. In the US, iPhone use is high among many consumer and professional audiences, while Android dominates in many other markets, including India. A product aimed at a specific country or sector often has a clear lean.
The second is budget and speed. Building two separate native apps costs more and takes longer than one. Cross-platform tools let one codebase serve both and suit many business apps, while a heavy graphics or hardware-based product may justify native work. We explain the trade-offs in plain terms and recommend what fits your plan, including starting on a single platform and expanding once the idea is proven.
What a good first version looks like
A first release is not the whole vision. It is the smallest app that lets a real user get real value, so you can learn from it. We help you find that line.
- One core job done well, rather than ten done badly.
- The fewest screens needed to complete that job.
- Sign-in and data handled simply, with only the permissions you need.
- Features you can measure, so you can see what users actually do.
- A list of what comes next, ranked by evidence, not guesses.
Everything on the "later" list stays in the scope document, so nothing is lost. It simply does not delay the launch.
Test the idea before you build it
A clickable prototype is one of the cheapest ways to learn whether an idea works. Put it on a few phones, ask people from your target audience to complete a task and watch where they hesitate. The places where people get confused are the places the design needs work, and fixing them on a prototype costs hours, not weeks.
We suggest simple ways to run these sessions, such as asking five people to do the same task and noting where they stop. Five is usually enough to reveal the biggest problems.
Things the foundation stage also covers
- Accounts and login: what sign-in approach suits your users.
- Data and privacy: what you collect, why, and the rules that apply, such as app store requirements.
- Integrations: payments, maps, messaging or other services the app depends on.
- Admin needs: how you or your team will manage content and users.
- Store requirements: what Apple and Google expect before an app can be published.
These are the areas that most often cause surprises late in a project. Raising them early makes the estimate more accurate.
The estimate
At the end of the stage, you receive a written estimate for full development. It is based on the scope we agreed together, not on a guess made from a one-line brief. It sets out the features, the main assumptions and the effort required, so you can compare it with other quotes on equal terms.
If you decide to build with us, the work carries straight on from the scope. If you decide not to, or to build elsewhere, the scope, flows and prototype are yours to take.
Is this right for you?
Mobile App Foundation suits founders and businesses with an idea for an iOS or Android app who have not yet committed to development. It also suits teams that already have a developer but need a clearer brief. If you need a simple website instead of an app, our website services are a better fit, and if you need a larger custom software system, our Custom Software Solution service covers that.
Tell us what you have in mind when you order, even in a few lines. The more we know at the start, the more useful the first workshop will be.
Who does what
You bring the knowledge of your market and your customers. We bring the product, design and engineering experience to turn that knowledge into a buildable plan. The stage works best when one person on your side can attend the workshop, review each step promptly and make decisions, because delays in feedback are the most common reason a scoping stage drags on.
You do not need to be technical, draw anything or know the names of tools. If you can explain who the app is for and what it should help them do, we can take it from there.
Common reasons app ideas stall, and how this helps
- The idea is too big. We cut it down to a first version that can ship.
- Nobody agrees what it does. The scope document gives everyone the same picture.
- The cost is unknown. The estimate replaces a guess with a number you can plan around.
- The idea is untested. The prototype puts it in front of users before you build.
- The wrong team is chosen. A clear brief lets you compare developers fairly.
Most of the value of this stage is in the decisions it forces early, when changing your mind is still cheap.
What it does not cover
To keep expectations clear, the foundation stage does not include production code, a live backend, app store submission, ongoing maintenance or marketing. Those belong to the development stage and later. We describe them in the estimate so that you can see the whole path, not only the first step.
