A first working version in a few weeks, not a year

How long before an application built for your business is actually usable? A few weeks, for a first use case that genuinely works, not a year of specifications before the first line of code. But that short answer hides a method worth understanding before you trust it.

Why a software project usually drags on#

The most common instinct is to want full control before signing: months of specifications, every screen described, every rule written down on paper. The idea makes sense, but it starts from a false premise: that someone can describe a tool they have never used.

The site manager finds out at delivery that the screen asks for six fields where he fills in two on site. The distributor notices that the approval path drawn on paper doesn't match the one his team actually follows. Every gap becomes a change order, and that is what inflates the timeline, not technical difficulty.

What we look at before writing a line of code#

Before building, we spend one to two days with the business: what we call the audit. It doesn't produce a months-long document. It answers three questions:

• What is the costliest problem today? The one losing the most time, or the most money.
• Who will use it, and under what conditions? Standing on a site, sitting at a desk, between two deliveries.
• Which existing tools need connecting from day one? Payroll, accounting, a system that has to stay in place.

This short piece of work doesn't need to be long to be useful: its purpose isn't to describe everything, but to know precisely what to build first.

Choosing the right starting point#

The first block built is never picked at random, or because it is the easiest to code. It follows one simple rule: start with what pays off most, not what ships fastest.

For a renovation contractor, this first block is often quote tracking. For a distributor, goods receiving. The choice is made with the business, not for it.

I don't know how many of you are behind this, or how long it's going to take.

It's a fair question, and the answer lies exactly in this breakdown: you aren't asked to take a twelve-month plan on faith. You see a first block running, on a real case, within a few weeks.

What changes with an application built block by block#

Instead of one large project delivered all at once, the application is built in successive blocks, each one replacing an existing tool instead of adding to it.

In practice:

• the first block is live while the next one is being prepared, and it is already useful day to day;
• feedback from the team comes through a tool they use every day, not through a meeting report;
• everyone sees what concerns them: the owner their daily figure, the manager their team, the field their task list;
• you can see the application and the code at any time, without waiting for a progress update.

You can see an example of this approach in our demo for a renovation contractor, and the full process is described on the your application page.

What a first version doesn't do yet#

A first version doesn't cover everything, and that isn't a flaw. It deliberately leaves out secondary uses, rare cases, and connections that aren't needed yet. Adding them too early would repeat the mistake of the full specification: guessing before anyone has seen the tool actually work.

What matters in the first few weeks isn't the list of features shipped, but the fact that someone genuinely uses it, on a real case, instead of whatever they did before.

A first version in a few weeks: the key takeaways#

A custom project doesn't need a year to be trustworthy. It needs a short audit that identifies the right starting point, then a first block built for that single use and put into service quickly.

If a project at your company has already taken longer than planned with nothing running, the question to ask isn't "when will it be done", but "what can I see working this week". The most common causes of a project going off the rails almost always start with no answer to that question.