I am not a developer by title. I run operations for an IT services firm. Yet in the last year I have taken several client briefs to deployed, paying, production software without a development team assigned to them. Not prototypes: systems with payments, encryption, QA cycles and clients using them daily.
The tool is an agentic coding assistant. The tool is not the point. The process is the point, and it is repeatable.
The shape of the process
1. Turn the brief into a page of decisions before touching code. Every statement of work leaves gaps. I list them and get answers: what happens when payment fails, who can see which fields, what "done" looks like for the first release. The agent is good at finding these gaps if you ask it to read the brief and list the questions a careful engineer would ask.
2. Build in vertical slices, one per run. Not "build the platform". One slice: a user submits one form and sees it saved. Next slice: payment. Next: admin view. Each slice ends with a commit and a real test in a real browser, and the tracker gets an entry with the measured time.
3. Run the QA cycle as a discipline. Test, file, fix, deploy, verify, close. The filing step matters. Bugs found and fixed in the same breath never make it into the record, and the record is what the client is paying for.
4. Hand over something operable. A runbook, an admin panel, environment notes, a rollback path. If I get hit by a bus, the client's next developer should be able to pick it up from the repository alone.
What a travel platform taught me about payment-first design
The first product I built this way was a travel entry platform: travellers fill in the right government form for their destination and pay for the service. The obvious design records the application, then takes payment. That design produces orphaned applications, angry refunds, and support tickets.
The design that worked is payment-first and idempotent:
- Nothing is recorded as an application until the payment provider confirms the money cleared.
- Confirmation can arrive three ways: the provider's webhook, the customer returning to the success page, and a cron job that reconciles anything the first two missed. All three paths create the same record once, keyed on the payment reference, so it does not matter which arrives first or twice.
- Every state change is logged with a source. When a customer says "I paid and nothing happened", the answer is in the log within a minute.
This pattern is not specific to travel. Any product that takes money before doing work should be built this way, and an agent will not do it unless you ask.
Security defaults I no longer negotiate
Because the platform handled passport-level personal data, a few things became fixed rules for every build since:
- Personal data encrypted at rest with a modern authenticated cipher, keys outside the database.
- Documents behind short-lived signed links, never a public URL that works forever.
- Uploads checked by content, reading the file's magic bytes, not trusting the extension the browser sent.
- Secrets in environment files, never in the repository, and a check in the deploy script that refuses to ship if one leaks.
- Admin actions behind a real login with rate limiting, not a shared link.
None of these are hard. All of them are skipped by default in a demo, and demos have a way of becoming production.
Forty prototypes, and a colleague who now runs the process
The same process, with the security rules relaxed and mock data instead of real, is how our sales team gets prototypes. In six months we built more than forty for prospects across government, finance, healthcare and consumer businesses: secure messaging for a state agency, a fraud-detection demo, scheme portals, clinical dashboards. A prospect who can click through a working screen behaves very differently from one reading a proposal. Several of those prototypes went into investor pitches and converted into paid projects.
Once the process was stable I wrote it down as a standard operating procedure and trained a colleague to run it. That is the real test of a process: it works when you are not the one running it.
Where it breaks
- When the brief keeps moving. Agents amplify indecision. Ten changes of mind cost ten rebuilds, fast but not free.
- When nobody reads the code. I read every diff. Not to write it, to understand it. The day I stop is the day something ships that nobody can explain.
- When "it works on the demo path" is accepted as done. The QA cycle exists to make that unacceptable.
If you run operations, product, or a small business, and you have a brief that has been waiting for a free developer for three months: the wait may be over. Just do not skip the page of decisions, the vertical slices, or the payment-first rule.