From a website to a working product in fourteen weeks

The brief was a website. A founder with a business-to-business software idea needed a page that explained it, a way for prospects to get in touch, and something to show investors. Reasonable, and a few weeks of work. By the end of the first conversation it was clear the website was not the problem.

The situation

The founder had customers waiting. Not interest, customers. Companies that had said yes in principle and were waiting for something to use. The founder was planning to build a website first, raise on the strength of it, and then hire a team to build the product. That is a year. The customers were not going to wait a year.

What the founder actually needed was a first version of the product that the waiting customers could use, with a website in front of it that said the same thing the product did.

What we were asked, and what we proposed

We were asked for a website. We proposed a product, a smaller one than the founder had in mind, with the website as its front door. The question the first version had to answer was not will anyone want this. People already did. It was will they use it twice, and can we deliver it at a cost that works.

That question shaped everything about the build.

What we did

A two-page brief. The question the version existed to answer. The first users, by name. The three things a user must be able to do. What would be measured from day one. What was deliberately left out, written down so nobody added it back in week six.

One room. The people building the product and the people who would have to sell it sat together from the first week. The landing page and the product were written from the same sentence. Tracking was designed with the features, not after them. When a customer question changed the product, it changed the marketing the same day.

Built simply, built to be replaced in parts. No roles and permissions nobody had asked for. No settings screens. Tools the team knew rather than tools that were fashionable. Clean enough that a future in-house team could pick it up without starting again, which is the point of a first version that works.

The founder owned the decisions. We built. The founder decided. Ambiguity was resolved within a day, because we had agreed at the start who resolved it and how fast.

What happened

Version one shipped in fourteen weeks. The waiting customers used it. The website in front of it described what they were using, not what was planned, so the first conversations with new prospects matched the product they were shown. The founder raised on a working product rather than a page about one.

The founder's own description of it is the one we use. We came for a website and left with a working product. Because the marketing and engineering people sat in the same room, nothing got lost in a handover.

What was left out, and why it mattered

The list of things we did not build was longer than the list of things we did, and it was written down on the first day. Roles and permissions, because the first customers each had one user. Billing, because the first customers were invoiced by hand and that was fine for fourteen weeks. Integrations with other tools, because nobody had asked for one yet. Settings screens, because every setting is a decision the founder had not yet needed to make.

Each of these came up again during the build, usually in the form of "while we are in there". Each time, the written list settled it. The product that shipped did three things well. The customers used all three. Nothing that was left out was missed by anyone in the first month, which is how we knew the list was right.

The week-by-week shape

The first two weeks were the brief, the sentence and the design of what would be measured. No code. The founder found this uncomfortable, which is normal. Weeks three to ten were the build, with the waiting customers seeing a working version every fortnight and their reactions changing the plan in small ways. Weeks eleven and twelve were the website, written from the product as it actually was. The last two weeks were the parts nobody budgets for: onboarding the first customers, fixing what they found, and making sure the tracking was telling the truth.

What made the difference

• Naming the question before writing code. Will they use it twice is a different build from will anyone want this.
• Three things a user must be able to do. Not thirty.
• Tracking from day one. The first month of real usage is the most valuable data a product will ever have, and most first versions throw it away.
• No handover. The people who built it and the people who sold it were the same team.

What came next

When the question changed from does this work to how do we make it better, the founder hired. The first in-house engineer picked up the code without a rebuild, because it had been written to be handed over. Our role shrank to the parts the in-house team did not yet have, which is how an outside team should end.

What we tell founders

Name the question. Build the smallest thing that answers it, which may be smaller than you think. Keep the decisions and the code yours. Put whoever builds it in the same room as whoever sells it, from the first week. And treat the website as the front door to the product, not a substitute for it.