Walk into any conversation about business software and you will hear two options offered. Buy SaaS, because it is fast and cheap. Or commission a custom build, because you have outgrown what SaaS can do. The advice sounds sensible. It rests on a false choice. The businesses paying the cost of that false choice are the ones sitting in the middle.
A company running 80 to 200 staff, with real operational complexity and a budget that is not enterprise-sized, does not fit either bucket. The industry has not built a serious answer for that company. It built two answers for two different companies, then told this one to pick whichever is less wrong.
The two buckets, and why neither fits
SaaS platforms are built to serve as many customers as possible with one product. That means the workflow is fixed, and the business adapts to the software rather than the other way round. For a simple operation, that trade is fine. For a company with a genuine operational pattern, whether that is a logistics business coordinating fleet and freight, a manufacturer managing production against variable orders, or a construction firm tracking projects across sites, the fixed workflow becomes the daily obstacle. Staff build spreadsheets around the software’s gaps. The tool that was supposed to save time becomes the thing everyone works around.
Enterprise custom development sits at the other end. It solves the fit problem properly, because the system is built around the business rather than the business bending to fit it. But the model was built for a different customer. Six-figure budgets, extended discovery phases, and delivery timelines measured in quarters make sense when the client is a 2,000-person organisation with a dedicated IT department and a board sign-off process to match. A 150-person operations team does not have that budget or that patience, and does not need a system built at that scale to solve a problem that size.
Neither bucket was ever built with this company in mind. It falls through the middle by design, not by accident.
Why the gap exists
The gap is not an oversight. It is what happens when supply follows the easiest economics.
Development shops that do custom work have historically built their pricing and process around enterprise clients, because that is where the margins and the retainers are. Smaller custom projects get quoted at enterprise rates, or squeezed into a process built for a much bigger client, and the fit and the economics both suffer.
SaaS companies, meanwhile, are optimising for scale, not for fit. A platform serving ten thousand customers cannot rebuild its workflow for each one. Configuration options go so far and stop, because going further breaks the economics that make the SaaS model work in the first place.
Both sides are behaving rationally within their own model. The result is a mid-sized business with process-heavy, genuinely specific operations, told to either compress itself into generic software or pay enterprise prices for an enterprise process it does not need.
What serving this market actually requires
Closing the gap is not a pricing exercise. It requires a different starting point.
Understanding operations before writing a line of code. A system built for a mid-sized operational business has to start with how the business actually runs, not with a template workflow adjusted at the edges. That means understanding the process well enough to build for it, not around it.
Delivering in weeks, not months. A business this size cannot fund or wait through a multi-quarter build. The answer is not to cut corners on a full build. It is to scope tightly and deliver a working module in three to four weeks, prove the fit, then build out from there. Scope discipline, not shortcuts, is what makes that timeline honest.
Pricing that matches the client, not the category. Mid-market engagement values have to reflect a mid-market budget and a tightly scoped delivery, not an enterprise cost structure applied to a smaller company because that is the only pricing model on the shelf.
None of this is exotic. It is closer to what custom development looked like before the industry split into two extremes and stopped serving what sat between them.
Why this matters now
The businesses that will define this space are the ones willing to build for it deliberately, rather than treating it as a smaller version of enterprise work or a more demanding version of SaaS. That takes a different process, not just a different price list, because the fit problem this market has is structural, not cosmetic.
Mid-sized operational businesses have been told for years to make do. Adapt to the platform, or wait and pay for the scale you are not yet at. Neither is a real answer to a real operational problem, and the businesses still working around that gap know it better than anyone selling into it.
If your business sits in this gap, we built Tyne specifically for it.
Talk to us about what a fitted system would look like.