Why web apps take months (when they shouldn't)
The causes are nearly always the same: a long feature list from day one, a design that has to be finished before any code is written, and postponed decisions that hold up the work. None of these is a technical problem. They are all solved by doing less, on purpose, and deciding earlier.
1. Find the one thing it must do
Every product has a core action, the reason it exists: booking, ordering, approving a request, looking something up. The first version has to do that one thing well, from start to finish, for real users. Everything else goes on a “later” list.
One question helps you choose: if tomorrow the web app did only this, would anyone use it? If the answer is yes, you have found the heart of the first version.
2. Write the scope down before you start
One page is enough: who uses the web app, what they need to be able to do, what data it needs and which systems it has to talk to. Above all, what stays out of the first version. Writing the exclusions down avoids mid-project debates, the most common cause of delays.
3. Design and build in parallel
Waiting for a finished design before writing any code adds weeks to the timeline. Instead we work in one-week cycles: design a part, build it, try it together with the client. The product takes shape as something that works, and problems surface while they are still cheap to fix.
What a typical timeline looks like
Every project has its own pace, but the sequence is almost always this:
| Phase | What happens | Typical length |
|---|---|---|
| Kickoff | Scope, users, data and access to existing systems | A few days |
| First screens | The main flow works, with real data | 1–2 weeks |
| Weekly cycles | The first version is completed, with a review every week | 2–4 weeks |
| Launch | Testing with users, fixes, going live | About a week |
The lengths are indicative: a project with many integrations takes longer, one with a single simple flow less. For Steelman, a custom e-commerce with its own admin, it took about seven weeks from kickoff to going live.
4. Use proven tools
The fastest projects use technology the team knows inside out, not the newest. Put the novelty into the product and the experience of the people using it, and keep the foundations solid and predictable. The same goes for outside services: for payments, email and sign-in it is better to rely on dependable, ready-made solutions than to rebuild them.
5. Put it in front of users early
Launch is when the learning starts. A focused first version lets you base the next decisions on what users actually do, rather than on guesses made in a meeting.
Where possible, launch first to a small group of real users, such as your own team or a few trusted customers. The main issues surface within days, and opening up to everyone comes with more confidence.
What we need from you
Speed depends on the client too. Three things make the difference:
- One person who decides, able to answer questions the same day and approve reviews.
- Access to data and systems in the first few days: management software, CRM, accounts for the services you use.
- One hour a week to try the web app and say what works and what doesn't.
If you run that process with ready-made software today, first ask whether it is really worth building: we cover that in Custom Software vs Off-the-Shelf. If you've already decided, tell us your idea and we'll tell you what can go into the first version.
Frequently asked questions
How long does it take to build a web app?
A focused first version usually takes four to eight weeks. It depends mostly on how many features go into the first release and how many existing systems need connecting.
Does faster mean worse?
No, as long as you cut scope rather than quality. A small, tested and stable first version is worth more than a big one full of half-finished features.
What happens after launch?
We watch how the web app is used and plan the next versions from the data. We stay with you for maintenance and to help it grow.
