How long does it take to build a website, web app or mobile app?

“When can it be live?” usually comes right after “how much will it cost?”, and the two are connected. A deadline that is too tight either raises the price, because more people must work in parallel, or lowers the quality, because something gets skipped. A deadline that is realistic from the start saves money and arguments.

This guide gives the typical timelines we plan for, explains where the time goes, and lists what you can do to shorten a project without cutting the parts that matter. The ranges are the ones we use in our own estimates for a website, a web application and a mobile app; other companies will have their own, but the reasons behind them are the same everywhere.

Typical timelines at a glance

• A single landing page for a campaign or service: under two weeks.
• A business website of roughly ten to forty pages: four to eight weeks.
• A focused first release of an internal web application, such as an order, job or booking system: eight to fourteen weeks.
• A customer-facing portal with payments and several integrations: three to six months.
• A focused first release of a mobile app, including store review: ten to sixteen weeks.

These are calendar weeks from kick-off, not from the first enquiry. Before kick-off there is usually a week or two of conversation, scoping and a written estimate, and longer if a paid discovery phase is needed first.

Where the time goes on a website

A business website moves through a predictable sequence: agreeing the page list and the purpose of each page, structure and wireframes, visual design, building on a staging site, content entry, search and performance checks, and launch. The development itself is rarely the slowest part.

The slowest part is almost always content. Final text for every page, photographs, team profiles and approvals from the people who must sign them off take longer than anyone expects, especially when the people writing are also running the business. A website with every word and image ready on day one can be launched weeks sooner than the same site where content is “nearly ready”.

The second slowest part is feedback. Each round of design or page review that takes a week instead of two days adds a week to the project. Over five or six rounds, that is the difference between launching in one month or three.

Where the time goes on a web application

Web applications take longer than websites because they hold business rules, data and permissions, and because the people who use them every day have strong, specific needs. A typical first release involves:

• Workflow mapping: understanding how the process actually works today, including the exceptions nobody mentions in the first meeting.
• A clickable prototype that users try before code is written. Most major corrections happen here, cheaply.
• Data model and architecture, agreed and written down.
• Build in two-week cycles, each ending with a review on a staging site.
• Testing with realistic data, then acceptance testing by your team.
• Rollout: importing existing data, training users and running the old process alongside until people trust the new one.

Integrations are the most common source of delay. Connecting to accounting software, an ERP, a payment gateway or WhatsApp depends on what those systems allow and on getting access from whoever controls them. It is worth requesting credentials and documentation in the first week, not the eighth.

Where the time goes on a mobile app

A mobile app has all the stages of a web application, because most apps need a back end and an admin panel, plus some of its own:

• Device testing across a representative range of phones, including the budget Android models many users carry.
• Offline working, if needed, which takes careful design and testing.
• Developer accounts. Google Play and Apple developer accounts should be in your organisation’s name. Apple requires an organisation to have a D-U-N-S Number to enrol in its Developer Program. If you do not have one, request it at the start of the project, because waiting for it at the end can hold up the launch.
• Store review. Each release is reviewed by Apple and Google before it goes live. Plan several days for it, and more for a first submission, which may come back with questions about privacy declarations or content.

What slows projects down

Across all three, the same few causes account for most delays:

1. Unclear scope. If the must-haves are not agreed in writing, they grow during the project. Each addition is small; together they add months.
2. No single decision-maker. When three people must agree on every screen, and they are rarely in the same room, decisions take weeks.
3. Late content. For websites, this is the biggest single cause of delay.
4. Late access. Domain logins, hosting, payment gateway accounts, API keys and app store accounts that take weeks to locate or open.
5. Slow feedback. Reviews that wait a week for a reply.
6. Testing squeezed at the end. When acceptance testing finds problems in the final week, the launch slips anyway, with more stress.

How to launch sooner without cutting corners

• Launch in phases. Agree a first release that is genuinely useful and small, and put the rest into a second phase. Real use will reshape phase two anyway.
• Name one decision-maker with the authority to approve designs and scope, and agree a turnaround time for reviews, such as two working days.
• Start content on day one. If you are writing the copy, start before design is finished. If the vendor is writing it, give them access to the people who know the business.
• Gather access early. Make a list of every account the project will need in the first week, and open the ones you do not have.
• Review working software, not documents. Ask for a staging site or test build every one or two weeks, and actually use it.
• Use proven services for payments, messaging, maps and login rather than building your own.

When a fast deadline is real

Sometimes a date genuinely cannot move: a trade fair, an admissions season, a product launch, a festival sale. In that case, say so at the start and explain why. A good vendor will then propose a scope that can be delivered properly by that date, rather than promising everything and missing it. For a website, that might mean launching the most important pages first. For an app, it might mean launching on Android first, or as a web application while the store version is completed.

Be wary of anyone who agrees to an aggressive deadline without asking about content, integrations or decision-making. Either they have not understood the project, or they plan to skip something.

How we plan timelines

Every estimate we send includes a timeline with milestones, the assumptions behind it, and what we need from you to keep it: content, access and review turnaround. We show working software every fortnight, so you can see progress rather than take it on trust. For more on how projects run, see our delivery process, our guide to scoping a project before asking for quotes, and our articles on website costs and app development costs. If you are in Delhi NCR, read about working with us as a website design company or mobile app development company in Delhi, or request a quote from anywhere in India.