From Solo to 3-Person Firm: The Beancount Workflows That Break (And How to Fix Them)

General
1

I’m at a crossroads and need advice from anyone who’s successfully grown their practice.

The Solo Paradise That Can’t Scale

For the past 5 years, I’ve run a solo bookkeeping practice using Beancount. My workflows are perfect—for me. I have:

  • Custom Python importers that parse bank CSVs exactly how I like them
  • Git commit messages like “fix” and “cleanup” (I know what they mean!)
  • Implicit categorization rules that live entirely in my head
  • Shortcuts and folder structures that make sense to me
  • A mental model of every client’s books

I serve 15 small business clients, and I’m turning away 2-3 new inquiries every month. The demand is there. I need to hire.

The Nightmare Begins

Last month, I brought on my first hire—a bright junior bookkeeper who genuinely wants to learn Beancount. Within two days, it became painfully obvious: my “obvious” workflows are incomprehensible to anyone else.

She asked me to explain how the importer works. I opened the Python file and realized there are zero comments, variable names like df2 and processed, and logic I wrote at midnight that even I barely understand now.

She asked which clients require monthly closes vs quarterly. I realized I’d never written it down—I just “know.”

She asked about our chart of accounts standards. Turns out every client has a slightly different structure because I organically evolved them over years.

The Documentation Debt

I’ve been solo for so long that I have massive documentation debt:

  • No onboarding guide - “Watch me do it” isn’t scalable
  • No style guide - Should accounts be Expenses:Office:Supplies or Expenses:Supplies:Office? Both exist in my ledgers
  • No code review process - I’ve been committing directly to main for 5 years
  • No standardized templates - Every new client setup is custom
  • No training materials - Plain text accounting is foreign to QuickBooks-trained bookkeepers

According to research on scaling accounting firms, 55.5% of firms say workflow inefficiencies are their biggest challenge, and some lose clients because of it.

What Breaks First When You Scale Beancount?

I’m documenting everything now, but I’m curious—for those who’ve scaled Beancount workflows to a team:

  1. What broke first? Was it Git workflows? Code quality? Inconsistent categorization?
  2. How do you maintain consistency? Linting rules? Peer review? Standardized account hierarchies?
  3. Training materials - Did you build internal wikis? Record video walkthroughs? Pair programming?
  4. Git workflows - Do you use branches and PRs? Code review every transaction? How do you prevent merge conflicts?
  5. Documentation standards - What do you document? How detailed? Who maintains it?

My Current Plan

Here’s what I’m thinking (tell me if I’m on the right track):

  1. Create a practice-wide chart of accounts template - Standardize account naming for new clients
  2. Write an onboarding playbook - Document Beancount basics, our workflows, where everything lives
  3. Implement code review - No direct commits to main, require PR review even for small changes
  4. Refactor importers with tests - Add comments, meaningful variable names, unit tests
  5. Build a style guide - Document formatting rules, commit message format, file organization

But I’m worried this will take months while I’m still turning away clients.

The Core Question

How do you balance the urgency of growth with the necessity of building scalable systems?

Do I hire person #2 before documenting everything? Do I slow down growth until systems are perfect? Is there a middle path?

I’d love to hear your experiences—especially the painful lessons you learned the hard way.

For context: I’m in Austin, TX, serving mostly retail and hospitality clients with $200K-2M annual revenue. Most need monthly reconciliation and quarterly tax prep. I’m considering hiring 2 people this year to handle 30+ clients.