With us, the first version of an app is usually live within 4 to 8 weeks. That isn't a matter of working harder, but of choosing sharply: what has to be in version 1, and what can wait until you know how users respond? This article covers what determines how long app development takes, how such a project runs week by week, how we agree a fixed price up front, and what went into version 1 on a number of projects we built.
The short version
- MVP or first version: 4 to 8 weeks, depending on how much goes in.
- The biggest factor is scope, not the number of screens: user roles, payments, integrations and real-time features take the most time.
- Price and deadline are fixed up front. After a free intake you get one fixed price and a delivery date, which don't change as long as the scope stays the same.
- You see a working version every week, so you can steer along the way instead of only at the end.
What determines how long it takes?
Two apps with the same number of screens can differ by a few weeks. These are the factors that matter most:
- User roles. An app for one type of user is done sooner than a platform where customers, providers and admins each see something different.
- Payments. Checkout, subscriptions or payouts to third parties need extra building and testing.
- Integrations. Each link to another system, such as a POS, accounting software or an external API, also depends on how well that system is documented.
- Real-time features and hardware. Live statuses, notifications that must arrive instantly, or a connection to a scanner or touchscreen.
- Waiting time. Feedback, copy, logos and account access that keep you waiting push the schedule just as hard as technical problems.
- Publishing. Apple and Google review an app before it appears in their stores. That usually takes a few days, but leave some room for it.
How a 4 to 8 week project runs
- Discovery. In the free intake we discuss your goal, your users and what the app must do at minimum. Above all, we ask what does not need to be in version 1.
- Scope and planning. We fix which screens, roles and integrations are included. You get one fixed price and a delivery date before a line of code is written.
- Build and adjust. The bulk of the project. Every week you get a working version to try on your own phone, and you give feedback straight away.
- Test and launch. We test with real users, publish to the App Store and Google Play and set up hosting and monitoring. After launch we stay available for improvements.
You can read more about each step on our process page.
What about a web application?
A web application, such as a client portal, an internal dashboard or a SaaS MVP, follows the same 4 to 8 week timeline. A few things are different, though:
- No app store review. A web application goes live as soon as it's ready, and so does every update. That saves a few days at the end and makes adjusting after launch faster.
- Integrations and the admin side drive the schedule. With web applications most of the work is often not in the screens, but in connecting to systems you already use, such as your CRM or accounting software, and in what admins need to be able to do.
- One version for every device. A good web application works on laptop, tablet and phone, without separate iOS and Android versions.
Not sure whether you need a web application or an app? Start by asking whether users really need phone features, such as background notifications or the camera. Web app vs native app compares the options side by side. Read more on the page about having a web application built.
Transparent pricing: how we fix the price up front
We don't bill a first version by the hour. After the intake you get one fixed price that matches the scope. As an indication, based on our own projects:
| Type | Indication | Typically in version 1 |
|---|---|---|
| MVP | €3,000 – €5,000 | Only the core feature, to test your idea with real users as fast as possible. |
| Simple app | €5,000 – €8,000 | A few screens, accounts and an admin panel, without complex integrations. |
| Complete app | €10,000 – €15,000 | Several user roles, payments, integrations or real-time features. |
Want to add something halfway through? Then we look together at what can make way for it, or put it on the list for version 2. That way the price and deadline hold. How these amounts are built up is explained in How much does it cost to build an app?.
What went into version 1: examples from our projects
Every first version is different, because every product solves a different core problem. A few examples of what we built into version 1, and why.
Glasfixer: starting small with three products
Glasfixer makes made-to-measure glass, so every order used to mean a quote and manual work. Instead of putting the whole range online at once, the webshop with a price calculator launched with three products. Customers enter dimensions and thickness and see the price straight away. The result: Glasfixer no longer enters orders by hand and saves 10 hours a week. Adding more products now builds on a proven base.
Spichaser: investing where the risk is
The core of Spichaser is a timely warning when you might be followed. That's also where the biggest challenge was, and so most of the attention: a dedicated server that processes large volumes of licence plate data and sends alerts on time. We built the app itself in React Native, so one codebase runs on iOS and Android. That way the time went to the part that makes or breaks the product.
Akhie: trust belongs to the core
On a platform where guests eat at home cooks' tables, trust isn't an extra. That's why verification, reviews and secure payments between guests and hosts were already in the first version of Akhie, along with support for several languages. What belongs in version 1 depends on the product: sometimes it's more than you'd think.
Haagse Taxi: build once, use twice
The owner of Haagse Taxi also runs the Haagse Taxi Centrale. Instead of two booking systems, we built one booking platform that both brands run on, each with its own website and look. Customers see a fixed fare up front. Rates and bookings live in one place, so the second brand didn't need to be built again.
Tapp: a platform in separate parts
Tapp lets festival visitors order drinks in an app and collect them from containers. Around the ordering app we also built a POS tablet for bar staff and a touchscreen interface for the containers. Each part is a well-defined project that talks to the same backend. That's how a large platform grows in steps, each with its own schedule and price.
The common thread: a fast launch doesn't come from less care, but from a smaller first version. Pick the one problem your product has to solve, build that well, and let the rest wait until users tell you what they need.
Why it sometimes takes longer anyway
Even with a fixed schedule, things can slip. The most common causes:
- The scope grows along the way. Every "small addition" takes time. That's why we'd rather swap than stack.
- An outside party is slow. An API without documentation, or a supplier who takes a long time to grant access.
- Feedback doesn't come. When a working version sits unseen for a week, everything after it moves too.
- The store rejects the app. Apple has strict guidelines; a rejection means adjusting and resubmitting.
How to keep the pace yourself
- Appoint one person who makes decisions and reviews the new version every week.
- Provide copy, logos and access to accounts and systems early.
- Create Apple and Google developer accounts in your company's name ahead of time; that can take a few days.
- Write down ideas that come up during the build for version 2, instead of squeezing them in.
Want to know how long your app will take?
In a free intake we work out the smallest version of your idea, and you get a fixed price and delivery date. Before that, you might read What is an MVP? and how to choose the right partner, or browse all our cases.