Two Weeks from Zero to a Customer Demo

One thing first. My years in industry were spent on infrastructure monitoring, and the ownership of field data was never in doubt: it belongs to the customer, or to the employer of the time — never to me personally. What I took with me is experience: what that kind of data looks like, what questions an engineer asks of it, what makes an answer useful. This article is about how a product prototype got built in two weeks. Nobody’s data is involved.

The prototype came to be called MurSense: a conversational AI for the health monitoring of large infrastructure.

The first cut was to scope

“Health monitoring for large infrastructure” is a very wide subject: bridges, tunnels, dams, slopes, towers — each one of them is worth several years on its own. Want all of it inside two weeks and you will certainly end up with none of it.

So I kept exactly one vertical: railway bridges. Not because they are the easiest, but because the engineering record on that kind of structure is the least forgiving, and because I knew what the people who operate a bridge actually worry about day to day.

The goal of the demo was cut down to a single sentence too: let someone who knows bridges ask, in plain language, for something they would normally have to write a script to find — and get back an answer they dare to trust. That sentence became the only acceptance criterion for the whole two weeks; every idea that did not serve it went into the task pool.

Working in two days, and then the parts that are not code

The chain was working in two days: an agent that decides for itself which stretch of record to look at, which analysis to call, and then answers in an engineer’s language.

Most of the remaining time did not go into the model. A name, a mark, an interface, a manual someone can read without me, a demo video, materials in three languages. Engineers tend to file all of that under “packaging”; my own sense is the exact opposite: a demo is not a program, it is a story someone else can retell on your behalf. After the customer’s boss has watched it, they have to be able to go back and explain to their own team what this thing is — if they can retell it, the two weeks meant something.

Back then I did not yet have today’s toolkit

Worth mentioning: when I did this, I had not yet picked up the agentic command-line tools. It was a chat box the whole way, plus my own multi-window discipline: one window opens the card, one window does the work, a third one runs acceptance.

The point is not that tools do not matter. It is that what saves time was never how new the tool is — it is whether the process blocks rework before it happens. My tools have turned over several times in two years; not one line of that discipline has changed.

After the two weeks

It was shown to real customers a few times afterwards, and drew interest in taking things further. But let me be precise: demo-grade is not product-grade. Two weeks can produce something people are willing to sit down and keep talking about, and that is still a long way from a system running for years on somebody else’s site — where it rains, where the power cuts out, where someone puts a shovel through the fiber. None of that is in a demo.

What I actually kept is three lines: cut to one vertical; end every day holding something you can demo; never sign off on your own work.