Market · 7 min read · February 2026
Software by company size: what changes between small, mid-size and large companies
The software problem isn't the same at a 15-person company, a 120-person company or a 2,000-person company. What changes is the risk of getting it wrong, the team that will maintain it, and how you hire for it.
Small: generic SaaS works, until it doesn't
A small company starts with a spreadsheet, then an off-the-shelf SaaS, then several SaaS tools that don't talk to each other. It works as long as the process fits what the tool assumes. The moment to think about building something of your own is when the operation starts getting shaped by the tool instead of the other way around — when three people spend the week copying data from one system to another.
The common mistake here is building too early: an "internal ERP" before the process is stable. The cheaper path is usually to automate the edges — an integration, a routine bot, a dashboard — and postpone the in-house system until the rules stop changing every week.
Mid-size: the problem becomes integration and scale
Between 50 and 300 people, the challenge changes. There's already an ERP, a CRM, maybe an app. The friction is at the joints: data that doesn't match up, a process that depends on exporting a CSV, a report someone builds by hand every Monday. And volume starts to hurt — the queue that used to be instant now stalls, the database that used to hold up doesn't anymore.
This is the bracket where custom software pays off most: not replacing what exists, but connecting it, covering the gap between systems, and giving the operation an interface that shows what actually needs attention.
Large: the bottleneck is capacity, not ideas
A large company has a technology team and a backlog. There's no shortage of things to do — what's missing is senior people free to take on a specific front without stopping everything else. Here, hiring is rarely "a project"; it's engineering support on one front, integrated with the internal team, with the repository and the decisions staying in-house.
The size of the company doesn't tell you what to build. It tells you how much risk there is in getting it wrong, and who will maintain it afterward.
What doesn't change at any size
- Technical discovery comes before code.
- The repository, the documentation and the access stay with the company.
- Whoever talks to you during diagnosis is who writes the code.
If you're not sure which bracket you're in, that's also a conversation we have. Talk to Tensoor.