How long does custom software take to build?

How long does custom software take to build?

A focused business system usually takes six to twelve weeks. A connected platform usually runs three to six months, delivered in phases with something usable at the end of each.

These are planning ranges, not commitments. A real schedule is agreed in writing once the scope is settled, and anyone giving you a date before that is guessing.

What actually sets the schedule

Rarely engineering speed. Three things, in order:

How quickly decisions arrive. Every project reaches points where only you can decide: which of two workflows is correct, what happens to the exceptions, who is allowed to see what. A decision that takes a week takes a week off the delivery date, and these compound.

How quickly access arrives. Credentials, an API key from a vendor, an export from the system being replaced, someone to answer questions about how the old process really works. Waiting on access is the most common cause of a slipped date in this kind of work, and it is almost always a scheduling problem on the client side rather than an unwilling one.

How much of the current process is actually written down. If it lives in one person’s head and that person is busy, discovery takes longer than the build.

Where the time goes

A typical focused build, roughly:

• Week one to two. Discovery, workflow mapping, decisions recorded, data looked at properly rather than described.
• Week two to six. The core: records, workflow, permissions, the main screens. Usually visible to you from early on.
• Week five to eight. Integrations, which is where estimates move, because someone else’s API is someone else’s quality.
• Final two weeks. Migration, real data, training, handover, and the period where we are still on the hook.

Phases overlap. The ordering matters more than the boundaries.

Why phases beat a big launch

A system delivered in one piece after four months is four months of risk with no feedback. Phased delivery puts something real in front of the people who will use it early, which is when you find out that the workflow you described is not quite the workflow that happens.

It also means a budget can stop between phases with a working system rather than a half built one.

What makes a project late

• Scope added without a date moving, which is the classic
• An integration with a system that turns out to have no usable API
• Migration from data that is messier than anyone admitted
• A decision maker who is unavailable for two weeks at the wrong moment
• Starting a build while the business is still deciding what it wants, which is the case a Systems Blueprint exists to prevent

Rush work

Some projects genuinely cannot wait. Rush delivery is 25% of the implementation subtotal, it is stated up front, and it buys sequencing and priority rather than a different engineering team.

It does not make an integration with a slow vendor faster, and we will say so rather than take the uplift.

What to do next

Describe your problem and the preliminary plan includes phases and an indicative timeline. If the scope spans several systems, a Systems Blueprint produces the sequencing before anyone commits to dates.