How long does it take to build a web app?

For an internal tool with a clear process behind it, six weeks to a first working version that people use on real data is a reasonable expectation. Anything quoted in days is either tiny or optimistic; anything quoted in quarters usually means nobody has scoped it.

Why does it take six weeks and not six days?

Almost none of it is the interface. It goes on deciding what the rules actually are, getting data out of systems that resist it, handling the exceptions nobody mentioned in the first meeting, and the approvals and permissions that turn a prototype into something a team can rely on.

What makes an internal tool take longer than estimated?

Four things, in order: nobody can state the rules; a system has no usable API; there is no single decision-maker; and scope grows during the build. Three of those are visible before anyone writes code, which is why the scoping call matters more than the estimate.

Can you build it faster than six weeks?

Often, by building less. A tool that handles the main path well and leaves the twice-a-year exceptions manual can ship in two or three weeks and is usually more useful than a complete one that arrives in month five.

// Journal · Sep 24, 2026 · 4 min read

How long does it take to build an internal tool?

How long does it take to build an internal tool? For a web application with a process already behind it, six weeks to a first working version your team uses on real data — with something running to look at every week along the way. Anything quoted in days is either very small or optimistic about the exceptions. Anything quoted in quarters usually means the work has not been scoped, only estimated.

The more useful question is what consumes those six weeks, because it is almost never the part people picture.

Where the time actually goes

Deciding what the rules are: 1–2 weeks. Consistently the largest and least expected cost. “Approved” turns out to mean three different things to three departments. Nobody can say what happens when a record arrives without a customer reference. These are not technical questions and they cannot be answered by engineers, but they must be answered before the behaviour can be written down.

Getting at the data: a few days to a fortnight. If the systems involved have usable APIs, this is quick. If one is a hosted product with no export, it becomes the largest unknown in the project — and it is knowable in week one if anyone asks.

Building the thing: 1–2 weeks. The part everyone budgets for is rarely the constraint. Forms, tables, validation, permissions and an audit trail are well-trodden work.

Exceptions and approvals: 1–2 weeks. The long tail. Who can override. What happens to a half-finished record. How corrections are made without destroying the audit trail. This is where “nearly done” lives for longer than anyone expects.

The four things that triple an estimate

Three of these are visible before a line of code is written, which is why we would rather spend thirty minutes on a call than produce a fast quote.

Nobody can state the rules. If the process lives in one person’s head and that person is busy, the build is blocked on their calendar, not on engineering. This is the same failure that makes automation projects fail — the software is not the bottleneck.

A system has no usable API. Sometimes there is a database connection or a scheduled export. Sometimes an agent has to drive the interface, which works but costs more and is more fragile. Establish this first.

There is no single decision-maker. Two stakeholders who disagree will discover it mid-build, and the disagreement becomes a rework cycle. One named owner who can settle questions inside a day is worth more to a timeline than an extra engineer.

Scope grows during the build. Weekly demos make this visible, which is precisely their purpose — a request that arrives in week two can be traded against something else. The same request in week five cannot.

Shipping faster by building less

The reliable way to compress a timeline is not more people. It is a smaller first version.

Handle the main path properly — with validation, permissions and an audit trail — and leave the twice-a-year exceptions manual. A tool covering 80% of cases that arrives in three weeks earns its keep immediately and tells you which of the remaining 20% actually matter. A complete one that arrives in month five is being specified against a process that has since changed.

That is the same principle as the review queue: ninety percent handled automatically with a fast human path for the rest beats a hundred percent that is late.

How we run it

A 30-minute call where we say honestly whether the thing is scoped enough to quote. A written scope with a fixed price and a delivery date. A working demo every week — not a status update, the software running on your data. Handover where you own the code and the accounts.

Six weeks is the ceiling for a first working version, not the target. If something cannot be delivered in that window, we scope the first useful slice rather than disappearing for a quarter.

The same timeline holds for mobile applications, with one extra constraint: store review sits between a fix and the people using it, so the cost of a wrong assumption is days rather than minutes. That is an argument for testing on real devices earlier, not for a longer build.

Havoric is an AI automation and web development agency based in Ahmedabad, India, working with clients worldwide. Internal tools are the core of our web application work, and they often sit on top of an automation that was previously somebody’s morning.

Common questions

How long does it take to build a web app?: For an internal tool with a clear process behind it, six weeks to a first working version that people use on real data is a reasonable expectation. Anything quoted in days is either tiny or optimistic; anything quoted in quarters usually means nobody has scoped it.
Why does it take six weeks and not six days?: Almost none of it is the interface. It goes on deciding what the rules actually are, getting data out of systems that resist it, handling the exceptions nobody mentioned in the first meeting, and the approvals and permissions that turn a prototype into something a team can rely on.
What makes an internal tool take longer than estimated?: Four things, in order: nobody can state the rules; a system has no usable API; there is no single decision-maker; and scope grows during the build. Three of those are visible before anyone writes code, which is why the scoping call matters more than the estimate.
Can you build it faster than six weeks?: Often, by building less. A tool that handles the main path well and leaves the twice-a-year exceptions manual can ship in two or three weeks and is usually more useful than a complete one that arrives in month five.