From Embedded Systems to AI-Native: Why Microscale Is Betting the Company on LLMs

I spent a weekend last year trying to make QuickBooks Online work. I signed up. I connected it to our Shopify store. I imported the bank statements. I sat with the transactions view for a few hours — clicking through categories, guessing at account mappings, trying to figure out what the software wanted from me. Then I closed the browser, and I did not open it again.

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.