How long it actually took: three builds, with dates

Every published answer to this question is a range, and the ranges are wide enough to be unfalsifiable. "Four to twenty weeks." "Six to twenty-four weeks." We fetched eleven agency pages answering this exact question on 11 August 2026 and not one of them named a project, a start date and a launch date. The two that came closest both turned out to be hypothetical.

So here are ours. Three real builds, the dates taken from the version history rather than from memory, and — because a timeline without its conditions is just a boast — what those dates do not show.

Build one: a commercial property system

A UK commercial-property firm's whole portfolio: every occupier, unit and lease, the key dates, the documents, a portfolio map, and board packs that draft themselves.

• 6 June 2026 — the repository is created.
• 1 July 2026 — the full multi-tenant application is committed: the public site, the staff portal, groups, property search, team invitations.
• 15–16 July 2026 — a feature wave built from a recorded call with the client, shipped to the live system inside five days.
• 13 August 2026 — the twenty-third database change goes in. It is still being changed today.

So: about three and a half weeks from an empty repository to a system a firm runs its portfolio on. That is faster than any range on page one of Google, and you should be suspicious of it. The next section is why.

Build two: this website

Designed and built between 9 and 20 June 2026, launched with a working contact form on 1 July 2026. Redesigned and relaunched on 28 July 2026, because the first version sold the wrong thing — the business had changed underneath it and the site had not caught up.

That second date matters more than the first. A website is not finished when it launches; it is finished when it stops being wrong, and ours was wrong about what we sold within a month of going live.

Build three: turning one client's system into a product

TenureBook is the property system above, rebuilt as something anyone can buy.

• 15 July 2026 — forked out of the client's system as a separate product.
• 29 July 2026 — a real purchase runs end to end for the first time: payment taken, workspace created, welcome email delivered, sign-in working.

A fortnight — but only because the hard part had already been built once, for somebody else, and paid for. Starting a product from nothing is a different job with a different number.

What those dates do not show

This is the part the ranges leave out, and it is the part that decides what your build will take.

The first one started from something that already worked. Before 6 June there was a single-file HTML tool one person had built for himself and used. The concept was proven, the fields were known, and the arguments about what it should do had already happened. Three and a half weeks does not describe designing a system from a blank page — it describes rebuilding a proven one properly.

The client answered within hours. Every question — what should this field be called, does a lease ever have two break dates, who is allowed to delete a company — came back the same day. That is not normal, and it is worth understanding why it matters so much. When we say a build stalled, it almost never means the code stopped. It means we asked something and waited.

Live is not finished. Twenty-three database changes have gone into that first system since it went live, the most recent on 13 August. Some are features the firm asked for. Some are things we got wrong. In the third week after go-live we found a hole in the permissions — a role that could hand out admin rights it should not have been able to — and fixed it in two migrations on 15 July. If our timeline had ended at "live", you would not know that.

Calendar time and build time are different numbers

Nobody separates these, and every buyer question is really about the first.

Build time is how many days of work the thing takes. It is the number a supplier can estimate, and it is the number every published range describes.

Calendar time is how long it is before you are using it. It is build time plus every day nobody could move because a decision had not been made, a spreadsheet had not been sent, or the person who knows how the renewals actually work was on holiday.

For a small firm buying from a small builder, calendar time is dominated by the second part, not the first. Which leads to the only piece of advice in this guide that will change your date:

Pick one person who can decide, and give them an hour a week. A build with a decision-maker who answers in a day moves at roughly twice the pace of the same build with one who answers in a week — and it is the same amount of work either way.

What we would tell you to expect

We are not going to give you a range, because that is what this whole guide is about. What we will say is how we would shape it:

• Something usable early, on real data. Not a mock-up. If you cannot open the thing and put a real record in it within the first few weeks, you have no way of knowing whether it is going the right way.
• Your records in it as soon as it can hold them. Migration is where these projects actually fail, and finding out in week two is survivable in a way that finding out in week ten is not. We have written about why.
• A date you both understand the assumptions behind. Any date is conditional. It is only a real date if you know what it assumes about how fast you answer.

What to ask, and what a good answer sounds like

Ask any supplier: "What is the last thing you built, when did it start, and when did somebody first use it in earnest?"

You are not testing whether the number is impressive. You are testing whether they have one. A supplier who works from real dates will tell you what slipped and why; a supplier who works from ranges will give you a range, because that is all they have.

The second question is better still: "What have you changed since it went live?" Everything is changed after it goes live. Somebody who says nothing was is telling you either that nobody used it or that they stopped answering the phone.

If you want the same for a build you are weighing up, tell us what you are trying to replace and we will tell you what it would take and what that assumes about you.