Pragmatic instead of over-engineered
Do you want a solution that fits your company's size — not a corporation's? We look at your processes honestly with you and will also tell you when a standard tool is enough.
Software for the Mid-Market: Pragmatic Instead of Over-Engineered
Software for the mid-market is a discipline of its own. Not because mid-market companies are dumber or slower — quite the opposite. But because the conditions are different from those in a corporation and in a startup: grown processes, scarce IT resources, knowledge that sits in a few heads, and a very healthy respect for risk.
This article sums up what we have learned in projects with mid-market companies in the Munich area — pragmatic instead of over-engineered. And honest even where it is uncomfortable.
1. Why the mid-market is not a small corporation
The most common mistake: consultants and providers treat the mid-market like a corporation with fewer employees. That is wrong and expensive.
A corporation has specialists for everything — its own IT department, project management, architecture, operations. A mid-market company often has a handful of people who do everything at once, plus the day-to-day business. Software designed for corporate structures suffocates in a mid-market organisation under its own complexity.
A startup, in turn, can reinvent processes because it does not yet have any. A mid-market company has processes that have worked for twenty years and that revenue depends on. Here "move fast and break things" does not apply — here "change precisely and break nothing" applies.
Good mid-market software respects both: the scarce resources and the grown reality. It is not the technically most impressive solution, but the one that survives in real operation with real people.
2. When a mid-market company should NOT invest in software
The honest warning first. There are situations in which a software project is the wrong next step.
When the process itself is broken. Software automates a process — even a bad one. If the workflow is chaotic, you get chaotic software, just faster. First the process, then the software. Always in that order.
When no one internally has time to support the project functionally. Software does not emerge without the customer. If the two people who understand the process cannot spare an hour a week, the project fails — no matter how good the provider is.
When a good standard tool solves 80% and the missing 20% does not hurt. Not every pain justifies an investment. Sometimes the honest answer is: buy the standard tool, live with it, save money.
A good partner will tell you this. Anyone who ends every conversation with a proposal is optimising their revenue, not your company.
3. The principle: software must survive operation, not the project
This is the most important rule for mid-market software. A corporation can afford software that only a well-rehearsed team understands. A mid-market company cannot.
Mid-market software must pass three stress tests:
- The bus test. If the person who knows the system best is gone tomorrow — does it keep running? Is it documented, understandable, handover-able?
- The maintenance test. Can another developer make a change in two years without fear of breaking everything?
- The everyday test. Does it also work when reality does not match the ideal case — bad internet, faulty input, the edge case no one anticipated?
Software that does not pass these three tests is not an asset but a liability with interest. This logic applies to every piece of mid-market software and is closely related to what we write about follow-up costs in the guide to custom software development.
4. Pragmatic does not mean cheap — it means appropriate
"Pragmatic" is often confused with "cheaply cobbled together". The opposite is meant. Pragmatic means: exactly the complexity the problem justifies — no more, no less.
A mid-market company rarely needs the architecture with which a streaming service serves millions of users. It needs a solution that runs robustly for its 40 or 400 users, stays maintainable and is affordable. Anyone who sells it corporate architecture sells it maintenance cost it will never get rid of again.
The other extreme is just as wrong: the quick-and-dirty solution that works in the demo and collapses under load in the third month. Both extremes are unprofessional. The craft lies in the appropriate middle — and hitting it is a matter of experience, not a standard recipe.
Incidentally, this middle often does not lie in pure custom development, but in a platform solution with targeted extensions. How far you can get with that, we show in the guide to the Microsoft Power Platform for the mid-market.
5. The special case of old systems and interfaces
Hardly any mid-market company starts on a greenfield. There is always an ERP, a grown database, a system no one wants to touch any more. Mid-market software almost always means: building into an existing landscape, not next to it.
Two topics are so important here that they have earned their own articles: dealing with old systems in Legacy modernization and the question of how systems are connected cleanly instead of glued, in API development in Munich. Both are part of the mid-market reality — anyone who ignores them is planning past the customer.
More about our concrete approach can be found on the page about custom software and app development.
Conclusion
Mid-market software is not a shrunken corporation and not a grown-up startup. It is a discipline of its own, in which appropriateness, maintainability and respect for grown processes count more than technical brilliance.
The key points in brief
- Mid-market ≠ small corporation: scarce resources, grown processes, knowledge in few heads — corporate architecture suffocates here.
- Say NO when the process itself is broken, no one internally has time or a standard tool solves 80% pain-free.
- Software must survive operation, not the project: pass the bus, maintenance and everyday tests.
- Pragmatic means appropriate, not cheap — exactly the complexity the problem justifies.
- Platform plus targeted extension is often the economically right middle in the mid-market.
Sources
This article is deliberately a field report: it is based primarily on our own project work with mid-market companies in the Munich area and contains no external statistical claims. Where we refer to established architecture knowledge (maintainability, incremental replacement of old systems), the primary source is linked; the remaining references lead into our in-depth guides.
- Our own project experience from software projects for mid-market companies in the Munich area
- Martin Fowler: Strangler Fig Application — incremental rather than radical replacement in grown landscapes
- Guide: custom software development — follow-up costs and ownership of the process
- Legacy modernization — dealing with old systems
- API development in Munich — connecting systems cleanly
- Microsoft Power Platform for the mid-market — the appropriate middle
