A prototype built for a demo always contains lies. A button that shows a success message but saves nothing. Conditions written directly into the screen. Fixed data prepared only to make the look come together.
For showing, that is fine. Butcarry those lies into requirements definition and the customer’s understanding and ours drift quietly apart.
This instalment is the story of the period spent stripping those lies out.
We matched how data is held to the customer’s current setup.
The first thing we did was replace the whole mechanism for storing data. Not the approach we are used to, but the setup the customer actually uses.
. If we chose by ease of building, a different approach would move faster. We aligned anyway, becauseif data is held differently, the constraints you discover later are different.Search speed, behaviour under simultaneous updates, suitability for aggregation. These have their own quirks per approach, and a result verified on a different approach than production is no guarantee for production.
Rebuilding at the requirements-definition stage is still cheap work. Rebuilding after design is finished is not.
We turned every “pressable but nothing happens” into the real thing.
Next, we replaced the merely apparent functions with real ones, one by one.
Make create, update and delete real communication. Actually store accounts and permissions. Actually save a file and actually make it downloadable. Actually output the report. Actually fire the notification to the external service too (and when the other side is not connected, make that visible).
Andwe rebuilt the login mechanism to match production as well.For a demo it is convenient to switch roles on screen. We stopped that, so that only the permissions of the person actually logged in take effect.
This rebuild is unglamorous, but its effect is large.Discussions about permissions never get stuck as long as you are switching roles to show them.Only when you actually log in and meet “something that should not be visible is visible” does it become a concrete discussion.
We replaced the approval flow with the customer’s authoritative version.
The approval flow of the business was, at first, assembled from our imagination. We replaced it wholesale to match the customer’s official document. The number of steps was88.
Put 88 steps on an actual screen and things surface that were invisible while it was imagined.Who decides this step is finished? Are there cases where it may be skipped? Can you go back?
These do not come out of looking at a list of steps laid out flat. They come out where you actually try to proceed and cannot.
We pushed conditions written into the screen out into settings.
And the latter half of this period was devoted entirely to pushing conditions written directly into the screen out into settings.
How approvals circulate. What counts as an anomaly worth notifying. Who gets notified. How long something can sit before a reminder. How the likelihood rating rises and falls automatically. After how many days old data is cleared away.
All of these were, at first, written inside the program. It works. The demo passes. Butwhen the customer wants to change one number in the course of operation, they cannot do it without calling us.
A system where nothing can be changed after delivery without calling a vendor gradually stops matching reality. The gap gets filled by hand at the site.What gets called “an old, hard-to-use system” ten years later is usually built from exactly this accumulation.
So at the requirements-definition stage we decided to settle which parts can be changed by setting. This is not a discussion about features; it is a discussion about the system’s lifespan.
What it means that this rebuild fits inside a single period.
Let us line up what has been written so far. Wholesale replacement of how data is held. Turning apparent functions into real ones. Rebuilding authentication and permissions. Replacing 88 steps. A blanket stocktake of what becomes a setting.
Traditionally this is a volume of work for the implementation phase after requirements definition.And because it is built once and then rebuilt, it is treated as rework.
Put AI at the centre and this finishes before requirements definition begins. And the meaning of it being finished is not saved time.It is that the requirements-definition discussion becomes a discussion held in front of the real thing.Permission discussions happen looking at a screen that actually exposed something. Settings discussions happen while actually touching the settings screen.
Requirements agreed on paper usually drift later.Requirements agreed by touching do not.
Next time: the story of killing “it looks like it worked but nothing happened.”
* The counts in this article are our own side’s work records. Nothing identifying the customer or the system is included. Approach and time required vary with the scale and structure of the project.
Series “Project Diary” (7 parts)Part 1: 82 fixes to the prototype on the day we won the projectPart 2: Cutting our own company introduction out of the first meeting’s agendaPart 3: Counting what we did not understand and putting it on the tablePart 4: Bringing the prototype closer to the real build (this article)Part 5: Killing “it looks like it worked but nothing happened”Part 6: Cutting promises we could not keep out of the materialPart 7: Dropping the paper comparison and deciding by measurement