VillaSlot: How I Replaced Two SaaS Workflows in 48 Hours
Mike Codeur
Timely support took four days to answer me. Two days later, I had the first version of VillaSlot. That sentence explains the trigger, but not the work behind the result. I did not send “build me a SaaS” to an agent and go to sleep. I prepared a product the agents could build and verify without guessing the business intent.
VillaSlot solves a concrete problem in the management of my villas. Overnight bookings lived in one tool, hourly slots for shoots and events in another, and payments had to reach the correct Stripe accounts. I brought those flows into one application designed around the way I operate.
What VillaSlot actually replaces
VillaSlot does not claim to replace the Airbnb marketplace. It does not provide Airbnb's audience, acquisition, trust network, or global operations. It replaces the direct workflows I need once the customer is already there.
| Need | Before | In VillaSlot |
|---|---|---|
| Stays | Overnight bookings through an external platform | Direct booking with a shared calendar |
| Shoots or events | Hourly slots managed in Timely | Hourly booking in the same application |
| Payments | Separate flows for each villa | Deposit and balance sent to the correct Stripe account |
| Availability | Calendars spread across tools | One view to prevent conflicts |
This boundary matters. Building a focused business tool in 48 hours is realistic. Rebuilding Airbnb, its demand, trust, and operations is not.
The 48 hours started before the code
The speed came from preparation. I framed the product with Codex, then prepared a PRD, 20 user stories, their acceptance criteria, a dependency graph, and 20 mockups. Each agent received a bounded part of the product with an observable outcome.
A story did not merely say “add bookings.” It described the expected behavior, business rules, and evidence required for acceptance. That work keeps an agent from inventing critical details: which calendar to update, which Stripe account to use, when to request a deposit, or how to block incompatible bookings.
The dependency graph also set the order. A story depending on the booking model or payment flow could not start before those foundations were ready. The goal was not to keep the largest possible number of agents busy. It was to start the right work at the right time.
The 9-hour-20-minute autonomous run
Once the work contract was ready, I launched a 9-hour-20-minute autonomous run overnight. The system processed more than four billion tokens with Claude Code and Codex. That volume shows how much work passed through the system, not whether the result was good. Quality came from the proof loop attached to every story.
The flow followed these steps:
- select a user story whose dependencies are complete;
- read its acceptance criteria and define the expected evidence;
- write tests before or alongside the implementation;
- implement the feature;
- run a separate review pass;
- execute unit and integration tests;
- test the journey in Chrome;
- inspect the visual result;
- fix technical or functional defects and run the evidence again.
A validated story released the next items in the graph. A reproducible defect returned to the correction loop. A product ambiguity went back to a human instead of becoming a hidden decision in the code.
Why the mockups mattered as much as the tests
Automated tests can confirm that a calculation, API, or state transition works. They do not prove that a calendar is readable, a button is in the right place, or the journey makes sense on a real screen.
The 20 mockups gave the agents a visual target. The Chrome pass then checked the built application rather than isolated components. Visual inspection exposed layout gaps, inconsistent empty states, and actions that users could not understand.
I also keep implementation and review separate. The agent that wrote the code knows its own intent too well. A separate pass examines the diff and the evidence with less implicit context. It can still miss problems, but it reduces approvals based on “this should work.”
What the run delivered the next morning
By morning, the first usable version was there. I then put it against real use and added roughly ten more stories. That second phase matters as much as the first. An autonomous run can execute a plan, but actual use uncovers needs the initial plan did not contain.
The 48 hours do not mean the product was finished forever. They mark the time from a defined business problem to a functional version I could test in my villas. The next stage followed a normal product loop: use, observe, correct, and extend.
The limits of this workflow
This method does not make agents autonomous by magic. It moves effort into preparation and verification. It fails quickly when acceptance criteria are vague, several stories share an unstable environment, or agents can approve their own work without independent evidence.
I keep several rules:
- ambiguous product decisions return to a human;
- terminal output is not a functional test;
- a green test does not replace visual inspection;
- a review does not replace real use;
- token or agent counts are never a business outcome.
The gain does not come from one giant prompt. It comes from a precise contract between product intent, implementation, and proof. With that structure, I can let agents work for hours without confusing activity with delivery.
▶️ Watch VillaSlot, the autonomous run, and the complete workflow
For more field reports on agentic development, join The Agentic Dev.