Who we build for — SMEs outgrowing packaged software
The package still works. Your company just stopped fitting inside it
Nobody outgrows packaged software in one moment. It happens through a spreadsheet added here, a workaround agreed there, a seat bought so somebody can read a report, and a process step that exists only because one person remembers to do it. One day the tool is a system of record for data that is already maintained somewhere else.
KodDelta moves small and medium companies off packaged software one process at a time. Accounting stays where it is; the operational process with the heaviest manual workaround moves first, runs in parallel until the numbers agree, and only then replaces the old path. First module live in 2–4 weeks at $3,000–6,000.
The signals that you have outgrown the package
These are the ones that actually predict a successful move, in the order they usually appear. Two of them is a configuration problem. Four is an outgrowth problem.
- The spreadsheet next to the software. A process starts in the tool and finishes in a spreadsheet, every time, and everybody has stopped noticing. That spreadsheet is a specification of the missing module.
- Seats bought for reading. You pay per user for people who only need to see a number. In a package that is a licence; in a system you own it is a page.
- The process bends to the software. The thing that makes your company work — how you price, how you approve, how you schedule — has been reshaped to fit fields designed for someone else's business.
- Data you cannot reach. The answer to an operational question exists, but only inside a report the vendor decided to build, and getting at the underlying records means an export and an afternoon.
- Integration by copy and paste. The same record is typed into two systems by a person, which is both an ongoing cost and a permanent source of disagreement between the two.
- The renewal conversation has changed. Price increases, forced tier upgrades and modules bundled in that you did not ask for. This one is not a technical signal, but it is often the one that starts the project.
Working out the cost, with your own numbers
We do not publish a saving percentage, because it would be invented. The comparison depends entirely on your seat count, your workaround hours and your renewal history, and those are numbers you already have. Take the same period for both sides — five years is the honest horizon — and fill in the left column first.
| Cost line | Staying on the package | Custom system |
|---|---|---|
| Licensing | Seats × price × 60 months, including the seats bought only for viewing | None. Users are rows in a table, not a line on an invoice |
| Add-on modules | Tier upgrades and paid modules added to reach features you needed | Built once into the scope you specified |
| Connectors | Per-connector or per-transaction fees for integrations | Integration built as part of the system; see integrations |
| Manual workaround | Hours per week × loaded hourly cost × 52 × 5 | The workaround is the module; the hours end when it goes live |
| Build | None | $3,000–6,000 per module, $8,000–15,000 for a multi-department system |
| Ongoing support | Included in subscription, and not optional | Optional, at 12–25% of build cost per year depending on scope and response time |
| Price risk | Set by the vendor; your only lever is leaving | You own the code; the only future cost is work you choose to commission |
The line most companies omit is the fourth one, and it is usually the largest. The full five-year arithmetic is worked through on packaged vs custom, and there is a longer written comparison in the five-year TCO guide.
What to move, and what to leave exactly where it is
The most common mistake is treating this as a replacement project. It is not. It is a boundary change: some things move, most things stay, and knowing which is which is most of the design work.
| Area | Recommendation | Why |
|---|---|---|
| Statutory accounting, e-invoicing, payroll | Leave in place | Regulated, well served by packages, and the compliance burden of rebuilding is never repaid |
| Email, files, chat | Leave in place | Commodity software you are unlikely to outgrow, and nobody's competitive advantage |
| Your operational process | Move | Quoting, approvals, work orders, scheduling and fulfilment are where your company differs and where packages force compromise |
| Reporting on operations | Move | Once the operational data is yours, reports are queries rather than exports |
| Customer and supplier self-service | Move | Per-seat pricing makes external users expensive in a package and free in a system you own |
Getting your data out: test this in week one
Every migration plan rests on an assumption about data extraction, and the assumption is usually made by someone who has not tried it. Test it before the plan is written, not after it is approved. Four questions, in this order:
-
Does the export cover every record type?
Most vendors export the obvious entities well and the rest badly. Check the joining records: notes, activity history, custom fields, approvals and attachments. Those are the ones that turn out to matter.
-
Does it include history, or only what is open?
An export of open orders is not a migration. Decide early how much history you genuinely need in the new system and how much can be archived read-only, because that decision changes both effort and cost.
-
Do documents and attachments come with it?
Files are frequently missing from exports and are frequently the hardest part to retrieve later. If they can only be fetched one call at a time through an API, that is a scheduling constraint you need to know about now.
-
Will the rate limits let you finish?
Extracting a few years of records through a throttled API can take longer than building the module. Run a measured sample, calculate the full extract from it, and plan around the real number.
Where a vendor offers no usable export, extraction at database or interface level is often still possible. What is not acceptable is discovering the answer during the cutover.
Running both systems in parallel
Parallel running is what makes the move safe, and it is the step companies try to skip because it feels like double work. It is double work, briefly, and it is the reason nobody has to bet a trading week on a launch date.
The pattern is the same for every process. The new module goes live for one team, one product line or one branch, while the old path continues untouched. Both are used for the same real work. The outputs are compared — totals, counts, the documents produced — until they agree, and disagreements are investigated rather than explained away, because a disagreement is either a bug or a misunderstanding of the process, and both are worth finding then rather than later. Only when the two agree is the old path retired for that scope, and only then does the next scope start.
The staged version of this, including how the accounting boundary is handled, is set out on the migration guide.
A realistic sequence for an SME
-
Inventory the workarounds
Every spreadsheet, shared document and manual re-entry that sits beside the package, with the hours each consumes per week. Half a day of work; it becomes both the business case and the build order.
-
Prototype the heaviest one
Clickable screens for the process that costs the most hours, in about 2 weeks. Cheap enough to change, real enough to argue with.
-
First module live, in parallel
2–4 weeks, $3,000–6,000, with the old path still running. The subscription is not cancelled yet, and nothing irreversible has happened.
-
Bridge to accounting, then extend
Connect the new system to the accounting package so nothing is entered twice, then move the next process. A multi-department system reaches $8,000–15,000 over 4–8 weeks; the bands are on pricing.
-
Reduce the subscription to what is still used
Drop seats and tiers as processes leave the package, at renewal rather than mid-term. Some companies end with no subscription; many keep a smaller one for accounting, which is a perfectly good outcome.
When you should stay on the package
- Your process is genuinely standard. If the package fits without workarounds, it is the cheaper answer and we will tell you so.
- The seat count is small and stable. Per-seat pricing only becomes the problem when the number of people grows or when external users are added.
- The pain is training, not fit. A team that has not been shown how to use the tool will produce workarounds that no custom build would remove.
- Nobody can own the process. A custom system needs a person inside the company who decides how the process should work. Without them the build stalls, whichever supplier does it.
If you are weighing this decision for the first time, custom software describes what a built system actually contains, and the quote form takes about three minutes.
Frequently Asked Questions
How do we know we have actually outgrown the package rather than configured it badly?
The test is where the workarounds live. If your team exports to a spreadsheet to finish a job the software started, if a process step exists only in someone's head because the tool has no field for it, or if you pay for seats so that people can read rather than work, the fit has gone. Badly configured software produces complaints about clicks and layouts; outgrown software produces parallel systems. Before deciding, list every spreadsheet and shared document that sits next to the package. That list is the honest specification of what the package does not do.
How do we work out whether a custom system is cheaper, using our own numbers?
Take four figures for the same period, usually five years: subscription cost including every seat and add-on module, connector and integration fees, the hours your team spends on manual workarounds priced at their loaded cost, and the price increases you have actually seen so far applied forward. Compare that total against a build cost of $3,000 to $6,000 for a single module or $8,000 to $15,000 for a multi-department system, plus optional support at 12% to 25% of build cost per year. We publish no saving percentage, because the answer depends entirely on your seat count and your workaround hours.
Do we have to replace everything at once?
No, and replacing everything at once is the most reliable way to fail. The normal pattern is to keep statutory accounting and payroll where they are, move one operational process into a custom module, run both systems in parallel until the numbers agree, and only then retire the old path for that process. Each subsequent process repeats the same three steps. Nothing depends on a single cutover weekend, and at every point you can stop and still be better off than when you started.
Can we get our data out of the current system?
Usually yes, but it needs testing before anything is promised. Four things to check: whether the export covers all record types or only the main ones, whether it includes history rather than only open items, whether attachments come with it, and whether API rate limits allow a full extract in reasonable time. Where there is no usable export, database-level or interface-level extraction is often still possible. Run the test in the first week, because it decides both the plan and the schedule.
What happens to the integrations we already have?
They are inventoried and then rebuilt or bridged deliberately. In most SMEs the list is shorter than expected once it is written down: accounting, e-invoicing, a shipping provider, a marketplace, sometimes a bank feed. The custom system connects to the same endpoints through an API or a database bridge, and the connection is tested alongside the old one before anything is switched. Nobody discovers a missing integration on the first day of live running if the inventory was made properly.
Will we be locked into you instead of into the SaaS vendor?
No, and that is checkable rather than promised. Source code, database schema and intellectual property transfer to you on delivery; there are no per-user licences and no runtime component that stops working if the relationship ends. The system can be hosted on your own infrastructure. Support is optional, priced yearly as a percentage of build cost, and can be declined without the software degrading. The practical test of any supplier is what you own the day you decide to leave.
How long does the first module take?
A clickable prototype in about 2 weeks, and a first module live in 4 to 6 weeks at $3,000 to $6,000. The first module is usually the process with the heaviest manual workaround, because it repays the fastest and it proves the approach to the team that has to trust it. A multi-department system, meaning several processes and the bridges to accounting, is $8,000 to $15,000 over 2 to 4 months, delivered one module at a time rather than as a single launch.
Send us the spreadsheet you keep next to the software.
It is the most accurate specification your company has. We come back with a module order, a data extraction plan and a fixed price for the first step.