The Accidental Product

How Clerk Was Born From Scratching My Own Itch

A vendor sends me an invoice. I am in a coffee shop, between meetings, with maybe ninety seconds before I need to be somewhere else. I open Clerk in a browser tab and drop the PDF into the chat. Within twenty seconds it replies: a draft bill, the right vendor, the right amount, the right due date, a question about which project to charge it to, and a note that this vendor’s last invoice was paid eleven days late — would I like a reminder this time? I click “Project A” and “yes.” The bill is filed. The reminder is set. The journal entry will post when the bill is paid. I close the tab and walk to the next meeting.

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.