Building software without hiring five engineers: eight months coding with Claude inside an agency
In under 4 months, a platform built with Claude brought 73% of Quirurgil's missing billable base back into its CRM. What worked, what we learned, when to build.
AI, digital marketing and medical marketing consultant · btodigital
Between 8 May and 25 August 2026, in under four months, a platform we built at btodigital with Claude brought 73% of Quirurgil’s billable customer base that was missing from its CRM back into the system. We did not put together a team of five engineers to do it.
Before 2026 I had a single code repository of my own. Over the next eight months I opened 62. That jump did not come from a new team. It came from Claude Code, Anthropic’s tool that writes, tests and deploys code from plain-language instructions.
This piece is for executives wondering whether to build their own system instead of buying yet another one. I cover what went well, with numbers; what I learned along the way; and the build rule I adopted after getting things wrong.
What changed in eight months?
Claude Code changed who can build software inside an agency. That does not mean the AI works alone: I decide what gets built, review what it does and answer for it when something breaks in production.
This is what came out of those eight months, with its real status as of October 2026:
| System | What it does | Status, October 2026 |
|---|---|---|
| QOG, Quirurgil’s platform | CRM, commissions, maintenance and a product catalog with health registrations | In production; replaced Salesforce as the system of record |
| Lead module on btodigital.com | Receives every lead and routes it to the CRM, analytics and team email | In production, with 23 automated tests |
| btodigital’s quoting tool | Sales proposals drafted with AI | In production |
| El mejor DOC’s medical dictation app | Report templates for radiologists | In production |
| My students’ exam | Online assessment for my courses | Was closed for two months; reopened on 28 September |
Building fast is not the hard part. Keeping what you built running is.
What did Quirurgil get out of it?
Quirurgil is a Colombian company that imports, sells and services medical equipment. Its main risk was not inefficiency: it was quoting the wrong price or selling a device whose health registration had expired. Its CRM did not reflect the business. It held 5,495 accounts, the accounting system had 815 unique billable customers by tax ID, and only 219 matched between the two.
QOG was built so the system would mirror real operations. These are the results:
| Result for Quirurgil | Figure |
|---|---|
| Billable base missing from the CRM that came back into the system | 73% |
| Duplicate accounts resolved against the accounting system | 673 |
| Preventive maintenance jobs generated automatically, previously done by hand | 1,308, across 568 devices |
| Business units with automatically calculated commissions | 8 |
The case is public in btodigital’s portfolio (in Spanish). Those eight business units each have a different commission scheme. No off-the-shelf CRM handled that, and that is half the answer to the build-or-buy question.
Why is business outcome the only metric that counts?
The first public version of the case listed different numbers: 249 code deliveries, 20,645 lines of Python, 119 modules and 87 screens. I submitted it for an external review and it came back with a blunt note: the case did not state a measurable result.
The reviewer was right. Those four numbers measured how much we worked, not what the client gained. I replaced them with the figures in the table above, which answer a different question: what changed in Quirurgil’s business.
If a vendor pitches a project in lines of code, screens or hours, ask what the client gained. If they don’t know, neither will you.
What we learned
Building with AI also speeds up mistakes. These are the three that taught me the most.
| Situation | What happened | What I learned |
|---|---|---|
| The student exam was closed for two months | An access setting shut it down, and the server answered “not found” instead of “forbidden,” which is misleading. That project also had no version history | Everything in production needs an external monitor and a repository, no exceptions |
| A 6,713-line file with no tests | The btodigital.com backend grew inside a single file. Any change could break something else without warning | New modules are built separately, with tests from day one |
| Manual deployments | The quota for the service that deployed QOG automatically ran out, and deployments moved to manual | A deployment that depends on one person is a risk, even when it is documented |
Two more practices became rules. Anything critical gets bundled on your own server, because corporate and clinic networks block what they don’t recognize. And the AI writes, but the code does the arithmetic: the server recalculates every number and ignores the one the model returns.
There is one more risk the table does not show: 62 repositories are 62 things to maintain. The ease of building creates debt just as fast.
What is hexagonal architecture and why should an executive care?
After those failures I adopted a rule: every new module with business logic is built with hexagonal architecture. The name sounds technical; the idea is simple.
Your business rules sit at the center. What happens to a lead that arrives via WhatsApp, how a commission is calculated, when a maintenance visit is due. Those rules don’t know which database stores the data or which CRM the company uses.
Around them sit standard sockets. The center says “I need to save a lead” or “I need to notify the CRM,” without saying how.
Adapters sit outside. One for the database, one for the CRM, one for email, one for the AI model. Each plugs into a socket.
The first module built this way was btodigital.com’s lead module, on 3 October. It has one rule per source: a contact form or WhatsApp lead opens a deal in the CRM, logs the conversion and alerts the team; a quote is simply saved. Here is what changes for whoever runs the company:
| Executive’s question | One giant file | Hexagonal module |
|---|---|---|
| Can I switch CRMs? | You have to hunt for the CRM across the whole codebase | You swap one adapter; the rules stay untouched |
| How do I know a change didn’t break anything? | Manual testing, often in production | 23 automated tests with fake adapters, without touching the real database or sending emails |
| What happens if the CRM goes down? | The request fails and the lead may be lost | The lead is saved |
To be honest: this is the first module. The big file went from 6,713 to 6,457 lines, nothing more. The full migration happens piece by piece, only when a module is touched for another reason. I don’t apply it to content sites, landing pages or one-off scripts: there it is overhead.
Build or buy: what is the right question?
The usual question is how much it costs to build. The right one is different: where is the rule that makes you money, and who is going to maintain it?
| Buy when | Build when |
|---|---|
| The process is the same in every company: accounting, payroll, email | The rule that sets you apart doesn’t fit the standard, like eight commission schemes or health registrations per product |
| Off-the-shelf software already measures the outcome you care about | You pay for a system that doesn’t reflect your business and your team works around it in spreadsheets |
| Nobody will answer when it breaks | Someone will maintain it, test it and watch it |
The answer is usually mixed. At Quirurgil we did not replace the accounting system: QOG reads it and treats it as the source of truth. Buy the commodity, build the differentiator.
How can you apply this in your business?
Before building your own system with AI, go through this list:
- Write down the business outcome you will measure, with a date, before the first line of code.
- Identify the proprietary rule that purchased software doesn’t handle. If you can’t find one, buy.
- Start with one module, not the whole system.
- Separate business rules from integrations and require automated tests from day one.
- Have the server recalculate every number an AI model produces.
- Bundle anything critical on your own server if the system will run on corporate or clinic networks.
- Put every project in a repository with history, no exceptions.
- Set up an external monitor for everything in production.
- Document deployment so it doesn’t depend on a single person.
Frequently asked questions
Can you build business software with Claude without an engineering team? Yes, with conditions. QOG, Quirurgil’s platform, was built with Claude in under four months and runs in production. But someone has to decide what gets built, review what the AI does and answer when it fails. AI replaces programming hours, not accountability.
What is Claude Code? It is Anthropic’s tool for programming with Claude: it writes code, tests it, fixes it and deploys it from plain-language instructions. I use it to build systems for btodigital and for clients.
How long did Quirurgil’s platform take? Under four months, from 8 May to 25 August 2026. In that time 73% of the billable base missing from the CRM came back into the system and 673 duplicate accounts were resolved.
What is hexagonal architecture in plain terms? It means putting business rules at the center, separate from databases, CRMs and AI models, which connect through standard sockets. You can switch vendors without rewriting the rules and test them without touching real data.
When is buying better than building? When your process is the same as any other company’s, when standard software already measures what matters to you, or when nobody will maintain what you build. Building is only worth it where your edge is.
What is the biggest risk of building with AI? That speed hides debt. In my case, an internal service that stayed closed for two months, a 6,713-line file with no tests and deployments that came to depend on one person.
If you are weighing whether to build your own system, that is how I work as an AI consultant with Claude. Before you start, read why AI projects fail in small businesses. And if you want to see how I audit what I build, I wrote about it in three AI auditors reviewed my website.