What this is for

Every back-office has a handful of seams that hurt — a CRM that doesn’t talk to QuickBooks, a processor export that has to be hand-massaged before it’ll import, a Zapier flow that breaks every other Friday because someone renamed a column upstream. The point of this engagement is to pick the two or three seams that cost the most operator hours per month and replace them with code the firm writes, owns, and maintains alongside the books.

The reason this is its own line of work and not bundled into bookkeeping is that the diagnostic is different. Bookkeeping asks: are the books right? Automation asks: where is the back-office spending time it shouldn’t have to spend? Those are related questions but they get answered with different tools and produce different deliverables.

The “written, not configured” line

There’s a real distinction between integrations stitched together in a no-code tool and integrations written as code. Zapier and Make are excellent for the first six months of a workflow’s life. They’re a liability by month eighteen. The reasons are consistent across every engagement we’ve taken over:

• Visibility falls off a cliff as soon as a flow involves more than three steps. Debugging a Zap that’s been silently dropping records for two weeks usually starts with logging into Zapier and discovering there are no logs.
• Every breaking upstream change — a renamed Stripe field, a Salesforce custom object migrated, a QuickBooks API version sunset — silently breaks the flow without firing an alarm anyone reads.
• Vendor lock-in compounds. A Zap doing 200 runs a day at the Starter tier is fine; at scale the same flow costs more than a junior developer.
• Nobody can read it but the person who built it, and that person left.

Code in a real repository, with tests, deployed to Cloudflare Workers or a small Postgres-backed service, fixes all four. It’s not exotic infrastructure. It’s the same shape as any other backend service — TypeScript, Python where the libraries are stronger, version control, CI, observability, alerts that go to a real channel. The CPA who owns the books is on the repo so the integration doesn’t become a black box that only the engineer can touch.

Typical scope

Most engagements are 4–10 weeks. A short engagement looks like: a custom connector between a bespoke CRM and QuickBooks that batch-syncs invoices nightly with idempotency, error queues, and a Slack channel for failures. A longer engagement looks like: a small internal app — an intake form for new vendors, a routing flow into Bill.com with category and entity defaults, a dashboard for the AP queue, and the connector that wires the whole thing back into the GL.

The shape of the build matters more than the line count. We don’t ship a 4,000-line service when an 80-line script and a cron would do. Most of the small internal apps we’ve shipped are under 1,500 lines of code across the entire stack. The maintenance burden after launch is the metric we optimize for — every line shipped is a line we have to keep alive.

How we scope a build

The first week is diagnosis. We sit with the team for a few hours, walk the existing workflow end-to-end, and identify the steps that fail most often, the steps that take the most clock time, and the steps that depend on a person remembering to do them. The output of that week is a written recommendation — what to build, what to leave alone, and what to delete entirely. Sometimes the right answer is “you don’t need a build, you need to turn off three of these tools and use the one you already pay for.”

If a build makes sense, the fee is scoped to what’s being wired together. After launch, ongoing maintenance is either standalone or rolled into the broader engagement depending on what’s already in place. We’ve never had a build go into production without a maintenance plan — code that nobody owns rots, and rotted code in the finance stack causes incidents.

What this isn’t

This isn’t full-stack product engineering. We don’t build customer-facing apps. We don’t take on long-running platform builds where there’s no finance line of sight — the engagements that work here are the ones where the deliverable improves either the close, the reporting cycle, the cash flow, or the operator’s view of the business. If the work is “build us a customer portal,” the right shop is a product agency, not the firm.

It’s also not a replacement for an ERP. NetSuite and Sage Intacct exist for a reason, and below a certain operational complexity they’re overkill while above it they’re the right answer. We’ll tell you which side of that line you’re on during the diagnostic, and if the answer is “you need NetSuite next year,” we’ll refer you to an implementation partner and stay out of the way.

How this pairs with §5

§5 (Financial Ops & Process) and §2 are usually a pair. Process and tooling can’t really separate — a close calendar that depends on someone manually exporting from Shopify every Monday is a process problem and a tooling problem, and fixing only one of them is worse than fixing neither. When both lines are running together, the diagnostic week becomes one week instead of two, and the implementation is faster because the team isn’t moving between two engagements.

Pairing with §3 (Bookkeeping) is the most common pattern overall — the CPA running the books has the clearest view of which seams hurt, which is why the engineering work usually starts from a list the close team wrote.