How a boutique tool stays trustworthy
Small teams are supposed to ship fast and break things. We chose the opposite trade. Here is why, and what it costs us.
A reasonable question we get from anyone evaluating a small product: can a small team really be trusted with the data that runs my firm?
It is a fair question. Commission economics, revenue recognition, client requirements. These are not playground data. If the tool breaks, real money breaks with it.
The default trade for a small product
Move fast. Ship every day. Apologize when something breaks, fix it, move on. This trade is rational for consumer apps and irrational for software that handles a firm’s money.
So we made the opposite trade. Slower than we could move. Less surface area than we want. More test coverage than is normal for a team our size.
What that actually looks like
- 1781 automated tests. Not a vanity number, a contract. The test suite runs on every change, and we do not ship if any of them fail. Most of the tests are about money: commission math, revenue recognition by model, snapshot logic, invoice rollups.
- Zero implicit-any TypeScript errors in the production codebase. Strict typing across the entire system. The kinds of bugs that happen because a field was the wrong shape, that whole class is closed.
- An architectural review on every meaningful change. Not a checklist. A read by a second engineer with the authority to say “no, this is not how we do it.” Slower than a thumbs-up. Catches what a thumbs-up does not.
- AI is bounded to two surfaces, and money math is not one of them. We use Claude in exactly two places. Sage is a help assistant that answers from our own help articles, the User Manual, and the Feature Catalog, and cites the source. The DRD to FRD converter proposes structured functional requirements rows for a solutions engineer to review and approve. The system prompts pass no business data to the model. No deal record, no commission, no margin number, no journal entry.
- Money math is deterministic and balanced by construction. Every commission calculation, every revenue recognition entry, every journal entry posted to QuickBooks runs through rules we can explain. Rev rec journals are checked for debit equals credit before they are persisted; an unbalanced entry cannot exist, even as a draft. No model advises on a number that hits your books.
What it costs
It is slower. Every feature takes longer than it would at a “move fast” team. There are weeks where the roadmap looks like nothing happened.
We think that is the correct cost. The product is the kind of product where a quiet bug in a piece of math is worse than a missing feature. A missing feature is a request. A quiet bug is a lost deal.
What we want it to mean
If you are evaluating PartnerView and the objection in your head is “they are too small for me to trust with this,” the answer is not that we are not small. The answer is that we know exactly what kind of product this is, and we are not running it like a five-person consumer app.
A boutique tool can be a high-quality tool. We are trying very hard to prove the case.