Case studies

The founder was a business owner without a technical background. Using a sophisticated multi-agent AI coding process, he had spent several months building a survey platform for large organizations. Tens of thousands of employees would answer its surveys. Before launch, he wanted to be sure it would hold up: under load, against security and GDPR requirements, and in real-world use. In two weeks I set up and ran the whole system, went through the code, the tests, and the planned infrastructure, and checked what the documentation claimed against what the system actually did.

The platform was in good shape overall. The report listed about 130 findings, a handful critical or high and the majority medium or low, ranked into a plan for what to fix before launch. Typical patterns of AI-built software emerged: components built in isolation that didn’t connect to each other, safeguards that were built but never switched on, and tests that existed but never ran. The founder handed the findings to his AI coding agents to fix straight away.

A founder and two developers, strong in machine learning and back-end infrastructure, had built a coaching platform that analyzes how competitive gamers play. It worked as a proof of concept, and the founder wanted to turn it into a product other players could use. How much of it could go into production, and what would it take? I reviewed the code of each component, the cloud infrastructure, and how the work was planned and tested. I also worked out what analyzing one match cost.

The report covered three things. The infrastructure could run for under $500 a month instead of the $1,500 he was spending. The core platform could be ready for customers in six weeks at best and three months realistically, with clear specifications, a proper QA process, and a production environment. And while the core analysis was affordable to run, some of the more advanced analysis was still at the research stage and cost 10 to 100 times more per match than players would pay: better to launch without it and do further research to bring costs down. The founder put the recommendations into practice, already starting with the infrastructure while I was still wrapping up the review.

Two first-time founders were building a platform for creators to sell their content. They had worked with a developer for two months and wanted the product to take shape faster, with progress they could follow. I looked at what had been built and how the work was planned. The founders had asked from the start for everything to be built right, so it wouldn’t need changing later. The developer took that literally: he spent the two months on foundations a large platform would need one day, while the first goal was a preview and waitlist page. The founders also kept refining the designs, and as a back-end specialist he found the visual details hard to match. I worked with the founders on the requirements, and together we brought in a front-end specialist and a back-end developer. Each week the developers committed to goals they agreed were realistic, and delivered them.

A few weeks later the preview and waitlist page went live, and from then on the founders saw finished work every week instead of just status updates.

Two first-time founders needed a back-end developer for a platform where payments sat at the heart of the system. I wrote the job post, screened dozens of applicants, and interviewed the strongest four, two of whom stood out. The founders and I then had a call with each of them. The deciding factor was deep experience building payment processing in Python, one of the most critical parts of the back-end. He was new to the freelance platform where we found him, so instead of a track record there, I checked his references and got glowing feedback from his past clients.

The founders hired him. He turned out to be an excellent developer, responsible and skilled at working with AI coding agents, and one I’d gladly work with again.

A founder with a background in recruiting was building a marketplace where companies post hard-to-fill roles and specialist recruiters propose candidates. He wanted to start with clear requirements, to avoid the problems that so often derail a first product. He knew his users and what they wanted. Over three weeks of calls we worked out what that meant in software: each journey through the system for companies, recruiters, and candidates, what goes on each screen, and what data the system needs at each step. He wrote out the details, with AI assistance, and I reviewed them for gaps: a page missing information its users would want, a next step with no direct way to get there. I explained what each technical choice would cost in effort and complexity, so he could weigh the trade-offs and narrow the first release, and showed him how to write user stories that developers can build from.

With the finished requirements, the founder built the platform with AI coding agents and launched it.

A founder planning a recruiting marketplace was offered an existing product to build on. Its founders had part of what he wanted, but their business hadn’t taken off. Would buying it save him time and money? The key question was whether it held anything a coding agent couldn’t build in a few hours. Worth paying for would have been advanced logic that took real insight to get right, or confidence that the software does what it should: then he could simply have added the few things he still needed. Customers, data, or distribution could have been worth the price too. I found none of these: the code was solid but not outstanding, had seen only a few real users, and held no logic that would be hard to build from scratch.

He built from scratch with AI coding agents instead, and launched.

An environmental nonprofit that assesses hundreds of large companies and financial institutions each year was replacing the legacy software their assessment work runs on. They wanted a system that made the work simpler for everyone involved, from their own assessors to the companies being assessed, and their in-house developers were ready to build it. What they needed first was a clear definition of what the new system had to do. Over eight weeks I talked to the people who would use it and went through the existing software with them: which parts they relied on, which nobody used, and which didn’t fit how they actually work. From there we worked out how they wanted their day-to-day work supported, and I wrote the product requirements document: goals, users, and requirements grouped by area of work. Then I wrote out all 209 user stories in the team’s project tool, each with acceptance criteria and non-functional requirements such as data volumes and an audit trail of who changed what.

The requirements document was approved, and the in-house team took it from there to design and build the new system.

Kids kept missing their online lessons because they couldn’t find the video link or get the software running when no parent was in the room. The founder wanted an app that made joining a lesson simple. He had described it and collected quotes from developers, which ranged from a few thousand dollars to five times that, and he couldn’t tell where the difference came from. Each vendor had read his description differently, and some had quoted for a far more comprehensive app than others: the quotes simply weren’t comparable. Once I’d explained this, we specified the app together: a simple, child-friendly layout of every screen, how each feature should work, and how it fit with the video service and the rest of the setup. With the specification in hand, the quotes became comparable, and the founder chose a contractor at a fixed price, who delivered the app a few weeks later.

The app went live for all their learners, and joining a lesson took one tap.