I've been writing good, fast, inexpensive software
An engineering manager I worked with before asked me how I can deliver good software for lower cost. Am I slow? Is it truly good? Am I losing money?
One should always keep such friends close. And it’s a fair question. The old rule in software is good, fast, cheap: pick two. But I provide all three. The short answer is that I changed how I work. The long answer follows.
I jumped in advance
For most of my career I had it all: a reliable full-time salary as a staff engineer, solving tricky engineering or team problems with people I like. Then AI agents appeared, and got better at writing code faster than anyone expected. And I wanted to build software differently. How long would jobs that write software the 2025 way last?
I went independent before I had to find out. I lowered the price, promised as much productivity as a full-time remote freelancer, and as much quality as I’ve been delivering as a full-time staff engineer.
Standups, mandatory code reviews on every change, planning meetings with long horizons, make little sense now for most startups I worked with. Not all, but most. I help them navigate this change.
Lately I watch friends’ companies shrink their engineering teams, fewer job offers and morale down for people used to more generous prospects. Those companies still have a backlog. The capacity they let go can come back as a contract that carries less risk than a hire.
AI agents made me much faster. Years of experience tell me what to build, what to refuse, where risk lies, what a good pull request looks like. My agents turns that into Good Code in minutes.
That much output can be more than one employer can use. Spread across several clients, it became a business.
One experienced person, many agents
RailsPilot is that business: $5,000 a month for up to 12 production features. The client gets the economy of scale of AI, attached to a person with the agency and experience to steer it.
Coding agents write the first draft of almost everything. My team and I direct them inside conventions I set up on day one: tests first, a CI gate, small pull requests, encode improvements into our toolkits, automating a little more every week (steps towards Dark Software Factories).
Sometimes I draft a first version myself. I recently reconnected with my editor and Test Driven Development, laying down foundations for a pattern that would repeat. I knew the design we needed. An agent might have repeated code or gotten it wrong at first, requiring future refactors. It was productive and fun.
I decide how much review each change gets. Minor dependency updates merge automatically after a one-day cool-down and passing automated checks. Cleanups, style and copy changes pass with mostly automated reviews. Authentication or authorization get my full review, can’t afford hallucinations or complications in such code: agents assist me, but I offload none of my attention. I’ve worked in Rails since 2009 for different consultancies and companies, so knowing which lane a change belongs in is where my experience gets spent.
The unit of work is a feature, usually scoped to a screen the client can open. It’s 90% async. Every Thursday the client gets an email with the detail of what was done, each line linked to its changeset, a count of how many of the month’s 12 have been delivered. A shared spreadsheet shows what shipped each month next to what was invoiced.
Twenty-four hours
Yesterday, on a call with a medical group I work with, the operations lead was surprised. She had emailed me 24 hours earlier asking for a new internal tool. I replied with my assumptions and a link. She wrote back confirming the assumptions, without noticing the link already pointed to the working tool.
The agent gave me the speed. The assumptions came from months inside her team’s data and from having built this kind of tool before. I now help them incorporate AI workflows on their tasks with potential for automation.
The ledger
Speed on one tool is an anecdote. Here is a longer record, from a different client.
On August 6th the founder of a telehealth startup emailed me the requirements for a new app. By the 8th there was a Rails application with a data model and a CI gate. The contract started on the 10th. The first feature, an AI check that rejects blurry or badly framed photos, was merged on the 11th. By the 12th a patient could sign up and a provider could claim and review the case. On the 17th it was deployed.
This is the ledger summary the client and I both look at, through October:
| Month | Invoiced | Features allocated | Features delivered |
|---|---|---|---|
| August (pro-rated) | $3,750 | 9 | 9 |
| August add-on | $3,000 | 6 | 6 |
| September | $5,000 | 12 | 8 |
| October | $5,000 | 12 | 12 |
Notice September delivered 8 out of 12, part of that month went into a spike on a third-party API, and a written comparison of that API against the requirements. It showed we had to change the roadmap for the following months. We found that out in a document, before building complexity on unverified assumptions.
In need of good, fast, inexpensive software?
The math checks out: $5,000 a month is $60,000 a year, less than half of a senior Rails engineer’s salary in the US, with the first feature delivered within 24 hours of starting.
RailsPilot confirmed I don’t need to lower the quality of my work to lower costs.
Clients happy, me as well. As it’s always been.