How long does it take to build an app?

Building an app takes 6 to 16 weeks with us, depending on what kind of app it is. A web app takes 6 to 12 weeks, from the discovery workshop that produces the written scope to the day it goes live. A first version of a product for founders, an MVP, takes 8 to 12 weeks. A mobile app for iOS and Android takes 10 to 16 weeks. Each of those is for an app with sign-in, a database, one core workflow, an admin panel and notifications, built by a senior developer in two-week sprints. A business website is quicker at 3 to 6 weeks. Where your project lands in its range depends on how many workflows, roles and integrations it needs, and on how quickly decisions get made on your side. This article walks through the weeks, what stretches them and what keeps them short.

These are calendar weeks, not working days of effort. A project is a sequence of decisions as much as a sequence of code, and some of those decisions are yours: approving the design, testing a sprint's work, supplying content and data. The timeline assumes those happen within a few days each time.

Every project at ELORA DIGITAL follows the same five steps, described on our process page. Here is how they fall across a typical ten-week web app.

The discovery workshop turns the idea into a written scope: the one core workflow, the user roles, the integrations, and what is deliberately left for later. For a project over $10,000 this workshop is paid ($500 to $1,500) and credited to the project if it goes ahead. Wireframes follow, and you approve the design before anything is built. This is the cheapest moment to change your mind, so it is where we ask the most questions.

Three sprints of two weeks each. The first sprint usually delivers sign-in, roles and the data model, so you can see real screens with your own terms in them early. The second builds the core workflow from end to end. The third finishes the admin panel, the notifications and the edges: empty states, error messages, permissions. Each sprint ends with a working build in your client portal, a short review, and a decision on what the next sprint contains.

User acceptance testing with your team, fixes, a security check, data migration if there is any, and the launch itself. You get the documentation, the source code and a 30-day warranty. From there the care plan looks after hosting, backups, updates and small changes.

A six-week project compresses this to one or two sprints with a very tight scope. A twelve-week project adds sprints for integrations or a second workflow.

A mobile app follows the same five steps, and the extra weeks come from the things a web app does not have. The API and database behind the app are built and secured in the first sprints, so there is a working back end before the screens arrive. Each sprint's build is installed on real iPhones and Android phones, not only viewed in a browser, because the camera, GPS, notifications and offline storage behave differently on each. Then both app stores review the app before launch, which can take days and occasionally sends a build back for changes. One React Native codebase keeps the two platforms from doubling the work, but testing and the store process still add roughly four weeks to a comparable web app. If the phone's own features are not part of the job, a web app that people add to their home screen launches sooner; website, web app or mobile app explains how to tell.

Most delays in software projects come from one of these:

• Late feedback. A sprint review that waits a week pushes every later sprint by a week. The build cannot move to the next piece until the last one is confirmed.
• Scope that changes mid-build. New ideas are welcome, but a change to the core workflow after sprint two means revisiting finished work. We quote changes separately so the decision is deliberate.
• Integrations. Connecting to Xero, Stripe or a customer's own system depends on the other side: documentation, sandbox accounts, approvals. Start those conversations in week one.
• Content and data that are not ready. Migrating years of spreadsheet records means cleaning them first, and that is usually the client's job. Decide early what moves and what stays behind.
• Too many decision-makers. One person who can say yes keeps the project on its dates.
• Unclear roles and permissions. Who can see and change what is the question that gets answered last and costs the most to change.

• A smaller first version. One workflow done properly launches sooner than three done roughly. Add the rest as a second stage once people are using it.
• A paid discovery workshop. A few hours of decisions saves weeks of rework.
• Test data and real content from day one. Real job names, real customers and real documents show problems that placeholder text hides.
• Standard parts. Sign-in, roles, email and the admin panel are included and proven. Asking for them to behave unusually is where time goes.
• A fixed scope and a fixed price. When the scope is written down, nobody has to renegotiate what done means.

Imagine a Melbourne electrical contractor with eight staff who wants to replace a whiteboard, a shared calendar and a stack of paper job sheets with a job management web app.

The scope after discovery: one core workflow (a job is quoted, scheduled, completed with photos and signed off), three roles (office, electrician and administrator), and one integration with Xero so completed jobs become draft invoices. A plan for that project looks like this:

That is ten weeks, inside the 6 to 12 week range, with the Xero integration as the piece most likely to add time if the sandbox or the approvals are slow. The price would be quoted within the $15,000 to $40,000 web app range plus $1,500 to $5,000 for the integration, fixed once the scope is signed. How much does it cost to make an app explains how that price is built up.

Speed is a trade-off, and the thing usually traded away is testing. An app that launches a fortnight early and loses a week of invoices to a bug has not saved any time. We hold the steps fixed (discovery, design approval, sprint reviews, testing and the warranty) and move the timeline by changing the scope instead. If you need something live in six weeks, we will tell you what fits in six weeks and what should wait for stage two.

If a longer build is the honest answer, you will hear that too, with the reasons. The case studies for Reckonly and Scentena, two products our co-founder Anis built before ELORA DIGITAL, show where the time in a real build goes: not only the headline feature, but the sign-in, billing, security and review steps around it.

The timeline is written into the scope alongside the fixed price. You see every milestone, file and message in your client portal, so there is never a week where you wonder what is happening. Sprints end with a review every two weeks, decisions are recorded, and changes are quoted before they are built. To get a timeline for your own project, describe it on our quote page and you will have an estimate range within one business day. The written scope, with its timeline and fixed price, comes out of the paid discovery workshop.