2026-04-12
Built for one person
A friend of mine runs a cleaning business. Two cleaners. Weekday rates and weekend rates — different because the work is different. A rotating group of household clients, each on their own schedule. Fixed costs that don't change month to month. Supplies that scale with every session. And at the end of it all, no clear picture of whether the business is making money after tax.
That bothered me more than it should have.
I'm a CPA. I've built financial models at companies with 150 to 180 employees — multi-entity consolidations, acquisition support, the kind of scale where a wrong assumption costs real money. The instinct to solve a forecasting problem is just there. You see the gap, you want to close it.
So I did.
The spec took about ten minutes. The engine — the part that calculates revenue, gross profit, expense categories, and tax provision — took longer to think through than to build. It's a pure function. No database calls, no UI, no side effects. Inputs go in, a monthly P&L comes out. I wrote twenty tests before I wrote the interface.
That's not how most people build things. But a financial calculation you can't verify from its inputs isn't a calculation — it's a guess. The tests aren't optional quality work. They're the proof.
The hard parts weren't the math.
A Postgres extension that isn't enabled by default, throwing an error I'd never seen. A TypeScript interface that collapses to never when the dependency expects a different internal shape. A build system that evaluates module code during static export and crashes on an environment variable that doesn't exist until runtime. Each one of those took about twenty minutes and a clear enough head to read the actual error message rather than the first result that came up.
None of it is glamorous. It's just the work. You either do it or you don't ship.
I also cared about the security more than strictly necessary.
The app is invite-only. No one can create an account without a direct invitation. Login is a magic link — there's no password to steal. Every row in the database is locked to its owner at the database layer, not the application layer. Even if someone bypassed the app entirely, the data isn't accessible.
The business data of a two-person operation isn't particularly sensitive in the grand scheme. But the principles are the same whether it's a cleaning business or a company with thirty employees. If you're handling someone's financial data, you handle it like it matters. That's not a security decision. It's a decision about what kind of work you want to do.
From the first line of code to a live URL with a real person able to log in: one day.
That's the thing I want people to take away from this. Not that I'm particularly fast. Not that the tool is particularly sophisticated. But that the gap between "I want to build something" and "it's built" is almost entirely made of decisions, not ability.
You decide to write the spec before you write the code. You decide to test the calculation before you wire up the interface. You decide to care about the security details nobody will ever notice. You decide to work through the four error messages instead of stopping at the first.
That's it. That's the whole thing.
Anyone can do this. The only interesting question is whether you decide to.