How long does custom software take to build?

The number most companies are quoted

Panorama Consulting's 2025 ERP Report puts the average implementation at nine months, down from fifteen and a half the year before. That figure covers packaged systems rolled out by vendors and integrators, and it is the timeline a director in Malaysia is usually shown: a quarter for discovery, a quarter for configuration, a quarter for testing and go-live. Custom software has a reputation for taking longer still, because it is assumed to start from nothing.

What we count instead

We count days from the commit history of systems that are already in production. A commit is a dated record of code that shipped, so the count is a measurement, not an estimate. Four recent examples, all from one company, an 800-person engineering consultancy that runs its daily field operations on our system:

• One day. Five changes were asked for at an 08:30 walkthrough on site on 17 August 2026: free-text box IDs with type-ahead, hand-offs in batches, hand-offs to third parties, registration on the web, and several photos per hand-off. All five were live on the web and on staff phones by that evening.
• One week. A purchase-to-pay workflow, from requisition through quotations, approvals, purchase orders printed on the company's own PO paper, deliveries and payments, with a catalogue of 1,269 items, went from go-ahead to live on production between 10 and 17 August 2026.
• Seven build days. An event and venue booking module took four days on the web and three on the phone between 31 July and 10 August 2026, and was on both app stores by 13 August.
• Seven days. A company-wide assistant went from the idea on 11 August to live for its first users on 18 August.

Why it is fast

Three reasons, none of them heroic.

• Every module starts on a platform already in production. Sign-in, permissions, the phone app, the web app, notifications and document output exist before the first line of the new module is written. A new workflow is added to a working system rather than built from a blank page.
• We work beside the people who do the job. The walkthrough on 17 August was on site with the staff who handle the boxes. Requirements gathered that way do not need a month of workshops, and the first version is tested by the people who asked for it, the same day.
• One codebase ships to phones and the web. The purchase-to-pay workflow lives on the web, the booking module needed both, and the site changes went to phones and the web from the same change. There is no second team and no second schedule.

What "days" does not mean

A first version in days is not a finished system in days. The purchase-to-pay workflow went live in a week; the procurement manager's first day of testing produced thirteen screenshots of feedback, and most of it shipped the same day. Speed matters at the start because it puts a real system in front of real staff early, and their use is what shapes the next version. The alternative, a long build followed by a long training programme, produces a system that fits the requirements document and not the company.

How to read a vendor's timeline

Ask what staff will be able to use on the first date they give, not what will be "delivered". Ask whether the timeline includes the phone app. Ask what happens when a manager asks for a change in month four, and what that costs. The honest answers to those three questions tell you more than the total.