PRG 02Method03 steps00 / 03
The method.
Three steps, in order. Start with the real constraint. Build the smallest useful system. Stay through deployment. Below is what each one means in plain terms, an example of each from the work, and what each one rules out.
STEP 01Constraint01 / 03
Start with the real constraint.
Every project has one thing that decides its shape, and it is rarely on the feature list. Sometimes it is the data, which cannot leave the building. Sometimes it is the connection, which drops. Sometimes it is a license. SAID had to interpret between people in 110+ languages with no connection at all, so it was built to run entirely on the device, and everything else followed from that. Anthony once built on a vision model whose license turned out to be the real constraint; he swapped the model, and the result was better than what he started with. The first conversation is about finding that one thing.
What this looks like in practice
- Ask, in the first meeting, what has to work and what is in the way. The feature list can wait.
- Write down where the data lives, who is allowed to see it, and where the connection drops before drawing any architecture.
- Ask on the first day what happens when the system fails, not at launch.
- Treat the place the system will run as a requirement, not a detail for later.
- If the cloud is not an option, never assume it, not even for the prototype.
What it rules out
- Scoping a build from a feature list.
- A prototype that assumes clean data and a perfect connection.
- Choosing the architecture before the constraint is known.
- Finding out where the system has to run on the day it goes live.
STEP 02Smallest02 / 03
Build the smallest useful system.
The smallest useful system is one a real person can use for real work, with nothing added to make it look finished. Small enough to understand, test, and change. Useful enough that using it tells the truth about whether it works. One of the lab's own tools is the example: it does one job, checking whether what an AI assistant says it learned actually made it better, and that is the whole tool. Size comes later, once a system has earned it.
What this looks like in practice
- Build the first version to do one job end to end before it does a second job at all.
- Make every part justify its place. Cut the ones that cannot.
- Test the paths that will run at 3 a.m., not the ones that run in the demo.
- Put it in front of real users early. What they do with it outranks what the plan said they would do.
- Decide who can see what from the start, not in a later sprint.
What it rules out
- Building a platform before there is one working product on it.
- Adding features because the demo would look better with them.
- A system nobody can explain in one sitting.
- Waiting for the full roadmap before anyone uses anything.
STEP 03Deployment03 / 03
Stay through deployment.
A system is not done when it is built. It is done when it is running where it has to run, in the hands of the people who have to trust it, with someone accountable for what happens next. Anthony stays for that part. Some of the systems he has delivered run across five clinical sites, with 4,000+ people using them a day at peak and some of that use in live emergencies. When a system is used like that, someone has to own what it does next. One person owning the build, the hardening, and the outcome means there is nobody to hand the problem to.
What this looks like in practice
- The person who designed the system is the person on the line when it goes live.
- Check readiness against the real environment: the real data, the real connection, the real users.
- Check before launch whether it keeps working, who can see what, and how well it is tested. Fix what turns up; do not note it for later.
- Hand over a working system with a visible record of what was decided, not a slide deck.
- End the engagement when the system holds, not when the code is delivered.
What it rules out
- Handing a demo to someone else to make it ready for real use.
- A launch that is a date on a calendar rather than a state the system is in.
- Another layer of management between the decision and the person who made it.
- Calling it done before anyone has used it for real.
PRG 02PositionReady
What the method is for.
- AI systems that survive contact with production.
- Built to deploy.
- Let's build something that ships.
PRG 05ContactReady04 / 04
Send the hard version.
Send what has to work, when it has to work by, and what a good outcome looks like. A sentence is enough. The reply comes from Anthony.