The honest answer is that calendar time and effort are different things, and most schedule overruns come from the calendar, not the engineering. Here are realistic ranges, and where the weeks actually go.
Ranges by size
- Simple internal tool: 6–10 weeks. One workflow, one user type, a couple of integrations.
- Customer portal or line-of-business app: 3–6 months. Several roles, permissions, documents, notifications, real integrations.
- Multi-role platform: 6–12 months, and it should be phased so something useful ships at month three.
- Legacy replacement: 9–18 months, dominated by data migration and by rediscovering rules nobody wrote down.
These assume a team that is actually available. "Three months" from a firm juggling four projects can mean six, and that is worth asking about directly.
Where the time goes
For a typical four-month build:
- Discovery and specification — 2 to 4 weeks. Feels like delay, prevents months of it.
- Design — 2 to 3 weeks, overlapping the end of discovery.
- Build — 8 to 12 weeks, in two-week increments with something demonstrable at the end of each.
- Data migration — 2 to 6 weeks, running alongside the build, then rehearsed at least twice.
- Testing and fixes — 2 to 3 weeks. Routinely compressed, routinely regretted.
- Deployment and training — 1 to 2 weeks.
What genuinely runs in parallel — and what cannot
Can: design alongside late discovery; migration scripting alongside the build; documentation alongside everything.
Cannot: building before the data model is settled; testing before there is something to test; user acceptance before the workflow is complete. Adding people to these phases makes them slower, not faster — a real constraint that is easy to forget when a deadline is under pressure.
Four things that add months without adding features
- Slow decisions. A question that waits a week for an answer costs a week. This is the most common cause of overrun and it sits entirely on the client side. Name one decision-maker with authority.
- Third-party access. Waiting on API credentials, a vendor's sandbox, or a security review from a system owner who did not know they were in scope. Start these on day one.
- Late scope changes. Each one is small. Together they are a month. Keep a phase-two list and put things on it rather than arguing about them.
- Data that is worse than described. Almost universal. Get a real export in front of the team in week one, not week ten.
How to genuinely go faster
- Cut scope, not phases. Shipping less is fast. Skipping testing is not — it just moves the time to after launch, with users watching.
- Ship the first useful slice early. One complete workflow in production beats five half-built ones, and it starts generating feedback that improves everything after it.
- Clean your data in parallel. Work you can start today without a contract.
- Reuse. Authentication, notifications, payments, file storage. Buy these; nobody needs a bespoke login screen.
- Answer questions within a day. The cheapest schedule improvement available to you.
The estimate to distrust
Be wary of anyone who gives a confident timeline in the first meeting. They have not seen your data, met the systems they must integrate with, or found the exception that runs through your whole process. A serious firm gives a range, names its assumptions, and offers a paid discovery phase to narrow it.
For what that costs, see our web application pricing breakdown. If you are still deciding whether to build at all, custom versus off-the-shelf is the better place to start.
Tell us what you need and when you need it — we will tell you honestly whether the date is achievable.