A break from the strategic essays this week. I have spent the last two days getting voice calling working on Pulse — the customer-support agent that lives at pulse.faxter.com, and the second module in the suite I have been writing about. The way the day actually went is, I think, a more useful artifact of what “vibe coding” looks like in practice than another piece of theory.

So this week, an interlude. A field journal. A real engineering arc that started with a question and ended at 1:30 AM with a hundred and fifty lines of replacement code that should not have had to exist.

Strategic essays resume next week.

Setup

It started with a single question: what do you think about adding voice call to Pulse? That kicked off about fourteen hours of dense collaboration with an AI coding assistant. Most of it productive. The last six hours a debugging marathon I won’t forget.

By the end, Pulse could receive WhatsApp voice calls, ring every available staff dashboard, and let an agent answer with their browser microphone. The customer hears them. They hear the customer. Real audio over a real WebRTC pipeline.

But the story is not really about voice calls. It is about how a human and an AI assistant work through a hard problem when the easy answers run out.

The Clean Half

The first eight hours felt like flow.

We started by thinking before building. Architecture, then UI, then a roadmap. The assistant pushed back on my initial impulse to dive in — let’s settle the open questions first, then the roadmap writes itself. It wasn’t wrong. We made decisions about transport (WebRTC for free, Twilio for paid features), about ringing behaviour (simultaneous, fastest finger), about transfer (in-browser staff transfer for both, WA-number transfer Twilio-only). Each one captured in a docs file with the why attached.

Then we shipped Phase 0 — the schema, the Call model, the webhook dispatch — in one tight commit. I placed a real call to my business number and we both watched the engine.io payload arrive in the logs. Field names matched. The plan worked.

Phase 1 was the part I’m proudest of. The work split cleanly into a backend half (Meta API client + answer/end wiring) and a frontend half (incoming-call toast + WebRTC SDP exchange + in-call panel). The assistant suggested we lock the contract surface between them — the call:incoming socket payload shape, the answer endpoint signature — and then dispatched two agents in parallel, each on its own git worktree. They came back roughly an hour later. The merges were clean because the contract was locked. That part was a small revelation: parallel AI work isn’t fragile if you treat the integration boundary like an API.

The Trouble Starts

It was about commit fifteen of the day when the first cracks appeared. A crash about timezone arithmetic. A 400 from Meta about a deprecated typing_indicator. Some 500s from the Baileys sidecar replaying buffered messages that included WhatsApp Status updates from status@broadcast.

Each of these was a real bug, none of them caused by our voice work directly, but all of them surfaced because our voice work created new sessions and new database states and new restart events that exposed latent issues. We fixed them one by one. The assistant pushed back when I said one was “new” — the constraint has been there since the initial migration, the bug is pre-existing. I pushed back harder — I was running this without errors before our changes. We were both kind of right. The bugs were latent; our changes activated them.

Each fix was small. Each one mattered. And each one was followed by “now real-time should work” — and it didn’t.

The Mystery

By midnight I had voice working in test calls but the dashboard wasn’t updating live. Messages would arrive in the database. The agent would reply. The customer would receive the reply. But on the staff screen, nothing — until I pressed F5.

The assistant and I went through a dozen hypotheses. None of them right.

• It’s the auth token expiring. It wasn’t.

• It’s WORKERS=4 without proper Redis fanout. We set it to 1; still broken.

• It’s nginx misconfigured. I pasted my config; textbook correct.

• It’s the Service Worker caching old JS. Tested in Incognito; same problem.

• It’s the wss:// URL scheme tripping socket.io-client. Coerced to https://; same problem.

• It’s the explicit transports config. Removed it; same problem.

Around hour three of this I made a decision that turned the whole night around. I asked the assistant to instrument the transport itself — to monkey-patch WebSocket.prototype.send at the very top of the entry point and log every byte that left the browser. Stop guessing. Show me the wire.

What I saw next is what I want to remember.

The browser sent 2probe (engine.io upgrade probe). It sent 5 (engine.io UPGRADE commit). It PONGed back when the server PINGed. It did everything except send the one packet that mattered: 40{"token":"..."} — the Socket.IO namespace-connect packet. The auth callback was firing — socket.io-client thought it was sending — but the bytes never made it to the wire.

To prove the wire wasn’t the problem, we did a brutal test: I pasted a raw WebSocket connection into my browser console, manually typed 40{"token":"..."} and called ws.send. The server received it. The connect handler ran. Everything that should have worked, worked — bypassing socket.io-client entirely.

That was the moment I understood: the library itself was lying about what it was doing.

The Pivot

There’s a cliff in any project where you stop trying to fix something and start trying to replace it. We were standing at that cliff at 1:30 AM. The assistant proposed it cleanly — Branch B4: write a raw-WebSocket adapter. About 150 lines. We knew the protocol; we’d just used it manually. There was no real reason to keep fighting socket.io-client.

I said yes.

The adapter went in fast. The assistant wrote it; I reviewed; we shipped. The first version had a small race condition — emits dispatched before the connect ack got dropped — and we fixed it by adopting socket.io-client’s own pattern: buffer pre-connect, flush on connect.

Then real-time worked.

A WhatsApp message arrived at the dashboard live. An incoming-call toast appeared the instant a call came in. Six hours of debugging ended in a single page reload that did everything it was supposed to do.

What I’m Taking From This

A few things I want to remember the next time I do this.

Plan before you build. The hour we spent on the architecture doc and the contract lock saved us at least three later. When the parallel agents merged cleanly, that was the dividend.

The assistant proposes; you verify. Several of my best moments in this session were pushing back. No, I really was running this without errors. No, that’s not enough evidence to commit a fix. Show me the actual diff. The assistant is excellent at making plausible hypotheses, and plausible hypotheses are not the same as true ones.

Instrument before you fix. Until I saw [ws.send] data=40{...} not appearing on the wire, every fix was a guess. The diagnostic patch was the real breakthrough; everything before it was theatre.

Bypass beats heroics. When socket.io-client wouldn’t cooperate after four config combinations and a version downgrade, the right move was not to keep configuring. It was to ship 150 lines of replacement code and stop depending on the broken thing.

Persist your findings. We saved memory entries — if real-time looks broken, check these three things in this order — so the next session doesn’t redebug from scratch. That’s a discipline, not a feature.

The marathon is part of the work. I almost gave up around hour four. The assistant didn’t, partly because it doesn’t get tired, partly because debugging is what it’s actually good at when you give it the right tools. There’s something useful about having a partner who’ll sit with you in the same problem at 1 AM and not flinch.

I’m going to bed. The dashboard is updating live. The voice toast pops up the moment a call rings. Customers can hear staff. Staff can hear customers.

Eight hundred lines of new code. Twenty-seven commits. One latent bug from a year ago, one new library written from scratch, and one really long night.

Worth it.

That interaction was not possible eighteen months ago. Not in any product, on any platform, at any price. The thing that made it possible — a model competent enough to read a document, hold a memory of past behavior, ask the right clarifying question, and take a real action on the user’s behalf, all in the time it takes to stir a cup of coffee — only exists now. The thing I built on top of it, which is what I want to write about today, was not supposed to be a product. It was a tool I built so I could stop hating my own bookkeeping.

This essay is about how it stopped being mine.

What Clerk actually is, in concrete terms

The previous essays in this series have talked about Clerk in the abstract — as a thesis, as a bet, as the first agent in a Business Operating System. I have not, until now, told you what it actually does, and I think the abstraction is starting to work against me. So before anything else, here is the product, in the order a real user encounters it.

You sign up. You tell Clerk what kind of business you run. It uses that to set up a chart of accounts that fits — sole proprietorship, professional services, retail, non-profit. Five steps. Under five minutes. By the end of onboarding you have a working accounting system, configured for your jurisdiction, with the right tax codes already wired in.

You connect a bank account. Either you upload a CSV from your bank — which is what most Nigerian users do, because the bank APIs here are not great — or you connect through Mono if your bank supports it, or Plaid if you are somewhere else. Either way, the transactions land in Clerk. Within a minute, they have all been categorized. Not with keyword matching, the way QuickBooks does it. The model actually reads each transaction and decides what it is in the context of your business. The first round of categorizations will get a few things wrong. You correct them. The corrections become rules. Next month, those same patterns get caught automatically.

You start sending Clerk documents. A receipt photo from your phone. A vendor’s invoice that arrived in your email. A scanned expense report from a colleague. A bank statement PDF. Clerk reads them, extracts what is relevant, links them to the right transactions, and stores them permanently. Six months later, every transaction in your books has a source document attached to it that you can pull up in two clicks. This is the part that changes the relationship a small business owner has with their books, and I will come back to it because it is more important than it sounds.

You ask questions. “What’s my profit this month?” gives you a real answer with the numbers and a quick explanation of what changed. “Why did expenses jump in March?” pulls the actual transactions that drove the jump, grouped by category, and tells you which lines are out of pattern. “Send me a balance sheet for the auditor” generates a PDF in three seconds and emails it where you ask. The asking happens in the same chat window you used to upload the receipt, or over WhatsApp, or in Slack, or in the web app. Clerk is the same agent in every channel, with the same memory, the same tools, the same opinion about how your books should be kept.

You generate invoices. You say “send Acme an invoice for the web design work, three hundred thousand naira, due in thirty days” and Clerk drafts it, asks for whatever it does not already know, sends it, books the receivable, and tracks the payment status until the money comes in. When the payment lands in your bank account, Clerk recognizes it, matches it to the invoice, marks it paid, and posts the journal entry. The whole loop — invoice, reminder, payment, reconciliation — happens without you opening a screen.

You run payroll. Clerk knows your employees, knows the statutory deductions for your jurisdiction, and runs the calculation when you tell it to. PAYE, pension, NHF for Nigerian users. PAYE and NICs for UK users on the partner’s instance. The payroll journal entries post automatically. The payslips generate automatically. The compliance filings draft themselves.

You forecast. “What does my cash flow look like for the next six months at our current burn?” gets you a real ML-based projection — ARIMA on the revenue side, Prophet for seasonality, monte carlo for the scenarios. Clerk shows the assumptions it is making and lets you change them. What if we land that contract. What if FX moves five percent. What if the new hire starts a month later. You can save scenarios, compare them, and walk into a board meeting with a real model rather than a wishful spreadsheet.

You collaborate. If you have a bookkeeper, an accountant, or a co-founder, they get their own login with the right permissions. The system is multi-user from the start. They can edit what they are allowed to edit. The audit trail records every change. You can leave each other comments on transactions. You can share a report with your investor in one click — they get a read-only view scoped to exactly what you want them to see.

That is, roughly, the product. There is more — a spreadsheet editor with formula support, a plugin system for custom workflows, a knowledge base for tax and accounting rules, executive dashboards — but the core, the thing that does most of the heavy lifting, is what I just described. A small business’s entire back office, run by a competent agent that you can talk to in any channel, with documents linked to everything and tax compliance built in.

This is what people are asking me for when they ask if they can use it. Not the abstract Business Operating System. This.

Why accounting was waiting for this

There is a deeper question lurking under the product description, and I want to answer it before I go any further, because I think it is the most under-discussed thing about why Clerk works at all.

Why is accounting uniquely suited to be solved by a competent AI, in a way that a lot of other small-business pain is not?

The pat answer is that accounting is “structured” — that the rules of double-entry bookkeeping are well-defined, that there is a right answer to every question, that this is the kind of domain where a precise system can shine. That answer is wrong, or at least it misses the point. The right answer is closer to the opposite. Accounting is uniquely suited to AI because the rules are structured but the inputs are unstructured to the point of hostile, and bridging that gap is exactly what large language models are good at.

Think about what a bookkeeper actually does. They look at a bank statement that says TRSF FRM/MUSA/RECON and decide whether that is a customer payment, a personal transfer, a vendor refund, or a loan repayment from a friend. They look at a receipt scan that is blurry, partially in another language, missing the date, and figure out what it represents and which account it should hit. They look at an invoice that uses one set of terminology in a vendor’s industry-specific format and translate it into the standard chart of accounts. They look at a payment that does not quite match any open invoice and decide whether it is a partial payment, a duplicate, or for something that has not been billed yet. The judgments are constant. They require context — about the business, about the people, about the history. The volume is high enough that no software written in the last forty years has gotten close to handling them without a trained human in the loop.

Traditional accounting software gives up on this problem. It accepts that the inputs are messy, refuses to do the judgment, and pushes the messiness onto the user. Categorize this. Match this. Reconcile this. The user, if they are not a trained accountant, mostly gets it wrong, gives up, and the books get worse over time. That is the failure mode of QuickBooks and Xero and every other product in this category. It is not a failure of the software. It is the software doing exactly what it was designed to do, and what it was designed to do is help an accountant — which would be fine, except that most small businesses do not have an accountant, and that is the actual problem.

A capable AI does not give up on the messy input. It reads TRSF FRM/MUSA/RECON and asks who Musa is and what kind of relationship you have with him, and once you tell it, it remembers. It looks at the blurry receipt and pulls out the date, the vendor, the amount, the line items, and asks about the one field it could not read. It looks at the partial payment that does not match any open invoice and proposes three explanations, ranked by likelihood, and asks you which is right. It bridges the gap between what the world actually gives you — bank statement narrations, smartphone photos of receipts, emails from suppliers, voice notes from your delivery guy — and what the books require, which is consistency, completeness, and double-entry discipline.

That gap is the gap small businesses have been falling into forever. It is the reason their books are always behind, always slightly wrong, always too painful to reconcile. The gap is bridgeable now. It was not bridgeable a year ago, not at this quality, not at this price. And once it is bridgeable, accounting stops being a thing small businesses do badly because they cannot afford to do it well, and starts being a thing that runs in the background, like email, or maps.

This is what makes Clerk a category change, not a feature update. We are not building a better accounting app. We are building the first accounting system that does not require a trained human to operate. That is a different thing, and the difference is most of why this works.

How I noticed it had stopped being mine

I was using Clerk to run Microscale. The books were cleaner than they had ever been. I was spending maybe a tenth of the time on accounting that I had been spending before, and the time I did spend was almost all reviewing decisions Clerk had already made, rather than making decisions from scratch.

I was telling people about it, the way you tell people about any piece of software that has materially improved your week. The conversations started to repeat themselves. I would mention, in passing, that I had built a thing. The other person would ask what it did. I would explain. The other person would be quiet for a beat, and then they would ask — not politely, but with something close to urgency — whether they could use it. Whether I would sell it. Whether I could give them a login for their company.

The first few times, I was flattered. By the fifth time I started to notice something. By the tenth time I could not un-notice it.

What I noticed was this. Every single person was describing the same pain. Not a related pain. Not a cousin of the pain. The exact same pain, in the exact same words. I cannot afford an accountant. The software is too complicated. My books are always behind. I am scared of what due diligence will turn up. I know what I am doing wrong but I cannot fix it. Different industries. Different sizes. Different cities. Different people. The same words.

I had assumed my situation was specific. It was not. It was shared, by roughly every small business owner without a finance team — which is most of the small businesses in the world. The pain was universal. The thing I had built to fix my own version of it was, without my trying, the thing a large number of other people were also trying and failing to fix. The reason nobody had built it was that until very recently, building it had been impossible. Now it was possible. I happened to be one of the first people to have built it and lived with it long enough to know it actually worked.

This is the moment I want to be honest about, because I think it is the most repeatable lesson in this essay. I did not have a flash of entrepreneurial insight. Insights are guesses about markets you have not entered. I had a flash of recognition, which is a different and more reliable thing. Recognition is just seeing that the thing in front of you is also in front of other people. You are not predicting anything. You are noticing something. The difference between the people who build accidental products and the people who do not is mostly the willingness to notice.

The hard part of the transition

I want to spend a paragraph on the part of this story that I find people consistently underestimate, because I think it is where most internal tools die when they try to become products.

The naive view is that the gap between “a thing I use” and “a thing other people can use” is a features gap. You built it for yourself, so now you have to add multi-tenancy, permissions, onboarding, billing, a hundred things you did not need when you were the only user. That gap is real. It is also the easy part. Features are tractable.

The hard part is that when you open your tool up to other people, you lose the feedback loop that made the tool work. You were building for you, and the tightness of that loop — every broken thing surfacing within a day, on real data, with real consequences — was what let you ship fast and prioritize ruthlessly. The moment you have other users, you have to start building for people who are not you, and if you are not careful you slide into exactly the kind of composite-user guessing game you had successfully avoided. The accidental product starts becoming a deliberate product, and deliberate products are often worse.

The thing that has rescued me here, and that I think is going to keep rescuing Clerk as it grows, is that I never stopped being a customer. I am still using Clerk to run Microscale. I am still the first user of every feature. I still feel the pain before any of my paying customers feel it. Microscale is not just a customer; it is a reference implementation. As long as Microscale’s books are the ones I care about most — and they are, and will be for a long time — there is at least one real user with a real life depending on this software, and that is enough to keep the product honest.

The lesson, for anyone reading this and wondering whether their own internal tool is secretly a product, is that the test is not “are other people interested.” Of course other people are interested. There is a new capability in the world, and any tool built on top of it feels interesting to anyone who does not have one. The real test is whether you can open the tool up to other people without breaking the thing that made it good in the first place. Whether you can keep the honest feedback loop alive while adding the features and the scaffolding and the multi-tenancy that opening up requires. Most builders fail this test. I am trying very hard not to.

The shape of an accidental product

There is a category of product emerging right now that I think is going to define a lot of the next few years of software, and I want to name it explicitly because the name has not settled yet. Call it the accidental product. The defining features:

It was built to solve one specific person’s problem, by that person, using AI tools that did not exist eighteen months ago.

It works unusually well in its core use case, because the builder was the user and the feedback loop was tight enough that everything that did not work got fixed within a day.

It is unusually opinionated, because the builder did not have to compromise with a market.

It is idiosyncratic in ways that look like flaws to a market researcher and like virtues to other people with the same problem.

It is hard to copy, because the thing that made it good was not a feature list or a market insight. It was a specific person solving a specific problem with a tight feedback loop, and copying that without the specific person is harder than it looks.

These products do not look like venture-backed software. They are not designed to be unicorns. They are scrappy and narrow and full of assumptions that only make sense if you are the exact person who built them. But because the pain was real and the feedback loop was tight, the tool works. It actually solves the problem. And then, almost inevitably, it turns out the pain is not unique to the builder, and the tool gets pulled out of its creator’s hands by people who also need it.

I think this is going to be a dominant pattern for software in the small-business space for the next several years. Not because solo founders are going to displace SaaS companies overnight, but because the new tools have made it possible for a single person with a real problem to build a real solution without any of the apparatus a software company traditionally requires. No team to convince. No market to validate. No deck to pitch. Just the problem, the builder, and a model competent enough to do most of the typing. The thing that this changes is not how much software gets built. It is who gets to build it. And the products that come out of that shift are going to be different — more opinionated, more specific, harder to imitate — than the products that came out of the previous era.

Clerk is one of those products. Pulse, the customer support agent already running at pulse.faxter.com, is another. The next agent in the suite will be a third. I am not the only person noticing this pattern, and I do not need to be. The pattern is inevitable now. What I am doing — writing this series, hiring a team, building the rest of the suite — is just the part of the inevitability that I happen to be participating in.

What I think this means for you

I want to end with a question rather than a conclusion, because I think the question is more useful.

Is there a tool you have built for yourself in the last twelve months that you have stopped being able to live without? Not an experiment. Not a script. A tool you actually use, on real work, that has materially changed how you do something. If yes, the next question — the one I want to leave you with — is whether you have noticed yet that other people have the same problem you built it to solve.

They probably do. They are probably already telling you about it, in passing, the way the people in my conversations were telling me. You are probably explaining it away as flattery. It is probably not flattery.

If that is true, then the only thing standing between you and an accidental product is the willingness to notice, the willingness to take it seriously, and the willingness to do the unglamorous work of opening it up to other people without breaking the thing that made it good in the first place. Most of the people who build internal tools never do this. The ones who do are going to define the next several years of software.

I noticed mine. This series is what I am building from the noticing.

If you noticed yours, I hope you build it.

This essay is about that update.

Year one: vibe coding as glorified autocomplete

When we were building Faxter, “AI-assisted coding” meant something specific and limited. You had a chat window open in one monitor and your editor in the other. You described what you wanted. The model gave you a block of code. You read it, understood it, usually rewrote half of it, and pasted the rest. Then you debugged, because the model had hallucinated an API that didn’t exist, or used a library version from two years ago, or confidently produced something that would compile and run and silently corrupt your data.

It was useful. It was genuinely useful. I built, largely alone, a working public cloud platform — virtualization, billing, the control plane, the whole software stack — at a speed that would have required a real engineering team a few years earlier. But the human was doing all the thinking. The model was a faster way to produce boilerplate and a pretty good rubber duck for design questions. It was not, in any meaningful sense, a collaborator.

The mental model I had then was: the AI is a very fast junior who cannot be trusted with anything load-bearing. Every line it produced passed through my head before it reached the repo. That was the correct mental model for the tools available. It is not the correct mental model anymore, and the fact that a lot of smart people still hold it is why I keep having the same conversation at dinners.

Year two: the model can hold a problem in its head

Sometime in late 2025 and through the first quarter of 2026, this changed. Not gradually. The models stopped producing snippets and started producing work. You could describe a feature, point at a repository, and get back a change set that understood the existing code, touched the right files, matched the conventions, and ran. You could ask for a refactor that spanned a dozen files and get it done in a single pass. You could say “the bug is somewhere in how we handle VAT on imported goods” and come back twenty minutes later to find it diagnosed, fixed, and tested.

The thing that had changed was not just code quality. It was duration of coherent reasoning. The old models lost the plot after a few hundred lines. The new ones could stay on task for a whole feature. That sounds like a small difference. It is not. It is the difference between a tool and a collaborator, and everything downstream of that distinction — how you plan work, how you structure a codebase, how many people you need, what a “team” even is — changes.

I started building Clerk right as this shift was happening, and the journey from the first commit to where I am now is the clearest picture I have of what vibe coding actually is in 2026.

The first architecture was a mistake. So were the next four.

I started by trying to build an agent from scratch. This was a mistake, but it was the kind of mistake you have to make in person to understand. I had opinions about how an AI agent should be structured — planning layer, execution layer, orchestration layer, response formatter — and I built all of it by hand. It worked, in the sense that it ran. It did not work, in the sense that every new feature was harder than the last one, and I spent more time maintaining my own scaffolding than I spent on the accounting logic that was the actual point.

So I threw it away and tried a second design. Then a third. Then a fourth. Each one was a different theory of how to decompose the problem — a tiered planner that routed simple queries to cheap paths, a composite-operations framework that let me define workflows declaratively, a three-stage response pipeline, a dual-agent system where a custom orchestrator handled the cost-sensitive cases and something smarter handled the rest. Each of these sounded like a good idea at the whiteboard. Each of these was, in retrospect, a version of the same mistake: I was building a framework when I should have been building a product.

The fifth attempt was LangGraph’s ReAct pattern. It worked on the first try. Not because LangGraph is magic, but because it stopped me from building the scaffolding I kept insisting on building. ReAct is almost embarrassingly simple: the agent reasons, picks a tool, acts, observes the result, reasons again. That’s it. There is no planner, no orchestrator, no tiered router. The model handles complexity natively because the model is actually capable of handling complexity now, and every layer I had been lovingly constructing around it was just a cage that constrained what a capable model could do.

This is the single most important thing I have learned from vibe coding in 2026, and it is counterintuitive enough that I want to say it plainly: the better the model gets, the less software you should write around it. Every abstraction you add is a bet that the model is dumber than it actually is. That bet kept being wrong. It kept being wrong faster than I could take it off the table.

The clean restart

By early 2026 the codebase was an archaeology of good intentions. Four agent architectures’ worth of dead code, two parallel agent systems, a 2,500-line response formatter, a capability registry with forty entries, composite operations defined in JSON-like structures, hardcoded tax rules, template-based responses that felt robotic, and a planning layer I could no longer justify. It worked. Users used it. But every change was painful, every bug fix risked breaking something else, and onboarding a new contributor — even an AI one — was an exercise in forensic anthropology.

I did something I had not done before. I asked Claude Code to read the entire project and summarize, in brutal detail, what we had learned. What worked. What didn’t. What we’d do differently. What anti-patterns we kept falling into. No diplomacy. No face-saving. Just the lessons.

It produced ten articles’ worth of prose. I read it twice. Most of it was things I already knew but had not let myself say out loud: the dual-agent system was fundamentally flawed because users needed one way to do things, not two. Templates were a mistake because every response felt generic when it should have felt like a conversation. Accounting rules should have been data, not code, because tax laws change and jurisdictions differ. The “just one more layer” instinct had cost me more than any other single habit. The 80% of features half-finished were worth less than the 20% finished to 100%.

Then I did the thing you are not supposed to do. I started over. I used the ten articles as the prompt. I told Claude Code to build Clerk again from scratch, with those lessons as hard constraints, and I sat with it for a week.

The new codebase was done in seven days. 100% AI-generated code. Not “AI-assisted with heavy human rewriting.” AI-generated. I read every diff, I made decisions at every fork, I redirected when it went off course, but I did not write the code. I directed the code. The distinction matters.

The rebuilt system was smaller than the one it replaced, cleaner, faster, and — this is the part that still surprises me — more capable. The discipline of the lessons-learned prompt forced it to refuse the abstractions I had been too attached to delete by hand. A human rewrite would have smuggled half of the old complexity back in out of sentimentality. The AI had no sentimentality. It just built the thing.

What I actually do now

People ask me what “vibe coding” looks like in practice in 2026, so here is the honest version, from the inside.

I spend most of my time doing three things: deciding what to build next, reading diffs, and arguing with the model when its first instinct is wrong. The actual typing of code — the thing I used to think of as “programming” — is now the smallest part of the loop. Most days I don’t touch the keyboard to write code at all. I touch it to write prompts, to read what came back, and to say “no, do it this way instead, and here is why.”

The skill that matters is not prompt engineering in the sense of magic incantations. It is taste. It is knowing, when the model shows you a diff, whether the diff is right. It is knowing which of the four reasonable-looking approaches it just proposed is the one that will compound into a clean codebase six months from now versus the one that will metastasize. The model can generate five plausible architectures in the time it takes you to read one of them. The value you add is picking the right one and refusing the other four, fast, with conviction.

The other skill that matters, and that I did not expect, is refusing to intervene. When you are used to writing code by hand, watching an agent work is excruciating. It goes down paths you wouldn’t have taken. It tries things you know won’t work. Your instinct is to stop it, grab the wheel, and do it yourself. That instinct is almost always wrong now. Most of the time the agent recovers. Most of the time its path, even when it’s not the one you would have taken, arrives somewhere fine. Every time you interrupt, you are trading a small amount of its momentum for a small amount of your control, and the exchange rate is worse than it feels.

I have had to unlearn the habit of mid-air corrections. I try to set the agent up well, let it work, and review the result. If the result is wrong, I tell it what was wrong and let it fix it. The temptation to micromanage is strong and almost always counterproductive.

The rules I now refuse to break

After two years of this, I have a short list of rules that I will not violate, because each of them was earned by ignoring it and paying for it:

One way to do things. If your system has two agents, two codepaths, two ways to reach the same outcome, you will spend the rest of the project’s life paying for the choice. Pick one. Delete the other. If you can’t decide, flip a coin — being wrong is cheaper than being split.

No templates for anything the user reads. If a human is going to read it, a model should write it. Templates feel robotic because they are robotic. The entire point of an AI-native product is that the product can talk. Don’t gag it.

No hardcoded rules for anything that changes. Tax rates change. Jurisdictions differ. Accounting standards evolve. Anything that lives in the world, and the world gets to modify, belongs in a knowledge base the model can read — not in an if statement.

The minimum path from API to database. If your request diagram has more than four boxes, you have too many boxes. Every layer is a bet that you are smarter than the compiler and the model combined. You are not.

Read the lessons before starting work. I keep a LESSONS-LEARNED.md file in the repo and I load it into context at the start of every serious session. It is the cheapest insurance I have ever bought. The anti-patterns you fell into last month are the anti-patterns you will fall into this month if no one reminds you.

Let the model finish. Whatever is happening, let it finish. Then judge. Interrupting is almost always worse than reviewing.

Finish the 20% before you touch the 80%. At every stage of Clerk I have had the temptation to start the next shiny feature before the current one is actually done. Every time I have given in, I have ended up with another 80%-complete feature in a codebase that already had too many. Finish. Ship. Then expand.

What this changes

The question I get asked most often is whether this is real leverage or a party trick. Is a solo founder with Claude Code genuinely equivalent to a team of five, or are we all going to wake up in a year and find out the code we shipped at 3x speed is unmaintainable garbage?

My honest answer, after two years of actually doing this: it is real leverage, but it is leverage that rewards a specific kind of operator. If you have taste, if you can read a diff and know whether it’s right, if you can hold a product vision in your head and steer toward it, if you can resist the urge to micromanage and also the urge to trust too much — then yes, the multiplier is large, maybe larger than people are willing to say in public. I have shipped more working software in the last year, alone, than a funded team of engineers would have shipped on the same problem a few years ago — and the difference is not me. The difference is the tools.

If you don’t have those things, the leverage is still there, but it cuts both ways. You will produce more code, faster, and some of that code will be wrong in ways you cannot see, and by the time you find out the pile will be too tall to excavate. The failure mode is not “AI writes bad code.” The failure mode is “human who cannot evaluate AI output accumulates bad code faster than ever before.”

The thing I believe, and that I am betting Clerk on, is that the people who learn to do this well will have a window of a few years where they can build entire products that would previously have required entire companies. Not because they are smarter. Because the cost of converting a decision into working software has collapsed, and the bottleneck has moved upstream to the decisions themselves.

That is what the year of vibe coding with Claude Code taught me. The bottleneck moved. You either moved with it, or you are still writing code by hand and wondering why the people who didn’t are shipping so much faster.

I know which side I’m on. The next essay is about what you build when you’re on that side — and how the tool you built to run your own business starts turning into a business of its own.

That weekend was the beginning of this story, though I did not know it yet.

I run Microscale, an embedded systems company in Abuja. We design hardware and we write firmware. Accounting is not what we do. What we had, up until that weekend, was an Excel workbook — an income-and-expenditure tracker that balanced, in the sense that the columns added up, but that was only as complete as the transactions we remembered to type into it. Which, honestly, was never all of them. A real business does not run on a workbook that depends on whoever happens to be paying attention that week. Ours had been getting away with it, but we both knew it.

What was wrong with QuickBooks

The problem was not that QuickBooks was bad. QuickBooks is not bad. QuickBooks is, by any reasonable measure, a competent piece of software that does what it says it does, at a price that is fair for the work involved. The problem was that QuickBooks was not built for me.

What QuickBooks was built for is a person who already knows how to do accounting and who wants software that accelerates the work they would otherwise do by hand. When that person sees a screen full of uncategorized transactions, they know what to do with it. They look at the list, they apply their judgment, and they go. When I saw a screen full of uncategorized transactions, I stared at it. What account does a cash withdrawal at a bank ATM go under? What about the dozen transfers to names I half-recognized? What about the Shopify payouts — gross or net of fees? What about the transfers that looked like they were between my own accounts but might not have been? I did not know. I knew the business. I did not know the books. And QuickBooks had no opinion about that gap, because it was not designed to. It was designed for someone who had already crossed it.

That is — and this is the important part — the normal outcome for a small business owner who tries to set up accounting software without an accountant next to them. You do not fail loudly. You do not throw your hands up and curse the product. You put in a few hours, you hit a wall, you promise yourself you will come back to it over the weekend, and you do not. It is not a failure of will or intelligence. It is the software assuming a skill you do not have, and declining to close the gap on your behalf.

Why I was trying in the first place

Two things had me trying at all.

We were preparing to raise, and investor diligence is not compatible with “my books are roughly okay.” Every number has to tie out. Every transaction has to have a story. You need to be able to explain why this line moved and where that payment went, without qualifying the answer.

The second was Nigeria’s 2026 tax law, which was moving through the legislature at the time and is now in force. The old regime had a lot of slack in it — informal reconciliation, patchy filings, a tolerance for small-business messiness. The new regime has less slack, and more of what slack remains is going to be audited out over the next few years. The writing was on the wall. If we did not get our accounting house in order voluntarily, we were going to be forced to do it involuntarily, and more painfully.

There was also a third thing that nobody on the outside could see yet. Jim — my co-founder, who had come over from our previous company, Faxter — and I had been having a recurring conversation for months. Faxter had not worked. We had shut down the infrastructure business, and the shutdown had left us with something unusual: runway. Not enough to start something ambitious from scratch, but enough to place a real bet on the next thing. We had been brainstorming what that next thing should be, and the shape of our conversations kept coming back to AI. Not because “AI is hot” — that much was obvious to everyone — but because the part of AI that was becoming genuinely capable was the part we were best positioned to build with. Agents that could do real work inside real businesses.

We did not know what the first product was yet. We knew there was funding, we knew there was a window, and we knew we wanted to spend both on something in AI. Beyond that, we were waiting for a problem that was sharp enough to justify building a solution.

Clerk presented itself.

The weekend with the bank statements

A few weeks after the QuickBooks attempt, I decided to try something different. I had all three of our bank statements as CSV files. I had a year’s worth of transactions. I had been using Claude Code heavily for engineering work. I dropped the CSVs into a session, described the business, and asked it to help me figure out where the money had gone in 2025.

It came up with a lot more than I expected.

Over the course of a long weekend, working through the transactions interactively, Claude Code did real double-entry bookkeeping. Not keyword categorization. Real journal entries, a trial balance, an income statement, and a balance sheet. Every entry balanced. Every account reconciled.

The part that convinced me was not the automation. It was the conversation. Nigerian bank statement narrations are messy — the bank truncates names, merchants use aliases, and half the transactions are human-readable only if you know who the humans are. A lot of the work was me explaining. This transfer to Musa? He is an FX intermediary; sometimes those payments are for goods, sometimes they are investor loan repayments — you will have to check the context for each one. That transfer to my own name? Not a drawing. I was paying for freight. Only the transactions literally tagged “DRAWING” are actual owner drawings. Each time I clarified, the classifications adjusted. The model did not argue. It did not re-make the same mistake two transactions later. It held the context.

And it did the accounting itself. I was bringing the judgment about what transactions were; it was bringing the discipline of what to do with them. Somewhere around hour four, I realized I had started to understand things I had never understood before. Double-entry bookkeeping — the idea that every transaction moves two accounts at once, and that the whole system stays honest because those two sides always have to agree — had, up until that weekend, been a piece of accountant jargon I nodded at politely. Now I was watching it in motion, line by line, on my own numbers, and it finally made sense. COGS. Accruals. The logic of why a cash movement and a revenue event are not the same thing. I was not being taught the concepts. I was being shown them, in the context of data I already understood, by a collaborator who had the patience to walk each one through as it came up. By the end of the weekend I had, almost as a byproduct, learned more real accounting than I had in years of skimming blog posts about it.

When I came up for air at the end of the weekend, I had a set of books that were, for the first time in the company’s history, actually complete. I had a clear picture of what we had earned, what we had spent, where the money sat, and the audit trail I had been unable to produce in QuickBooks. I had the understanding of our year that I had been trying to buy from an accountant.

I had not meant to build a product. I had been trying to close my books. But I had, in the course of closing my books, accidentally built the kind of accounting software I had wanted QuickBooks to be — except it existed only inside a Claude Code session, inside the specific problem I had been solving, for the specific business I ran.

That was the moment the question changed. It stopped being “which accounting package should I buy?” and became “what if the accountant is the software?”

The decision

I did not decide to turn this into a company in a single moment. The decision accumulated.

I showed Jim what I had done. He looked at it for a long time. We had been waiting for a problem sharp enough to justify a product, and this was one: my own frustration, my own solution, and — if the weekend with the CSVs was any indication — a capability gap between what AI could now do and what commercial accounting software was shaped like. The gap was wide enough to build a company in.

We also had the context to move fast. I had spent the Faxter years doing AI-assisted coding and knew what the newer agents could ship. We had the runway. We had a market we both understood — Nigerian small businesses, of which Microscale was one. And we had the 2026 tax law as a forcing function that would, over the next few years, push every small business in the country toward better books whether they wanted it or not.

So we started building. Not as a side project, not as a hack. A real system, built to the standard that a company about to raise money needs its books to meet, with Microscale as the first customer and a long list of future ones lining up behind it.

What I took from those first weeks

I want to leave you with the specific thing I learned that first month, because it is the thing the rest of this series is downstream of.

The dividing line between accounting software that works and accounting software that does not is whether it can close the gap between someone who understands their business and someone who understands accounting. QuickBooks does not close that gap. It is built for people who have already closed it. Most small business owners never close it, because the economics do not justify hiring a full-time person who has, and the software does not substitute for that person.

A capable AI can close the gap. Not by being “better software” — by being a different shape of software. One that can hold a conversation about messy transactions, take judgment inputs, apply accounting discipline, and produce books a human can actually use. That is not an incremental improvement over QuickBooks. It is a different category of tool.

Clerk is our bet that building in that category, for a market that has been underserved for a long time, with the tools that have only just become capable enough, is the right thing to spend the next few years doing.

The rest of the series is about what building it has actually looked like.

The short version is this. I run an embedded systems company called Microscale. Sometime last year, I needed an accountant and could not justify hiring one, so I built one out of an AI. The thing I built turned out to be good enough that I started running my own company’s books on it. Then other people started asking if they could use it too. Then a British ERP company found it and decided, in a fifteen-minute meeting, that they wanted to resell it in the UK. Then I realised the thing I had accidentally built was not really an accounting app — it was the first module of something much larger. A suite of AI co-workers. A Business Operating System. The kind of thing that twelve months ago would have been impossible to build alone, and that today I am building anyway, mostly alone, with a co-founder and a lot of help from AI coding agents.

I want to write about it because I think the story is worth telling and because I think the moment we are living in — the moment where a single person can build software that used to require a whole company — is not being talked about honestly enough. Most of what I read about AI is either hype from people who are not actually shipping anything or fear from people who have not actually used the tools. I have been shipping, and I have been using the tools, and I have opinions. I want to express my thoughts in writing.

What the series covers

Over the coming weeks I am going to publish a series of essays about all of the following:

The origin story. Why an embedded systems company decided to bet on AI. What the forcing functions were. How a failed cloud startup two years ago turned out to be the foundation for the thing I am building now.

Vibe coding with Claude Code. What it is actually like to ship production software almost entirely through AI agents in 2026. The rules I have had to learn the hard way. The mistakes I made and the architectures I threw away before one of them worked. A technical companion piece for the engineers who want the gory details.

The accidental product. How an internal tool becomes a company, and how you know when it has. The moment I stopped calling Clerk “my accounting app” and started calling it something much larger.

The Business Operating System thesis. Why I believe the future of small-business software is not better apps but a coordinated team of AI co-workers. What the suite looks like. Why I started with accounting. Why a second agent is already in production.

Our first reseller. How a British ERP company found the product and decided to resell it in the UK after a fifteen-minute demo. What the deal taught me about the difference between a product and a platform.

Hiring the founding team. An open call for the people I need to build the Nigerian operation. This is the most actionable essay in the series — if you are a salesperson, a customer success specialist, an accountant, or an engineer reading this and thinking “wait, is he talking about me?” — you are the reason I am writing it.

Lessons learned. What I got wrong about building with LLMs and what I would tell myself a year ago. What I got right about dogfooding. The partnership that makes all of this possible and why I am not actually a solo founder even though it sometimes looks like I am.

The deep cuts. The design philosophy behind an AI-native product. Why I refuse to template any response the user reads. Why every UI feature has to come with an agent tool. Why the small business owner, not the accountant, is the user.

Who this is for

If you are a founder thinking about AI, I wrote this for you.

If you are an engineer wondering whether “vibe coding” is real leverage or a party trick, I wrote this for you.

If you are a small business owner wondering why your accounting software feels like it was written for someone else, I wrote this for you.

If you are thinking about joining an early-stage company and trying to figure out which ones are serious, I wrote this for you — the recruitment essay in particular.

And if you are just curious about what one person in Lagos is doing with the AI tools the rest of the world is still figuring out, I wrote this for you too.

The cadence

I am going to publish weekly, starting next week, on this Substack. Each essay will also go out in shorter form on LinkedIn, Twitter, and Facebook, but the canonical version lives here. If you want to read the whole thing in order, subscribe. If you want to read only the essays that look interesting to you, the titles will make it clear which ones those are.

A couple of essays will publish out of sequence because they are time-sensitive. The hiring essay in particular — I need the team now, not in three months when it happens to come up in the running order — so expect that one to drop early and to be pinned to the top of the page while I am still reading applications.

One more thing

I am going to write honestly. I am going to tell you about the things that worked and the things that did not. I am going to tell you about the architectures I threw away, the deals that died, the mistakes that cost me months, the partnerships that saved me, and the decisions I am still not sure about. I am not writing a victory lap. I am writing a field report from inside a thing that is still in motion, and I do not know how it ends any better than you do.

But I think the view from here is worth sharing, and I think the people who want to read it will recognize themselves quickly, and I think the ones who don’t want to read it will also recognize themselves quickly, and both of those outcomes are fine.

The first essay goes up next week. Subscribe if you want to read it the moment it drops.

See you then.

If you are new here, start with the intro post below, or jump straight to whichever essay matches why you are reading.

What this series is about

I run an embedded systems company called Microscale. Last year, I needed an accountant and could not justify hiring one, so I built one out of an AI. That tool turned out to work, so I started running my own company’s books on it. Then other people started asking if they could use it. Then a British ERP company signed on to resell it in the UK. Then I realized the thing I had accidentally built was not really an accounting app — it was the first module of something larger. A suite of AI co-workers. A Business Operating System. The kind of product that twelve months ago would have been impossible to build alone.

This series is the field report from inside that build. What I am shipping, what I am learning, what I am getting wrong, what I am betting on, and who I am looking for to help me do it.

If you only read one essay, read this one

→ #0 — I’m Writing a Series. Here’s What It’s About.
The intro post. Tells you everything in five minutes and points you at the rest.

If you have a specific reason for being here

You are a founder thinking about AI.
→ Start with #1 — From Embedded Systems to AI-Native, then #4 — Clerk Is Not an Accounting App for the business thesis, then #3 — The Accidental Product for how internal tools become companies.

You are an engineer curious about vibe coding.
→ Start with #2 — Vibe Coding with Claude Code, then the technical companion #2.5 — The Five Architectures I Threw Away Before Clerk Worked. Those two together are the engineering spine of the series.

You are a small business owner wondering why accounting software feels like it was written for someone else.
→ Start with #3 — The Accidental Product and then #7 — The Small Business Owner Is the User, Not the Accountant.

You are looking for a job at an early-stage company and wondering if this is a serious one.
→ Go straight to #9 — Help Me Build This. It is the recruitment essay. It tells you who I am hiring, what the work is, what the trade looks like, and how to apply.

You are here because of the UK reseller story.
→ #8 — Our First Reseller is the one you want. How a dead deal from two years ago came back to life and became the first commercial partnership for the new company.

You are just curious.
→ Read them in order. The titles and descriptions below will tell you what is in each one.

The series, in order

The essays are being published weekly, with a couple dropping out of sequence when they are time-sensitive. Subscribe to get each one as it lands.

The origin story

#1 — From Embedded Systems to AI-Native: Why Microscale Is Betting the Company on LLMs
Why an embedded systems company decided to bet on AI. What the forcing functions were — a raise, a new tax regime, and accounting software that is not actually built for business owners. How Claude Code reading a bank statement changed everything.

#2 — Vibe Coding with Claude Code: What a Year Inside the Loop Taught Me
What it is actually like to ship production software almost entirely through AI coding agents. The difference between “year one” vibe coding (copy-paste) and “year two” vibe coding (collaborator). The rules I now refuse to break. Why the better the model gets, the less software you should build around it.

#2.5 — The Five Architectures I Threw Away Before Clerk Worked
Technical companion to #2, for engineers. The monolith. The wrappers. The “Accounting OS” refactor. The dual-agent system. The clean rebuild. What I learned about local rationality, smart frameworks, and why a rewrite done by an AI is less sentimental than one done by a human.

#3 — The Accidental Product: How Clerk Was Born From Scratching My Own Itch
The moment an internal tool becomes a company, and how you know when it has. The difference between “I should build an accounting startup” and “I should build myself a thing that does this automatically.” Why building for yourself first is not a cliché but a specific kind of feedback loop that cannot be faked.

The thesis

#4 — Clerk Is Not an Accounting App — It’s the First Module of a Business Operating System
The BOS thesis. Why the future of small-business software is not better apps but a coordinated team of AI co-workers. Why accounting is the correct beachhead. Why a second agent is already in production. What the full suite looks like and why it is only possible to build right now.

The traction

#8 — Our First Reseller: How a British Company Found Clerk and What the UK Deal Looks Like
A dead deal from two years ago came back and became a reseller partnership in fifteen minutes. What the meeting actually looked like. What a reseller tells you about your product that your own customers cannot. Why the relationships you keep after the deal dies are worth more than the ones you build from scratch.

#9 — Help Me Build This: An Open Call for the Founding Team
The recruitment essay. Who I am hiring, what the work is, what the trade looks like, and how to apply. Sales Lead, Customer Success, Accounting Advisor, and senior engineers. If you have been reading the rest of the series and wondering how to get involved, this is the essay that tells you.

The team

#10 — Two Markets, One Codebase: Serving Nigerian and UK SMEs From the Same Platform
Multi-tenancy, tax regimes, currency, compliance, and the discipline of not forking. What the UK reseller forced me to build, what I refused to build, and why serving two markets from one codebase is the test that separates a product from a script.

#11 — Small Teams With Armies of Agents: Team Size in the LLM Era
How much leverage is real, where it breaks, and what kind of team you actually need when a single engineer with a good agent can ship what used to require ten. Why I am hiring anyway.

#14 — The Partnership: Why I’m Not Actually a Solo Founder
Jim, my co-founder — university friend, the one who joined me from Faxter and runs the business side while I run the technical side. Why the “solo founder with an army of agents” story is incomplete without him, and what a real technical/business co-founder partnership looks like at this stage.

The reflection

#12 — What I Got Wrong Building With LLMs (And What I’d Tell Myself a Year Ago)
The lessons-learned essay. The anti-patterns I keep falling into, the mistakes that cost me months, and the things I would send back in time if I could.

#13 — Dogfooding Clerk to Run Microscale: Running a Real Business on Software You’re Still Building
The feedback loop of being your own most demanding customer. What breaks when the software you ship is also the software your company runs on. Why I am never going to stop.

The deep cuts

#5 — AI-Native vs AI-Bolted-On: A Design Manifesto
Single LangGraph agent. Tools as the unit of extensibility. No hardcoded rules. Documents as first-class citizens. The principles behind Clerk, stated as a manifesto for anyone building something similar.

#6 — Every UI Feature Needs an Agent Tool: Designing for Two Interfaces at Once
The parity rule. Why I refuse to ship any feature that the AI cannot also reach. What this rule costs, and why I am convinced it is right.

#7 — The Small Business Owner Is the User, Not the Accountant
Why most accounting software gets this wrong, and why getting it right changes everything about how the product is designed. Persona-driven design for an audience that has been ignored.

Stay updated

New essays drop weekly, with time-sensitive ones published out of sequence. Subscribe below to get each one in your inbox the moment it lands, or follow along on LinkedIn, Twitter, or Facebook for shorter excerpts.

If any of this resonates, I would love to hear from you — hit reply to any email, leave a comment on any essay, or email me directly. I read everything.

— Ahmad