Three systems built in 11 days, 2 weeks, and about 3 weeks, each one taking a manual task off someone’s plate. AI wrote most of the code. What shortened the timeline was the method around it.
Anderson Silveira · October 1, 2026
In September 2026, a lubricant distributor had a process every small operation knows: orders arrived as photos of paper notes on WhatsApp, and someone retyped everything. The ordering and inventory system I built for them went from first commit to its current version in 11 days, already running on the client’s server. In June, Glint, an event platform that runs from the sales page to the refund, took about three weeks. In August, the first complete version of Kitnets, a platform for renting out and managing kitnets (small studio apartments), shipped in two weeks.
In all three, AI agents wrote most of the code. But if I had to point to what shortened the timeline, it wouldn’t be the AI. It would be understanding the manual work before automating it, and the method around the AI.
The moment that became clear was in Glint. The first version of sections enforced capacity at checkout. It worked. But the dashboard showed ticket tiers with open spots in a section that had no room left. The fix didn’t need a new screen: the limit moved to the configuration. The sum of a section’s tiers can’t exceed its capacity. An agent can write either version in minutes. Deciding which one is right is product work, and that work is what decides whether a system is ready in weeks or turns into an endless rework loop.
The method, in five parts
- 01Short discovery
Problem, audience, business rules, and what stays out.
- 02Model before screens
Entities, relationships, and where each rule lives.
- 03Slices that ship
Small waves, each one usable.
- 04AI with human review
Agents write; people approve the plan and the delivery.
- 05Tests as a gate
The suite blocks delivery, and the flow is checked live.
1. Short discovery, but with evidence
Short doesn’t mean shallow. For Kitnets, before any screen, I ran market discovery with cross-checking: 36 claims about competitors, pricing, and technical rules, all confirmed. That produced a requirements document with 12 feature blocks and 60 acceptance criteria, and a roadmap of 29 epics in three waves.
Three findings changed the product. The public listings page was the differentiator, because no competitor aimed at individual landlords had one that worked. Rent needed a Brazilian payment provider, with Pix (Brazil’s instant payment system) and boleto (a Brazilian bank slip), separate from the one that charges for the software subscription. And the legal stance became a product rule: the platform is software and a payment method, never an intermediary. None of these findings would come from asking an AI to “build a rental system.”
In the ordering system, discovery came down to one decision: don’t ask anyone to change their habits before they get something out of it. Buyers already sent a photo of their handwritten order on WhatsApp. So the system accepts the photo, the AI reads it, and a person checks it line by line before confirming.
2. Data model before screens
This is the step that saves the most time later. In Glint, I split the event into layers before designing anything: Event → Section → Ticket type → Ticket tier. A section is the physical area, with a capacity. A type is the commercial condition. A tier is the price ladder.
- Event
- SectionPhysical area, with capacity
- Ticket typeFull price, half price, day pass
- Ticket tierRolls over by date, by percentage sold, or when it sells out
With the right model, the question “where does the capacity limit live?” has an answer: in the section. The screen just follows.
The ordering system showed the same principle from another angle. Mid-project, the client asked to remove prices from every screen, because each buyer has their own negotiated terms. It looked like a big change. It turned out cheap, because the decision already lived in one place and the screens just followed it. When a business rule has a single address, changing your mind costs little.
3. Slices that ship
Instead of one big launch, the work moves in small waves, and each wave delivers something someone can use. In the ordering system, the first version went live within a few days, followed by almost daily adjustments based on what the client asked for: selling by the case, hidden prices, pickup scheduling. Kitnets followed the three-wave roadmap from discovery. In Glint, every feature became a spec in the repository, with goal, acceptance criteria, happy and unhappy paths, and risks; the catalog has a master document and 21 specs, and it served as the contract between design, code, and testing.
A slice that ships has an advantage no meeting can replace: the client reacts to something real, and the next wave grows out of that reaction.
4. AI in development, with humans reviewing
In Kitnets, 100% of the code was written by AI agents, in a process I designed: every request becomes a task with steps, a “challenger” agent attacks the plan before any code, and the requirements, technical plan, and improvements go through human approval. In Glint, large deliveries were split into waves run by several agents in parallel, with adversarial reviews on the parts that touch money and security.
One of those reviews found the risk of a double refund from two simultaneous clicks. The fix makes sure the item is canceled first, atomically, and only then does the money go back. That’s the kind of failure the happy path never shows.
The human role doesn’t shrink. It moves: away from typing code and toward deciding what goes in, what stays out, and where a human needs to be in the loop. In the ordering system, that became a product principle: the AI proposes, a human confirms. Getting the packaging wrong on a 200-liter drum is not a cheap mistake.
5. Tests that gate delivery
In Kitnets, a suite that tries to access another landlord’s data grew with every epic and blocks delivery if it fails. Glint’s suite passed a thousand tests, including isolation between organizers.
But a green test isn’t a working system. In the ordering system, the suite passed in full while the API, actually running, was returning an error on the catalog: the tests read one version of the code and the server read another. So after the green, someone runs the flow on the live system, looking at the screen. I wrote more about this in Validate before you build.
The three projects side by side
| Glint | Kitnets | Ordering system | |
|---|---|---|---|
| What it is | Event and ticketing platform | Kitnet rental and management | B2B ordering and inventory |
| The manual work it targets | Refunds by email and certificates assembled by hand | Reminders from a personal WhatsApp and Pix payments checked against the bank statement | Retyping the photo of the order and checking inventory from memory |
| Timeline | About 3 weeks | 2 weeks (first complete version) | 11 days (first commit to current version) |
| Model decision | Capacity limit lives in the section | Charging through the platform is optional | Stock balance is a ledger, not a field |
| Where the human sits | Adversarial review of money and security | Approval of requirements, plan, and improvements | Confirming every line the AI read |
| Quality gate | More than a thousand tests | Isolation suite on every epic | Flow checked on the live system |
The short timeline didn’t come from cutting steps. It came from keeping each step short, and skipping none.
When NOT to automate with custom software
Custom automation isn’t the default answer. I’d advise against it when:
- An off-the-shelf tool covers almost everything. Accounting, payroll, email marketing: if your process is the same as everyone else’s, pay for the subscription. Custom pays off when the process is what sets the business apart, like the photo of the order buyers were already sending, or capacity tied to the event’s physical space.
- The process doesn’t exist yet. If the operation changes every week, start in a spreadsheet. A system locks rules in; a rule nobody has defined turns into rework.
- Nobody on your side owns the product. Someone has to answer “is this in or out?” quickly. In the ordering system, rule changes came from the client, and that’s what kept the almost daily adjustments on course.
- There’s no one to look after the system afterward. A live system needs updates, monitoring, and someone to respond when something breaks. If nobody owns that, the system ages badly.
- The expectation is “AI does everything.” AI speeds up the code. It doesn’t decide where the capacity limit lives, or whether a photo reading can become an order without a check.
What I’d do differently
- Put real users in front of it sooner. In Kitnets and in the ordering system, the pain points came from market discovery and from the process as described, not from interviews. Short slices make that round cheap; it’s worth doing before switching on the most expensive parts.
- Check a rule change on every screen, on the live system. When prices came off the ordering system’s screens, two places were still printing a zeroed-out amount. No test complained; I only saw it by running the whole flow.
Checklist before automating with custom software
- Is the process the system will support a differentiator for the business, not something an off-the-shelf tool already covers?
- Did discovery put in writing the problem, the audience, the business rules, and what stays out?
- Was the data model designed before the screens, with each rule in a single place?
- Is the work split into small slices that ship?
- Is it clear where the AI proposes and where a person decides?
- Do plans and deliveries go through human review, with extra care on money and security?
- Do tests gate delivery, and does someone run the flow on the live system?
- Is there a product owner on the company’s side?
- Is it settled who looks after the system once it’s live?
How I can help
What your team does by hand can be automated. If there’s repetitive work in your operation, an order being retyped, documents read one by one, a spreadsheet checked by hand, I can lead it from mapping the process to the first version in production, or help you decide whether custom automation is really the way to go. The Glint, Kitnets, and ordering system cases show the process in detail. Get in touch.