By Roy Van Eijsselsteijn, CEO of Interactivated
When a company runs on too many tools, a new ERP is usually the first answer that comes up. It is a reasonable answer, but it is not the only one. You can also replace several software packages with one platform built around the way your company works, and keep buying only what genuinely makes sense to buy. Which route suits you depends on two things: how many of your tools overlap, and how specific your way of working is. In this guide we show you how to map the tools you have, what to replace first, and what you are better off leaving alone.
Choosing a new ERP or replacing your software packages: what is the difference?
Both routes have the same goal: ending the patchwork of tools that nobody quite has an overview of. They just get there in very different ways.
A new ERP is one system from one vendor that covers finance, sales, purchasing, stock and often HR as well. You adapt your processes to its modules, configure it to your company and roll it out across the organisation, usually in one large project with one go-live date.
One platform of your own takes a narrower approach. It replaces only the tools that overlap or fit badly, such as your CRM, your project tracking and your internal workflows. It is custom software built around the way your team already works. Bookkeeping and payroll stay with the packages you buy, and you replace one tool at a time instead of everything at once.
Is a platform of your own a custom ERP?
Partly, but not quite. A custom ERP usually means rebuilding everything a standard ERP does, from finance to payroll, and that is rarely a wise investment. The platform route is deliberately narrower: it connects the work that is specific to your company, and leaves standard administration to standard software that already does it well.
| New ERP | One platform of your own | |
|---|---|---|
| Scope | Most of the company at once | The tools that overlap or fit worst |
| Speed | One large rollout | One tool at a time, starting with a pilot |
| Cost model | Licences per user plus implementation | Build cost plus yearly running cost |
| Fit with your process | You follow the system's modules | The software follows your process |
| Risk | Concentrated in one go-live | Spread over smaller steps |
How to map your software packages before you replace them
Before you choose a new ERP, or decide to replace software packages yourself, it pays to write down what you already have. In our experience, most companies cannot name every tool they pay for, let alone say what each one is actually used for. Making that list is the first real step, and it is exactly the step most advice on choosing an ERP skips.
Copy the table below and add one row for every tool. Do not forget the small ones, or the tools a single team quietly bought on a company card.
| Tool | Cost per year | Users | Who uses it, and for what | Data it holds | Integrations | Workarounds |
|---|---|---|---|---|---|---|
| [e.g. CRM] | ||||||
| [e.g. project tool] | ||||||
| [e.g. spreadsheet for planning] |
A few tips for filling it in:
- Cost per year. Use the actual invoices rather than the price page. Add the add-ons, the extra seats and the hours someone spends keeping the tool running.
- Users. Count the people who actively use the tool, not the number of licences. The difference between the two shows what you are paying for without using.
- Who uses it, and for what. Ask the teams themselves, not only the person who bought the tool. You will often find two teams using the same tool for completely different jobs.
- Data it holds. Note whether it holds customers, projects, hours, invoices or documents, and mark which tool is the source of truth for each.
- Integrations. Write down which links are built in, which run through a separate connector tool, and which are really just someone copying data by hand.
- Workarounds. List the extra spreadsheets, exports and manual updates. These tell you exactly where a tool does not fit.
Once it is finished, the table answers three questions at a glance: what you pay, what overlaps, and where people are doing work the software should be doing for them.
Where duplicate entry and too many tools cost you money
The cost of too many tools is rarely the subscriptions alone. The bigger cost is the same data being typed in two or three places, and the errors that creep in when those copies slowly drift apart.
To make that visible, turn your inventory into an overlap map. Put the types of data in the rows and your tools in the columns, and mark every place where that data is entered or edited.
| Data | CRM | Project tool | Invoicing | Spreadsheets |
|---|---|---|---|---|
| Customer details | ||||
| Projects and scope | ||||
| Hours | ||||
| Invoices |
Every row with more than one mark is a place where tool sprawl is costing you. For each of those rows, ask yourself three questions:
- Who types this data in again, and how often does that happen?
- What goes wrong when one of the copies is out of date?
- Is the data moved by a person, by an export, or by an integration that breaks every now and then?
Some of these overlaps can be solved by connecting software you already have and want to keep. But when the same data passes through many tools and the links keep failing, one shared data model is often the better answer. That is the point where consolidation really starts to pay off.
What you should not build yourself
Some software should simply stay bought, whichever route you choose. Building it yourself would add risk and cost without making your company work any better.
- Bookkeeping and accounting. Tax rules and reporting formats change every year. A good package keeps up with those changes, so you do not have to.
- Payroll. Rules on pay, tax and pensions are detailed, and the cost of a mistake is high. This is work best left to specialists.
- Other compliance-heavy systems. Anything that has to follow sector rules, certifications or legal retention periods is usually safer as a standard product.
- Generic office tools. Email, calendars and file storage are cheap and reliable, and they are not where your company is different from others.
Our rule of thumb is simple: buy what is the same for every company, and build what is specific to yours. Your own platform then connects to these systems, instead of trying to replace them.
What you can replace with one platform
The tools worth replacing are the ones that hold your company's own way of working. That is where standard packages force your process into their shape, and where data overlaps the most.
- CRM. This becomes a candidate when your sales process does not match the package and the bill grows with every new seat. See our article on choosing a custom CRM or HubSpot.
- Project tracking. This is worth a look when teams keep adding custom fields, automations and manual updates to a generic work-management tool. See our article on renting or building a project management tool.
- Internal workflows. Think of approvals, planning, intake forms and handovers that currently run through email and spreadsheets.
- Client portals. A place where your clients can see status, documents and invoices, fed by the same data your own team works with.
These four often share the same core data: customers, projects, hours and invoices. When they live together in one platform, that data is entered once, and every team works from the same version of it.
You do not have to replace software all at once. Start with the tool that costs the most and fits the worst. Some companies end up with a platform that covers most of what a bespoke ERP would have done, without ever having planned one. Others replace a single tool and stop there, and that is a perfectly good outcome too.
Step-by-step: from several subscriptions to one platform
A new ERP is usually one big project with one big go-live. The platform route works the other way around: you replace software in small steps, and each step is tested before you take the next. That way your operations keep running while things change around them.
- Make the inventory. Fill in the tool table and the overlap map from the sections above, and agree with the teams on what each tool is really used for.
- Pick the first tool. Choose the one that costs the most and fits the worst. A high bill combined with many workarounds gives you the fastest return and the clearest test.
- Scope a pilot. Describe the few workflows people use every day, rather than every feature of the current package. A tight scope is the single most important protection against a build that runs over time and budget.
- Build the core flow. Build the pilot as a real, working product, connected to the systems you keep, such as your bookkeeping. Our notes on SaaS development explain how we set this up.
- Run in parallel. Use the new platform next to the old tool for a set period. Compare the results and fix any gaps before anyone depends on it.
- Migrate the data. Plan the software migration carefully: export the history from the old tool, clean it up and import it. Then check that records, attachments and links have all come across.
- Retire the subscription. Cancel the old tool only once the team works fully in the new platform. Then go back to step 2 and pick the next one.
AI-assisted development shortens these early builds considerably. Senior engineers use AI tooling to produce working screens and integrations faster than before. It does not replace senior engineering, though. Architecture, security, data migration and code review still need experienced people, and that is exactly what keeps the platform maintainable in the long run.
Which costs count for a new ERP or a platform of your own
If you compare the two routes on licence price alone, you will get the wrong answer. To make a fair comparison, count every cost line over several years, for both routes.
| Cost line | New ERP | Platform of your own |
|---|---|---|
| Start | Implementation partner, configuration, data migration | Build of the first tool, data migration |
| Recurring | Licences per user, often rising at renewal | Hosting, maintenance, security updates |
| People | Training, internal key users, change management | Product owner time, training |
| Change | Customisation by the vendor or partner, upgrade projects | New features built as needed |
| Tools that remain | Packages the ERP does not replace | Bookkeeping, payroll and other bought systems |
Two of these lines are often missed. First, implementing an ERP takes many hours from your own staff, not only from the implementation partner. Second, a platform of your own never has a running cost of zero: someone has to host it, maintain it and own it.
The same applies if you are planning to renew your ERP, or to replace an ERP system you already have. The old licences, the migration and the internal hours all belong in the sum.
For the full calculation, including a break-even formula you can fill in with your own numbers, see our article on own software instead of SaaS.
Risks and how to limit them
A platform of your own comes with risks of its own, and it is better to name them before you start. For each one, agree up front how it will be handled.
| Risk | What can go wrong | How to limit it |
|---|---|---|
| Maintenance | Nobody owns the software after launch and it slowly falls behind | Agree a maintenance plan and a named product owner before the build starts |
| Adoption | Teams keep using the old tool or a side spreadsheet | Involve the daily users in the pilot scope and run both systems in parallel |
| Lock-in with the builder | You depend on one supplier for every change | Own the code and the repository, require documentation, agree handover terms |
| Security | A custom system has gaps a mature package has already closed | Senior code review, regular updates and security testing as part of maintenance |
| Scope creep | The project tries to copy every feature of the old package | Start with the workflows in daily use and add the rest only when needed |
The phased approach takes care of most of these risks by itself. If the first tool does not work out, you have lost one pilot, not a company-wide rollout.
Frequently asked questions
Not in the classic sense. A custom ERP would rebuild finance, payroll and everything else. A platform of your own covers the work that is specific to your company, and connects to the standard systems you keep using.
Bookkeeping, payroll and other compliance-heavy systems. They follow rules that change every year, and good packages take care of that for you.
With the inventory. List every tool with its yearly cost, its users and its workarounds. Then pick the tool that costs the most and fits the worst, and scope a pilot around it.
That risk is real, so arrange it in the contract. Make sure you own the code and the repository, that the system is documented and that handover terms are agreed. Then another team can take over if it ever comes to that.
That depends on how many tools you replace, how much history you migrate and how long you run both systems in parallel. Because you replace one tool at a time, each step is far smaller than a full ERP rollout, and the company keeps working throughout.
How we approach this at Interactivated
When a company asks us whether it needs a new ERP, we do not start with a sales pitch for building. We start with the inventory from this article. Together we list every tool, look at the real invoices, and talk to the people who use those tools every day. That usually shows quite quickly where the overlap is, and which tool is costing the most for the least fit.
If a platform of your own makes sense, we pick that one tool and scope a pilot around the workflows the team uses daily. It is connected to the systems you keep, such as your bookkeeping, and it runs next to the existing tool until the team is confident enough to switch.
Our senior engineers build with AI tooling, which helps us get a working first version in front of your team sooner. Every part is still reviewed by experienced engineers, because the data model, the security and the migration decide whether the platform will still be easy to maintain years from now.
The code, the repository and the documentation belong to you, so you never trade one lock-in for another. After launch we keep the platform hosted, updated and secure, and we grow it with you, one tool at a time. And when we think a standard package will serve you better, we will say so.
Have your software packages reviewed
Not sure whether you need a new ERP or one platform of your own? We are happy to go through your tools with you: what you pay, where data overlaps, and which tool would make a sensible first pilot. You will get an honest view, including the cases where buying is the better choice. Plan a conversation about your situation.