I was my firm's biggest bottleneck. Now it runs on 40 apps I built myself

Two years ago, I was the bottleneck in my own firm. Every pricing decision, every capacity question, every "hey Mike, quick question" ran through me. So I did what any reasonable person does. I started building apps at night instead of sleeping.

I'm not a developer. I've been an accountant for seventeen years, I never took a computer science class, and most of the words on a developer's website mean nothing to me. But I got curious, and that turned out to be enough. Today, my firm runs on more than forty apps I built myself, with zero developers. I shared how at the AI in Practice Summit, and you can watch the full session here.

Here's the thing I most want you to take away. This is the worst AI will ever be. The slowest, the most expensive and the hardest it is ever going to be. And even now, the bar to build is far lower than you think.

What vibe coding actually is

Andrej Karpathy described vibe coding as a new kind of coding where you give in to the vibes and forget the code exists. In plain terms, you describe what you want in everyday English, it builds the thing, and then you test it, tweak it and share it. That's the whole loop.

It can be as complex or as simple as you make it. You don't need to write a novel or plan the perfect app for months. You can build one small, niche tool that solves a single annoying problem, then snowball from there.

And this goes well beyond toy projects. One of our first serious builds was a tax-planning optimiser that works out the most tax-efficient way to pay a company's owners. Work that used to take our senior accountants and CFOs eight to ten hours per client now takes about two. Better still, we moved an hour and a half of it onto our admin team, which freed up senior time for reviewing the work and actually talking to the client.

The workflow is deliberately simple: idea, prompt, paste

Here's how low the starting bar is. I opened Claude with no context at all and told it, "I'm an accountant, and I'd like to build a simple app for Lovable. Give me a few ideas." It came back with a handful, and I picked a Canadian tax deadline tracker.

One pro tip is worth its weight. Claude or ChatGPT probably already knows a fair bit about you, so try asking, "Based on everything you know about me, what could I build that would save me time?" You'll usually get a few genuinely good ideas back.

Then I asked it for a build prompt and told it to "make it comprehensive", which flushes out the detail. I copied that prompt, pasted it straight into Lovable, and asked it to build. About ten minutes later, I had a working tracker with a calendar view, a list view, category filters and reminder settings. I'd done nothing but paste. When I decided I didn't like the colours, I typed one more line, "my brand colours are red and black, make the app follow them", and it overhauled the whole look. It really is that simple.

Start small, and build the ugly version first

The best vibe-coded tools are usually not big platforms. They're small, single-purpose things that solve an irritating little problem. We built an Ontario payroll gross-up tool that does exactly one job. A client says they paid an employee $3,242 and forgot to work out the deductions, and it tells us precisely what they are. Anyone reading this could ship that in an afternoon.

So build the ugly version first. Get it working, and working accurately, before you touch the design. The visuals will pull you in because everyone wants a shiny app, but functionality is the point, and the look can be fixed in a prompt or two. Screenshots help here more than words. Paste one in, point at what's wrong, and it fixes it.

Then test it hard, and be honest about where it's going. Internal tools carry far less risk. The moment something is client-facing, you need to have tested it every way you can, because a tool that hands a client the wrong number is on you. Give it to a teammate and let them try to break it. That feedback is what makes it safe to roll out.

Buy the complex stuff, build the gaps

I'm not building everything, and neither should you. My rule is simple. Buy when something is complex, regulated or widely available, and build only the custom gaps.

I have no interest in rebuilding QuickBooks, a payroll engine or a practice management platform. We've run Karbon for over nine years, and recreating that would be madness. What I will build is the one per cent that an off-the-shelf tool misses, or the thing that simply doesn't exist yet. Instead of complaining about the gaps in your stack, or waiting for a vendor to fill them, you can often fill them yourself on a weekend.

The real cost: time, maintenance and liability

I'll say this plainly, because it matters. I've spent more money and time on this than I saved, and I'd do it again.

That was short-term pain for long-term gain, and I went in knowing it. But you have to be honest about the real cost. There are tokens and usage limits, and they add up. There's the time. If the hours you'd spend building could have been billable client work, the maths may not work. It worked for me because I did it at night and on my phone, not instead of client work.

Then there's maintenance. If I replace Calendly with my own tool and it breaks on a busy morning, clients miss meetings, and I'm dropping everything to fix it. And there's liability. When it's just you, a security breach or a wrong number has no third party to point at. None of that means don't build. It means weigh it before you do.

From a firm that uses technology to one that builds it

Once you build that first tool that solves a real problem, your brain rewires. You start seeing annoyances as projects. Someone mentions a frustration in a meeting, and I'm already adding it to my build list.

So if you want to start, spot the annoyance. If nothing comes to mind, ask Claude, ChatGPT or Gemini what you should build based on what it knows about you. Describe it the way you'd brief a new hire, in plain English. Build the ugly version. Then hand it to someone else to break.

One question changed everything for us. It went from "Can we buy a tool for this?" to "Can we build one?" We're no longer a firm that just uses technology. We're a firm that builds exactly what it needs, when it needs it. And the other side of that shift is a genuinely exciting place to be. Watch the full session here.