A 60-person distribution company I sat with ran their entire receivables ledger on a single shared spreadsheet. Twelve tabs, color-coded by one employee who had been there nineteen years. When she took vacation, the company effectively could not tell you who owed them money. That is not a tooling problem. That is an existential one, and it is the most common condition I find in the American mid-market.
The story everyone tells is that software ate the world. The truth is that software ate the very top and the very bottom of the world and left the middle to fend for itself.
The two coasts of the ERP market
At the small end, you have spreadsheets, QuickBooks, and a drawer of point tools. They are cheap, immediate, and they fit in a founder’s head. They work until they don’t. The failure is silent: nobody reconciles, two tabs drift apart, and one day a $340 line gets entered as $34,000 because somebody fat-fingered cents as dollars. I have seen that exact error end a quarter on the wrong foot.
At the large end, you have SAP, Oracle, and the system-integrator economy that surrounds them. These are real systems. They model a multinational’s general ledger across forty legal entities and they do it correctly. But the price of admission is a seven-figure implementation, a two-year timeline, and a standing army of consultants. You do not buy SAP. You enter into a relationship with SAP.
The mid-market is the band in between: roughly 50 to 1,000 employees, $10M to $500M in revenue. Big enough that spreadsheets are now a liability, too small to absorb a multi-million-dollar implementation and the headcount it implies.
| Segment | Typical tool | Time to value | True cost | Failure mode |
|---|---|---|---|---|
| Small (<50) | Sheets, QuickBooks | Days | ~$0 | Silent drift, key-person risk |
| Mid-market | Whatever they can survive | Months-to-never | Hidden, enormous | Stuck, half-migrated |
| Enterprise (1000+) | SAP, Oracle | 1-2 years | $1M-$10M+ | Over-built, under-adopted |
That middle row is where most of the real economy lives, and it is the row nobody designed for.
Why the gap persists
It would be easy to say the mid-market is just underserved and someone should go serve it. People have tried. The gap persists for structural reasons, and you have to respect them before you can close them.
The first reason is that the mid-market is not a market, it is a thousand markets. A 200-person specialty chemicals manufacturer and a 200-person home-services franchise have almost nothing in common operationally. The enterprise vendors solve this with configuration: SAP can be molded into either, given enough consultant-hours. That moldability is precisely what makes it unaffordable below the enterprise line. You are paying for infinite flexibility you will use 8% of.
The second reason is that mid-market buyers cannot absorb risk. An enterprise can run SAP and the old system in parallel for a year and write off a failed module. A 120-person company that botches its ERP cutover during Q4 can miss payroll. The cost of a bad migration is not measured in dollars, it is measured in whether the business survives the quarter. So they don’t switch. They stay on the spreadsheet and pray the person who maintains it doesn’t quit.
The third reason is the one I find most damning: most ERP products were designed for the person buying them, not the person using them. They optimize for the procurement committee’s feature checklist. The result is software with 4,000 screens, of which any given employee touches nine, and the nine they touch are buried four clicks deep behind the 3,991 they don’t.
The mid-market doesn’t need more features. It needs the right twenty workflows to be unmissable, and everything else to get out of the way.
What I learned building it twice
Before I built my own ERP I did two full implementations on a legacy open-source ERP for retail operations. That platform is the closest thing the mid-market has to a real answer, and the experience taught me more about the problem than any amount of theorizing would have.
The lesson that stuck: the schema you choose in week one decides which automations are even possible in year two. On the first build I let inventory and point-of-sale live in loosely coupled tables because it was faster to ship. Eighteen months later the client wanted automatic reorder suggestions based on real sell-through, and the data simply could not answer the question because the two systems had never agreed on what a “unit” was. On the second build I treated the data model as the product and the UI as a thin skin over it. Everything we wanted later became a small query instead of a migration nightmare. I have a whole separate piece on why data model is destiny; the short version is that you are not choosing a database, you are choosing your future.
The second lesson: migration is the real product. Nobody, and I mean nobody, switches ERP because the new one looks nicer. They switch when someone makes the terror of moving their data go away. The pretty UI gets them in the door. The painless import is what closes the deal, and it is brutally hard to make true because every legacy system is a haunted house of edge cases.
What I am building instead
Vontra, the AI-native business operating system I’m building, is my answer to the stuck middle. The thesis is narrow on purpose.
First, opinionated defaults over infinite configuration. I would rather ship the right twenty workflows out of the box than the ability to build any workflow. The mid-market does not have a business analyst to spec the perfect process. They have an owner who needs invoices to go out and cash to come in.
Second, the system is AI-native at the data layer, not bolted on at the chat box. Every meaningful action in the platform is a typed, permissioned tool. That means an AI can run operations the same way a person clicks buttons, which is a fundamentally different architecture than gluing a chatbot onto a legacy schema. I treat that tool surface as the real control plane of the business.
Third, the numbers have to be defensible. An ERP that shows a confident figure it cannot reconcile is worse than no ERP, because it manufactures false certainty. Financial trust gets built one reconciled report at a time, and I would rather show a number with its sourcing exposed than a beautiful dashboard nobody can stand behind.
Fourth, isolation is non-negotiable. The moment you serve many businesses from one platform, the most important code you write is the code that keeps their data apart. There is no acceptable failure rate on tenant isolation. None.
The economics that make it possible now
The reason this is buildable in 2026 and was not in 2010 is that the cost of the two hardest pieces collapsed. Configuration used to require consultants; now a well-designed system plus an AI that understands the tool surface can configure itself against a customer’s described reality. Migration used to require a project; now a model that can read a messy export, infer the mapping, and reconcile the totals can do in an afternoon what used to take a month.
I am skeptical of demos, so let me be precise about what is real. The AI does not replace the accountant. It collapses the setup tax. A 150-person company that would have faced a six-figure, multi-month enterprise-lite implementation can stand up a working system in weeks at a fraction of the cost, because the expensive human labor in ERP was never the software. It was the bespoke fitting.
Why this is the mission
I did not get into ERP because ledgers are exciting. I got into it because the mid-market is where most people work, and they are running the engine of the economy on tooling that would embarrass a software engineer. The enterprise has its army. The small shop has its spreadsheet and its prayer. The middle has been told, implicitly, that real operational software is not for them.
That is the gap. Closing it is unglamorous, schema-deep, migration-heavy, reconciliation-obsessed work. It does not demo as well as a flashy agent video. But it is the difference between a company that can scale past one person’s vacation and one that cannot. Built for missions means built for the company that actually has to make payroll on Friday. That is who I build for.