Guide

How long does a software project take, and what makes it take longer?

Anyone who gives you a single number before understanding your project is guessing. Duration depends on scope, on how many people can work in parallel and, just as much, on how quickly your side can decide, supply content and give feedback. This guide shows what drives the timeline and how to plan for it.

Key takeaways

Duration = effort ÷ how much can run in parallel, plus waiting time.
Waiting for content, decisions and approvals is the biggest hidden cause of delay.
Adding people does not shorten a project in proportion, and can slow it.
Plan with a buffer, and for Hong Kong public holidays and bad-weather days.
Examples below are illustrations from our own model, not promises.

What drives the length

Scope. More screens, user types, rules and integrations mean more work. This is the biggest factor, and the one you control most.
Uncertainty. Unclear requirements and untried integrations add discovery time, and rework when assumptions prove wrong.
Your speed. Every approval, piece of content and answer that arrives late stops the clock for the team.
The number of people who must agree. One decision-maker is fast; a committee is not.
Outside parties. Payment provider onboarding, app store review, data from a supplier and legal checks all have their own timelines.
Quality work. Testing, fixing, accessibility and bilingual content are part of finishing, not extras.

Three illustrations

Our cost estimator turns a description into effort in person-weeks and an indicative calendar time, using stated assumptions about team size. For three typical descriptions it gives:

A bilingual marketing website. About 6 person-weeks, roughly 4 to 7 weeks on the calendar with a team of two.
A web booking system with online payments, an admin area, notifications and two languages. About 19 person-weeks, roughly 7 to 11 weeks with a team of three.
A cross-platform app with accounts, payments, an admin area, notifications and one or two integrations. About 29 person-weeks, roughly 7 to 12 weeks with a team of four.

These are illustrations of the model, not promises. They assume a clear brief and prompt decisions, and exclude time spent waiting on third parties. Real projects often take longer for the reasons in this guide.

Why projects overrun

Scope grows quietly. Each “small” addition is cheap on its own and expensive in total. Keep a visible list, and decide consciously.
Content is late. Text, photos, translations and product data are needed before launch. Start them on day one.
Feedback arrives in lumps. A fortnight of silence then forty comments costs more than steady weekly input.
Integrations behave differently than the documentation says. Test the riskiest ones first.
Everything is tested at the end. Problems found late take longest to fix. Ask to see working software regularly.
The team is not fully available. A person split across several projects is slower than the hours suggest.

Planning a realistic date

Ask for effort and calendar time separately, with the assumptions behind each.
Add a buffer. Fifteen to thirty percent is common, more where scope or integrations are uncertain.
Count real working days. Hong Kong's general holidays, Lunar New Year and bad-weather days all take time away. Our project timeline planner turns working days into a calendar date and can work back from a deadline.
Agree your own deadlines for content and decisions, and write them into the plan.
Release in stages. A smaller first release arrives sooner and teaches you more. See planning a first release.

Frequently asked questions

Can adding more developers make it faster?

Only up to a point. More people mean more coordination, and some work cannot be split. Adding people late in a project often slows it down.

How long does app store review take?

It varies and is outside anyone's control, from hours to several days, and a rejection means resubmitting. Plan some days of margin before a launch date, and check the current guidance from Apple and Google.

Is a rushed project always worse?

Not always, but speed is bought by cutting scope, adding people or accepting risk. The safest way to hit a date is a smaller first release, not a squeezed schedule.

Working to a date?

Tell us the deadline and what has to be ready by then. We will say what is realistic and what to cut.

Request a project quote