How long custom software development takes

Benchmarks, by project type

A complete project, from the first meeting to the day the tool is genuinely used, generally finishes within a month. Meetings, back and forth and approvals included. The durations below cover the build itself, inside that month.

• An internal tool replacing a spreadsheet or a manual process: one to two weeks of build.
• A product configurator: one to two weeks, catalogue and visuals aside.
• An automated processing pipeline, images or documents: one to two weeks.
• A client portal connected to an existing system: one to two weeks.
• A complete multi-role business platform: delivered in successive stages, each at the same pace.

These durations hold under four conditions worth checking before relying on them: a held scope, usable data, accessible existing systems, and a number of users that imposes no particular security or approval constraints. Change one of the four and the schedule changes with it.

Where the time actually goes

The breakdown surprises people. On a one-month project, development itself rarely occupies more than half the calendar.

The rest splits between three lines, none of which appears on a development plan: understanding the business and writing the rules, obtaining access to existing systems, and preparing the data that will be used.

Access is the line nobody anticipates, and the most damaging. Getting read rights on a production system often involves a long-standing supplier, a security officer and sometimes an outside vendor. Three weeks of waiting is not unusual, and it always lands at the moment the team is ready to build.

That is why a project's very first action is not a framing meeting, it is an access request. It costs nothing, blocks nobody, and removes the most common risk.

Data preparation is the second. A clean reference base speeds everything up; an approximate one turns every feature into a negotiation, because you have to decide, case by case, what is true.

The three causes of slippage

Three causes explain most projects that drag, and none is technical.

• No arbiter. A project with one person deciding moves. A project with four equally legitimate opinions spends its calendar in meetings.
• Scope expanding along the way. Each addition looks modest on its own; accumulated, they double the duration without anyone noticing when it happened.
• Deferred approval. A tool waiting three weeks for a review loses those three weeks, and loses them twice, because the feedback then arrives bundled and contradictory.

Conversely, what almost never stretches timelines: technical complexity identified at the start. It is estimated, planned, and unfolds as expected in the vast majority of cases.

Fix the date before the scope

The most effective method sounds counter-intuitive: fix a go-live date before fixing the scope, then adjust the scope to hold the date.

And yet it produces the best results. A team that knows it ships within a month naturally decides what can wait, and those decisions are almost always right: half the features requested at the outset are never asked for again once the tool is live.

Two practices usefully complete the approach. Put a partial version into real use on a restricted scope rather than waiting for the complete version. And plan, from the initial schedule, one week after go-live for fixes: it will exist anyway, so it may as well be owned.

Finally, a weekly thirty-minute meeting with the decision-maker beats a monthly two-hour one. Questions get asked when they arise, and settled in days rather than weeks.

What a short schedule says about a project

A short announced timeline is not a sign of carelessness, often the opposite. It indicates a held scope and decisions taken.

We put a shipyard's configurator live in twelve days. That figure does not say the work was simple: it says the sales director had the catalogue and the rules in his head and agreed to spend a day or two on them from the start.

Conversely, a supplier announcing six months for an internal tool described in one page deserves a question: what exactly takes six months? The answer is instructive.

The good sign in a proposal is the presence of an intermediate production release. A project producing nothing usable before its last day is one whose real progress nobody knows.

The same subject from the budget side: what custom software costs

Go-live is the middle of the project

The two weeks after go-live produce more information than the entire design phase, because they confront the tool with real use rather than imagined use.

Plan that time explicitly: a few days of immediate fixes, then a review at ten days to handle what use has revealed. It is short, and it is what turns a delivery into an adopted tool.

After that comes a cruising rhythm, a few hours a month to follow changes in the business. A tool that no longer moves at all is usually a tool that is no longer used.

And if you have a deadline to hold, say so in the first meeting rather than the third. A constrained calendar is useful information: it changes how the scope is built, and it often produces a better tool.