Rebuilding a Recovery Center's Money Operations in Two Days: A Build Teardown

What was wrong with the recovery center's books?

The center is a multi-program behavioral-health operation, and it is insurance-paid. Claims go out through its insurance-billing platform, payers deposit into one business checking account, and that account is the real record of the business. Nobody could read it.

Two specific failures:

1. The QuickBooks showed $183K. The actual bank balance at the time was about $15K. The owner was making decisions off a number that was wrong by more than 10x.
2. The prior developer promised a QuickBooks rebuild, charged monthly, gave no access, and disappeared. So the owner had already paid for this exact outcome once and received nothing.

What did Zoro build for the recovery center?

Zoro built a phone-first dashboard for an owner who is not an accountant. No login friction, no accounting vocabulary, no money movement. It reads the bank account and answers four questions: what is the balance, what came in, what went out, and what is due next.

The pieces that mattered:

• A direct bank feed. A read-only connection to the business checking account through Plaid, with a forced full refresh every morning, so the balance on screen is the balance at the bank, not a cached value.
• A real backfill before the live feed existed. The bank data provider's approval process for a live connection takes time. Instead of waiting, we parsed the account's historical bank statements so the owner opened a true profit and loss covering months of history on day one. The previous developer spent two months and never showed a single number. We showed the full history before our live feed was even approved.
• Deterministic categorization. Around 14 categories built from the real payee strings in the account: payroll, rent, software, utilities, insurance premium financing, supplies. Internal transfers between the owner's entities are excluded from profit and loss, so moving money between accounts never counts as revenue or spend.
• Income by insurance payer. Deposits grouped by which payer sent them, separated from referral income and cash deposits, so the owner can see who actually funds the business.
• Recurring bill detection. Bills are detected from the transaction history itself, not typed in by hand: rent, software subscriptions, utilities, insurance financing, each with a typical amount and a projected next due date.
• The fund-by alert. The system projects the balance forward against upcoming bills, finds the first one that will not clear, and leads with the exact instruction: add this amount by this date.

One hard boundary, stated to the client and kept: the system never moves money. Read access only. Alerts tell a human what to do, and a human does it.

What approval paperwork did the live bank feed require?

The unglamorous part that unblocked everything: the bank data provider requires production approval before it will serve live data for a real business account. That meant a security questionnaire backed by actual policy documents covering information security, access control, data retention, authentication, and privacy. Zoro wrote those documents, branded them for the center, submitted them, and had production approval the same day the deal closed. This is the paperwork the previous developer never got through in two months. Most stalled software projects for small operators die here, in the forms, not in the code.

What did the dashboard catch in the first refresh?

The first forced morning refresh caught a real problem. The cached feed had been reporting a balance so stale it made the account look nearly empty. The forced pull returned the true balance, plus several transactions the cached feed had missed, including a large deposit. That same refresh flipped an active "this bill will not clear" warning to covered.

A stale balance is not a cosmetic bug. Every decision the owner makes that day is made against the wrong number.

Why did the build ship in two days instead of quarters?

Recovery centers sit under HIPAA and 42 CFR Part 2, some of the strictest data regulations in American business. Zoro deliberately scoped this system to the operating bank account only, so it never touches anything those regulations protect. That single scoping decision is why the build took days instead of becoming a compliance project that takes quarters. The client asked for more, a larger platform for the program itself, and the answer was: separate scope, priced separately, built to satisfy the regulations rather than route around them.

What is the operator lesson from this teardown?

The center did not need accounting software. It needed its own bank account translated into plain English every morning, and one alert that fires before a bill bounces. Most businesses in the $1M to $10M range are in the same position: the truth is already sitting in the bank account, and nobody has wired it to the owner's phone.

The previous developer sold a rebuild of a tool. Zoro sold the answer to four questions. That is the whole difference.

If your company runs on a bank login and a spreadsheet, the truth about your money already exists. The whole build here was wiring that truth to the owner's phone before the next bill tried to clear.