What custom software for an SMB really is (and is not)

Custom software is a system built around the way you work: your statuses, your pricing rules, your approval flows, your forms, your vocabulary. It is not a generic product where you switch features off until it vaguely resembles your operation. It is the exact opposite.

For a small or medium business this matters more than for a corporation. SMBs compete by doing something different: a special configuration, a shorter lead time, closer service. That edge almost never fits inside an off-the-shelf product, and when the company adapts to the software instead of the reverse, the first thing lost is precisely what made it worth choosing.

It is also not a two-year program or an enterprise budget. A good custom project for an SMB starts small, solves one specific bottleneck, and pays for itself with the hours it frees up.

The starting point is almost always the same: the spreadsheet. And spreadsheets are not free. The review of field audits on operational spreadsheets published by Raymond Panko (University of Hawaii) found errors in more than 86% of those audited. When that spreadsheet drives pricing, inventory or collections, every error has a cost.

When it makes sense

It does not always make sense, and saying so is part of the job. These are the signals that the moment has arrived:

• There are three or four business-critical spreadsheets only one person knows how to maintain.
• The same data gets entered two or three times into systems that do not talk to each other.
• The product you bought covers 70% and the remaining 30% is handled by hand, over email or chat.
• Asking for a report means waiting two days for someone to build it.
• Growth is limited by administrative capacity, not by lack of sales.
• The current system is old, whoever built it is long gone, and nobody dares to touch it.

When it does not

If the process is standard (accounting, payroll, plain invoicing) an existing product, properly integrated, almost always wins. The healthy answer is usually hybrid: a product for what does not differentiate you, custom development for what does.

Not sure whether you actually need custom software? In a 30-minute call we review your operation and tell you whether to build, integrate what you already have, or buy an existing product. If the answer is buy, we say so. Get in touch and let us look at it together.

Custom software, SaaS or ERP: what fits which need

The honest comparison is not custom versus ERP: it is which need you are solving. SAP, Odoo or any local accounting suite handle very well what is identical across every company. The problem shows up in whatever is specific to yours.

In practice almost no SMB sits at either extreme. The most common and healthiest answer is a mix: a standard product for accounting and tax, custom development for the operation that differentiates you, and both connected through APIs. We go deeper in custom software vs SaaS.

How we approach it

We use modular architecture from day one, even on small projects. Each module (sales, inventory, production, collections) is deployed and tested separately and talks to the rest through APIs. That lets you go live with one part of the system while everything else keeps running as it does today, without interrupting operations or asking anyone to learn everything at once. If you also sell online, that same modular approach is what drives our e-commerce and marketplace integrations.

Start with the bottleneck, not the org chart

The first module is not chosen by hierarchy but by pain: the process that burns the most hours or produces the most errors. If the first release does not give real time back to a specific person within weeks, the project started off wrong and it is worth revisiting before going further.

Short releases and scope locked per phase

The study McKinsey ran with the BT Centre for Major Programme Management at the University of Oxford, covering more than 5,400 IT projects, found that large ones end up 45% over budget and deliver 56% less value than predicted. The practical conclusion for an SMB is not to panic: it is not to run large projects.

That is why every two weeks there is something working that you can see, click and use, and scope is locked per phase instead of in one twelve-month contract. You can pause, reprioritize or add a new module without renegotiating the whole project.

Real cases

No names, because these are client operations.

How much does custom software cost?

The honest answer is that it depends, but it depends on concrete, measurable things:

• The scope of the first module. How many processes go into phase one and how tightly coupled they are.
• The integrations. Every external system adds work: e-invoicing, ERP or accounting, banking, marketplaces, carriers.
• Users and profiles. Not because of licences, but because of permission and screen complexity.
• Data migration. How many years of history need to come across and in what shape they are.
• Infrastructure. Cloud or on-premise, and what level of availability the operation needs.

We do not quote the whole system. We quote the first phase with locked scope and price, after a one or two week diagnosis, and that first module is usually in production within 4 to 6 weeks. Everything after that is quoted phase by phase, using what the previous one taught us: nobody has to sign today for what will only be understood six months from now.

The number that matters is not the price but how many monthly hours it gives back. When four people spend half a day entering data the system can capture on its own, or when building a quote takes twenty minutes and becomes a matter of seconds, the math closes in months rather than years. Tell us which process you want to solve and we will put a number on your case after the diagnosis.

Examples by industry

Logistics and distribution

Route sheets, digital delivery notes, shipment tracking and freight reconciliation. The order is entered once and travels all the way to invoicing with no retyping. We have a dedicated pillar on software for logistics and transportation with the full cycle.

Manufacturing and production

Production orders, raw material control, batch traceability and real cost per product. The typical case is the plant that knows how much it sold but not how much it cost to produce until month-end close.

Wholesale and retail

Price lists per channel, promotions, stock per location and customer accounts. This is where integration with the online store and marketplaces pays off fastest.

Healthcare

Appointments, medical records, insurers and service billing, with the data protection requirements the sector demands. We cover it in healthcare software.

Construction and field services

Progress certifications, daily reports, subcontractor control and cost per site. Data is captured from a phone on location, with no signal, and syncs on the way back.

Agribusiness

Seasons, plots, applications, storage and settlements. A sector where data is born in the field and the system has to go and get it there, not wait for it at the office.

Common (and expensive) mistakes

• Trying to fit everything into version 1. Unlimited scope is the number one reason projects never ship. Define a minimum that is useful on its own, and release it.
• Digitizing the mess. Automating a badly designed process only makes the error spread faster. Clean up the workflow before writing code.
• Underestimating data migration. Years of history stored in spreadsheets are the most valuable asset in the project and almost always the worst estimated task.
• Leaving out the people who will use it. A system designed only by management gets bypassed with parallel spreadsheets within three months.
• Having no exit plan. Code, database, documentation and access must be in your name from day one, not at the end.

Questions we get before kickoff

What technologies do you use?

Backend in .NET, Java or Node.js; frontend in React or Angular; databases in SQL Server, PostgreSQL, MySQL or Oracle; mobile in React Native. The choice is driven by your context, not our preference: if your internal team already knows a stack, that stack has the advantage.

Can it integrate with SAP or another corporate ERP?

Yes. We integrate through APIs, web services or scheduled file exchange depending on what each version exposes. What we settle up front is who owns each piece of data, so there are never two conflicting versions of the truth.

What you own when it is done

The system in production, the source code and infrastructure under your accounts, functional and technical documentation, and a team available to keep evolving it. If you want to build internal capacity, we do it through our software factory and team augmentation model. If what you have today is an old system that cannot be switched off overnight, the right path is progressive modernization, not a full rewrite. And once your data finally lives in one governed place, that is when it makes sense to talk about AI on your own data.

Across 25 years and more than 500 projects we learned something simple: SMBs do not need more software, they need less manual work. Everything else follows from that.