The work starts when the demo looks done
If you already have a working prototype, the next question is not “can we generate another screen.” It is “who is going to finish this, and who is going to live with it.”
We wrote about why context-right beats vibe-coded. This is the chapter after that: the last mile. It is not a deploy button.
What last mile actually means
Last mile is the gap between a happy-path click-through and software the company can run on a bad Tuesday.
It is four jobs that rarely show up in a prompt:
- Architecture you can still change after the original author has moved on
- QA on the exception path, not just the screenshot
- Launch into the environment people already open
- Ongoing maintenance so the thing does not rot
Custom software work at Sentral names those last three on purpose: testing and QA, launch and deployment, then ongoing support. The first one, architecture, is decided earlier and paid for later. Skip it and you hire someone anyway, only later and more expensive.
Architecture you can maintain
A prototype is allowed to be fragile. A product is not.
Maintainable architecture is boring on purpose. Someone can find the real data, know who owns writes, and hook the new piece into systems that already exist. When the other system is slow or wrong, the product degrades in a way a person can explain.
If only the generator can change it, you do not have a product. You have a souvenir.
QA the exception path
Demos are built for the path that photographs well. Businesses run on the path that does not.
Last-mile QA asks what happens when a record is half-complete, when two people edit the same job, when month-end locks a file, when the integration that “usually works” does not. That is not polish. That is whether you can ship.
Launch into what you already run
Launch is not “it ran on my laptop.” It is stores, servers, accounts, and the tools the company already opens at 8am.
Consulting at Sentral includes implementation support and then ongoing guidance. That sequence exists because a plan that dies at handoff is not a plan. The same is true of software. If the builder disappears at deploy, the last mile was never owned.
Stay on, or it rots
Software that nobody updates becomes a second source of truth with worse manners. Security patches, API changes, a new exception nobody modeled: those arrive after the screenshot.
This is why you hire someone. Not to type faster than the model. To take responsibility for the year after go-live.
Enterprise IT already feels the scale of that gap. Salesforce’s 2025 Connectivity Benchmark (MuleSoft, with Vanson Bourne and Deloitte Digital) surveyed 1,050 IT leaders at organizations of 1,000 or more employees. Those orgs averaged 897 applications, with about 29% typically connected. That is an enterprise sample, not Sentral’s market. It is still the shape of the last-mile problem: the unused connections are where work hides.
When the prototype is enough, and when it is not
Keep the vibe-coded build if you are still testing the idea and you are willing to throw it away.
Hire when the demo is becoming the system. When it has to talk to what you already run. When someone other than the builder will use it under pressure. When you will still need it in six months.
If that is where you are, talk to us about finishing the last mile, not generating another first mile.