How long does a web application really take to build?

Almost every vendor will say three months. Almost every project finishes in six to nine.

Not because they are all lying. Because three months is the answer to a different job from the one eventually done — and nobody counts the difference up front.

This article gives honest ranges, the reasons behind them, and how to check whether the schedule you were given is credible.

The five things that most often cause overruns

Note that none of these is about writing code more slowly. The code almost always finishes on estimate. What slips is everything around it.

• Decisions waiting. One person must approve a particular screen design but is away for two weeks. The project stops — not for technical reasons, but because nobody decides.
• Messy legacy data. The plan is to migrate data from the old system. On inspection there are four different versions of the customer number and nobody knows which is right. Cleaning it up alone can take a month.
• Requirements that appear after seeing the result. This is normal and healthy. What is not healthy is failing to budget for it from the start.
• Third-party integration. Payment gateways, shipping services, or an old finance system. Each has documentation of a different age, and some of the documentation is wrong.
• Testing that turns into extra requests. Users try it, find things they had not thought of, and the request list grows quickly.

Four of those five are not developer work. They are business decisions and data readiness. Which means most delay cannot be fixed by adding more programmers.

Realistic ranges, by type of work

The ranges below are general experience for work done carefully, not promises. Projects that finish far faster usually skip one of the items above, and that shows up later.

• One flow, one purpose, no integration: 3 to 6 weeks. Example: an online registration form with a simple admin panel.
• A single-module internal application with login and access control: 2 to 3 months. Example: asset records with QR codes.
• An application with two or three modules and one integration: 3 to 5 months. Example: point of sale plus stock plus sales reporting, connected to a payment gateway.
• A system with many roles, many branches, and approval flows: 6 to 12 months. Not because there is more code, but because there are more decisions.

Notice the pattern: time grows not in proportion to the number of features, but in proportion to the number of people who must approve something.

How to check a schedule you have been given

If a vendor gives you a single number for the whole project, ask for the breakdown. A credible schedule is almost always staged, with something usable at each stage.

• Ask for the schedule per stage, not one end date. Ask: what can I use after week four?
• Ask how much time is allocated to waiting for your decisions. If that number is zero, the schedule is not realistic.
• Ask what happens if one third-party integration turns out harder than expected. A good vendor has already thought about this and has a fallback.
• Ask how the project could be stopped halfway. Not because you plan to stop, but because a vendor with no answer to this usually has no clear plan either.

How we build a schedule

We write the schedule per stage with something you can test at each stage, not one distant end date. The first stage is usually two to four weeks and produces something genuinely usable, even though incomplete.

We also write the expected waiting time for your decisions separately from the working time. That often makes the total schedule look longer — and it is longer. But a schedule claiming it needs no waiting on anyone's decision is a schedule that will slip.

If, after the first conversation, we judge your deadline unachievable, we will say so before you pay anything.

The next step

If you have a specific deadline — a product launch, a peak season, or a requirement from head office — send it with the date. We will reply with two things: whether it is possible, and what must be sacrificed if it is forced.

We would rather tell you now that the deadline is unrealistic than give you a schedule that feels good today and then disappear in month three.