Why we shipped a serious ERP without a year-long rollout

The standard ERP playbook for a small company has been the same for fifteen years:

Sign a six-figure license
Hire a partner network implementer
Spend nine months in a discovery phase
Build a project plan with eight workstreams
Go live, sometime, eventually
Spend the next two years stabilising

Most small companies look at this and choose to stay on spreadsheets and QuickBooks. We thought that was a tooling failure, not a customer failure. Here's what we changed.

The implementation tax is the real product

When buyers compare ERP vendors they look at the SKU price. The SKU price is rarely the bottleneck. The bottleneck is the implementation tax: configuration, data migration, training, change management, and the long tail of "we just need this one custom report" tickets.

For a 30-person services company, the implementation tax on a traditional mid-market ERP is comfortably 5–10× the first-year license. A $30k license becomes a $200k project. That math is what kills the deal — and it's why most small companies never upgrade.

Three architectural choices we made specifically to attack this tax:

Choice 1: One data model, not federated services

Most ERPs evolved by acquisition. Selling came from one acquired product, manufacturing came from another, payroll came from a third. Each was a separate database; "integration" was a euphemism for nightly sync jobs.

When you implement a federated ERP, half the project is mapping the same entity across modules. Customer 1042 in Sales has to be Customer C-1042 in Manufacturing has to be Account 12-1042 in Accounting. You spend weeks building cross-references because the system literally does not know they're the same entity.

We picked a different starting point: one Postgres database, one Prisma schema, one set of tables. Customer.id is Customer.id everywhere. Every module reads it directly. There's nothing to map because there's nothing to integrate.

The cost of this choice: we cannot acquire and bolt on a 50-person engineering team's worth of side product. Everything we ship has to be written into the schema. That makes us slower at perimeter features. It makes us much faster at the core.

Choice 2: Defaults that match real businesses, not abstract ones

A traditional ERP comes empty. You configure your chart of accounts. You define your tax codes. You set up your fiscal year. You build your warehouses. You name your naming series. You wire up your default GL accounts on the company entity.

Each of these is a half-day of meetings between a partner and an accountant who would rather be doing month-end.

We went the other way: opinionated defaults that an accountant in our target geography (right now, Canada / BC) recognises immediately:

Chart of accounts pre-seeded with the standard CA SMB layout
5% GST + 7% PST tax templates (BC default) ready to use
Naming series pre-configured (SI-{.YYYY.}-{#####})
Company entity ships with all 11 default GL account FKs pre-mapped
Fiscal year auto-rolls

If you're in Canada / BC and you're a services or trading SMB, you sign up and you're posting invoices the same hour. If you're somewhere else, you reconfigure — but at least you reconfigure from a working baseline, not from blank.

The cost: we're geographically focused. We aren't trying to be a universal multi-region platform on day one. Our DPA, our data residency, our tax templates, our COA all reflect that. We'd rather be excellent for one geography than mediocre for fifteen.

Choice 3: Refusing to ship features we can't audit

Every "feature shipped" announcement on this product corresponds to a transaction the database can prove. Manufacturing shipped means BOM + Work Order with atomic SLE posting + atomic reversal on cancel — both wrapped in db.$transaction. AI invoice scan shipped means the original PDF stays attached to the resulting voucher forever, and the extraction confidence score is recorded on the row.

The features we could have shipped faster — production scheduling MES, multi-language UI without proper i18n, AI agents that "just summarise things" — would not pass that bar. So we cut them. The result is fewer modules, but every module ships with:

Multi-tenant guard on every query
Approval workflow available where it matters
Audit log on every mutation
Period-close protection at the schema level
Atomic transactions across all related tables

For a finance team this matters more than feature count. A controller doesn't want a stock photo of "AI insights" on their close cockpit. They want to know that the trial balance is provably balanced and the audit log is provably append-only.

The trade-off we accepted

We are not the right tool for everyone:

You need MES production scheduling. We don't ship it. Not yet, maybe not at all.
You're a 5,000-person company. Our advisory locking and our single-region architecture would constrain you. Pick something built for that scale.
You're outside our supported geographies. You can use it; it just won't feel as polished. We'd rather know that up front.
You want HIPAA. Read our DPA — we explicitly don't sign BAAs.

For everyone else — small to mid-sized companies that want a serious back-office without serving a year-long implementation sentence — we think this trade-off is the right one. The proof is the implementation timeline: typical onboarding to live data in well under two weeks, not nine months.

The way we put it on the /product page: nine modules, one ledger, in depth. The way to test it is to start a trial and see how far you get in an afternoon.