How an idea becomes working software in two weeks

Two weeks sounds like marketing. It is not, but it does require explaining, because the claim is easy to misread. Two weeks gets you a genuinely working prototype with real data that real people can use. It does not get you a finished, hardened, fully featured product. Those are different things and conflating them is how expectations get broken.

Here is what actually happens.

Days one and two: understanding the problem

A single properly run workshop, three hours, with the people who have the problem rather than only the people who signed the contract.

We are trying to establish three things. What is genuinely broken today. Who the software is for, specifically. And what would have to be true in three months for this to have been worth doing.

Most of the value here comes from disagreement surfacing early. It is remarkably common for two people in the same business to have entirely different views of the process they both work in, and far better to discover that on day one than in week six.

We leave with a one-page description of the product. One page. If it needs more, we have not understood it yet.

Days three to five: the clickable concept

By the end of the first week you are clicking through a realistic version of the product. Real screens, real navigation, plausible data. It does not do anything yet.

This is the single highest-value artefact in the whole process, because people cannot usefully review a specification but they can absolutely review a thing they are clicking. The feedback changes completely. "That is not what I meant" arrives on day five instead of week twelve.

Expect to change perhaps a third of it. That is the point.

Days six to nine: building it properly

Now it becomes real software. Database, logic, integrations, the actual work.

This is where AI-assisted development changes the economics. The scaffolding, the boilerplate, the routine plumbing that used to consume most of a developer's week now takes hours. What remains is the genuinely interesting part: deciding how the thing should behave.

We build the main path first and completely. Edge cases wait. A prototype that handles the common case beautifully teaches you far more than one that handles every case adequately.

Days ten to twelve: real data and real users

Your data goes in, which is always the moment the project learns something. Real data is messier than sample data, always, and the product changes shape to accommodate it.

Then we put it in front of three or four actual users and watch, quietly, without helping. Watching somebody struggle with something you thought was obvious is uncomfortable and extremely informative.

Days thirteen and fourteen: tighten and hand over

Fix what the user sessions exposed. Tidy the rough edges. Write the short amount of documentation that is genuinely useful.

Then a demonstration, a candid conversation about what is solid and what is held together with optimism, and a decision about what happens next.

Why this is possible now and was not five years ago

Three things changed. Modern frameworks removed enormous amounts of routine work. Cloud infrastructure removed the weeks that used to go on environments and deployment. And AI-assisted development compressed the remaining implementation time substantially.

What did not change is the thinking. Understanding a business problem properly still takes as long as it takes. We have simply stopped spending nine months on the parts that were never the hard bit.

What you get at the end

A working product, the source code, and honest information about what it would take to make it production-ready.

Sometimes the answer is "not much, let us launch". Sometimes it is "this is not the right idea". Both are worth two weeks.