Anatomy of a fixed-scope build

"Fixed scope, fixed price" sounds like a line from a brochure until you watch one run from start to finish. So here is one.

Last September I built EventScope for Johnson & Johnson Medical: an engagement analytics platform that ran across their stand at the EADV 2025 congress. Edge devices on the stand, a live dashboard for the team, four weeks from first conversation to working software on the congress floor. The case study covers the technology. This piece is about the process, because the process is what made the date. The technology just did what it was told.

What the client actually needed

J&J Medical had a multi zone stand at EADV, Europe's biggest dermatology congress. They wanted to know how the healthcare professionals walking past it actually behaved. Which zones held people, and for how long. Which times of day were busy. Whether the content was pulling people in or whether it was the coffee.

They wanted this live, during the congress, so the team on the stand could act on it. Not in a report three weeks later when everyone had flown home.

And it had to work somewhere hostile:

• The venue network cannot be trusted. Congress Wi Fi is shared with several thousand people and falls over precisely when you need it.
• The people on the stand are doctors. No faces stored, nothing personal leaving the device. GDPR here is not a checkbox at the end. It is a design constraint at the start.
• Twenty plus devices, installed by a stand build crew, not engineers. Plug in, walk away.
• A date that does not move. The congress opens on the day it opens, whether you are ready or not.

That was the brief. Notice what is not in it: a technology. Nobody asked for computer vision or Rails or edge computing. They asked for numbers on a screen they could trust, in a room where nothing else could be.

The scoping days

Before I wrote a line of code, I spent two or three days deciding what to build. The client got a written spec, an architecture, a delivery plan and a fixed price at the end of it. I have since turned that into a proper one week scoping sprint that every build starts with, because a fixed price quoted without one is a guess wearing a suit. On EventScope it was shorter and a bit less formal, and it still did the job.

Here is what got decided in those days, roughly in the order it mattered:

1. What "engagement" means, in numbers. Dwell time per zone. Visitor counts. Interaction counts. A sentiment measure. Then the harder list: what we were deliberately not doing. No tracking individuals. No face recognition. No re identifying someone as they moved between zones. The "no" list took longer to write than the "yes" list and was worth more, because it is the "no" list that stops scope drifting in week three.

2. Where the data lives. On the device first. Each unit runs its own detection, keeps its own local store, and syncs to the server in batches when there is a network to sync over. If the network dies, nothing is lost. It queues and catches up. That one decision shaped everything that followed, and it came directly from the "cannot trust the venue network" line in the brief.

3. What crosses the wire. Counts and timestamps. Never an image, not even to my own server. Privacy answered by architecture rather than by a paragraph in a policy document. This is also the sort of answer a client's data protection people can read in one sitting.

4. What the dashboard shows and how quickly. Under two seconds from something happening on the stand to the number changing on screen. On a large display, touchable, readable from a few metres away.

5. How devices get installed. Zero touch. Plug a unit in, it finds the server, registers itself, starts reporting. No laptop on the stand, no engineer crouched behind a plinth on build up day.

The spec was short. A few pages. The plan had three milestones with a date and a demo against each one. And there was a number, which I could commit to because those few days had removed the guesswork.

The milestones

A fixed scope only works if the client can see it working. Status reports are not evidence. So each milestone ended in something you could look at.

Milestone 1, end of week one: one device, one zone, one number. A single unit on a bench in my office, detecting people, writing events to its local store, syncing to a Rails app, and one count on a bare web page. Ugly, but true. This is where you find out whether the genuinely hard part, running inference on modest hardware at the edge, works at all. It did, after some tuning. If it had not, this is the week you want to know, not week three.

Milestone 2, end of week two: the fleet. Several devices, auto discovery, provisioning, and the offline sync with backoff. The dashboard went live at this point, pushing updates over WebSockets as events landed. The demo was simple. I pulled the network cable, the devices carried on counting, I plugged it back in, and the dashboard caught up. The client watched that happen and it did more for their confidence than any slide could have. Nobody worries about the venue network once they have seen the devices shrug it off. That is the demo that matters for a congress build. Everything else is decoration.

Milestone 3, end of week three: the real thing. The full dashboard on a 4K screen. Load tested at well above the expected volume. Deduplication, because devices that retry will occasionally send the same event twice and the database has to shrug that off. The 30 day retention and cleanup, so the data does not outlive its purpose. Deployment automated so a fresh server could be up in minutes if the first one died. Nothing left to build, and a week in hand.

Week four: install and rehearsal. I was on site for build up. The devices went on the stand, found the server, and started reporting. I walked the zones and checked the dashboard read what I could see with my own eyes. This is the week for the two or three things that only show up in the actual room, and the reason milestone three finished with a week in hand.

Three milestones, three demos, no surprises at the end. The order matters as much as the content. Hardest risk first, integration second, polish last. If you do it the other way round you have a lovely dashboard and no idea whether the devices work.

Launch on the congress floor

The congress floor is the only test that counts. Four days, twenty plus devices, over ten thousand events a day, with under 100 milliseconds from a device event to the server.

It ran for four days without an incident. I had built for the venue network falling over, for devices rebooting, for a server dying on the Thursday. None of it happened, which is the sort of anticlimax you want on a congress floor. The point of the offline first design was never that the network would fail. It was that I did not have to care whether it did.

Nothing but counts ever left the devices. If someone on the J&J side had been asked by their data protection team what was being collected, the answer fitted in a sentence.

The team had live numbers on the stand for the first time, on a screen, updating as people moved through the zones. That is what they asked for on day one of scoping, and that is what was on the wall.

At the same congress I also delivered an interactive photo experience for the same team, in a four week window. Different product, same process.

What support looked like after

Support on a congress build is front loaded. Build up day and opening morning are when things break, so that is where I was. For the four days of the congress I was on call, which turned out to mean checking the dashboard, seeing it doing its job, and going back to whatever else I was doing. Being on call for a system that does not ring is the goal, not a coincidence.

After the congress the platform tidied up after itself. The 30 day retention meant there was no long term dataset of doctors' movements sitting on a server somewhere, waiting to become someone's problem. Documentation and a proper handover, so the client owns what they paid for.

The measure I care about most is this one. The same team came back. Twice more within the year, for two more congresses, including an offline analytics kiosk built on the mirror image architecture, everything on the device and nothing in the cloud, because that congress needed it the other way round. Repeat work is the only review that means anything.

What actually made it work

Not the technology, although I am fond of it. Three things:

Decisions before code. A few days of deciding saved far more than a few days of building. Every awkward question got asked when it was cheap to answer.

Milestones you can see. Three demos, hardest risk first. The client never had to take my word for it.

Scope that does not move, so the date cannot either. The "no" list from the first few days is what kept week three calm.

That is the whole method. It is not clever. It is just done in the right order, every time.

If you have a build like this

Start with the scoping sprint. One week, £1,950 + VAT, and you get the spec, the architecture, the delivery plan and a fixed price quote. If we go ahead with the build, the full amount is credited against it. If we do not, everything the week produced is yours to take elsewhere.