Behind the question of how long it takes to develop a web application, there’s almost always a date. A licence that’s expiring, a seasonal peak the current system can no longer handle, budget that has to be spent this year. The short answer: a well-defined portal usually goes into production within a few months, while a platform with several user roles and integrations tends to need six months or more.
You can’t plan against a range like that, though. For that you need to know how the project is structured. So here are the phases as we run through them on our own projects: what happens at each step, where the time actually goes, and which moment matters for your planning.
Getting clarity before anything gets built
The first phase is a four-week exploration. It doesn’t start with code, but with the questions that shape the rest of the project:
- which process the application needs to support, including its exceptions
- who will work with it and what permissions each group of users needs
- which systems the application needs to exchange data with
- what deliberately stays out of the first version
That last question carries the most weight for your timeline. Every feature that can wait for a later version shortens the road to go-live. For how to draw that line sensibly, see our article on the difference between an MVP, a deliberately limited first version, and fully built-out software.
A clickable prototype before development starts
The exploration phase doesn’t end with a report, but with a clickable prototype: before development even starts, you click through the key screens and recognise your own way of working in them.
That early moment isn’t a formality. It’s only once people click through a prototype that you find out what stayed unsaid in the conversations: the exception nobody mentioned, the step that works differently in practice than it does on paper. The sooner that surfaces, the smaller the correction.
Build rounds you can steer
After that, the application grows in four-week rounds, each ending in a working version. You check in along the way, give feedback, and help decide what the next round delivers. Testing happens within every round, not as a final step right before go-live.
This is where most delays arise, and rarely because of the coding itself. Integrations with external systems bring waiting time with them: requesting documentation, getting access arranged, waiting for replies. And once the first version is running, new ideas start coming in. They’re welcome, but they belong on the list for a later version. A project that keeps growing during the build rarely arrives on time.
There’s more time around go-live than you’d expect
In a well-prepared project, go-live itself is a matter of hours. The weeks around it aren’t. Existing data has to be transferred and checked, colleagues need to learn to work with the new application, and the old system often keeps running alongside it for a while as a safety net. Budget a few weeks for all of this, and don’t plan the switch in your busiest month.
The clock doesn’t stop there, either. The first weeks in production teach you more about your application than any test round before it. So leave room for refinements shortly after launch, rather than spending the whole budget on the build right up to the last day.
Want to know whether your date is realistic? Work backwards: a few weeks for rollout and go-live, before that a number of build rounds that depends on your wish list, and at the start a four-week exploration. Or bring us your challenge; based on your process and your systems, you’ll get a planning you can test against these phases. See how we develop web applications and portals.