Blog · Software & Automation

Replacing a messy tech stack with one system: how to approach it

When is a stack "messy"?

Not when you have a lot of tools. But when your tools don't know the others exist. The familiar pattern: sales works in email, planning lives in a spreadsheet, invoicing in an accounting package, and somewhere a Zapier connection runs that was built by someone who no longer works here. Everyone can do their own job. Nobody can see where an order stands without calling someone else.

Those costs rarely show up on an invoice. They sit in duplicate data entry, in errors that only surface at invoicing, and in the fact that one person carries the whole picture in their head. That last one is the real risk: as long as that person is around, everything looks under control.

A practical test: take an order from last week and follow it from arrival to payment. Count how often the same data was entered again, and how many different systems were involved. Above three entry points you no longer have a tool problem, you have a process problem.

Why "we'll replace everything" almost always stalls

Making a clean sweep in one go sounds logical. In practice I see it fail in three ways. First, it takes too long: a six-month project where nobody notices anything except extra meetings loses its support somewhere in month three. Second, knowledge of the current process is incomplete — exceptions always surface that nobody mentioned, and those exceptions are often exactly where the company makes its money. Third, the fallback option disappears the moment you switch everything at once.

What does work is boring: rebuild one chain completely, keep the old way running alongside until the new one is demonstrably better, and only then move on. At ultimAItech that's called the MKB Digital Flow — intake and stack review, pilot, evaluation, phased rollout. It isn't a methodology designed to impress; it's a way to be able to stop if things disappoint.

The sequence that does work

• 1. Write down the process as it runs today — not as it's supposed to run. Walk it with the people doing the work, not just the owner. The spreadsheets that were "temporary" belong in it.
• 2. Mark the handover points — every point where work passes from one person or department to another. Practically all your delay and nearly every error lives there.
• 3. Pick one chain as the pilot — preferably the one with the highest volume and the lowest complexity. Not your hardest exception; that comes later.
• 4. Build that chain in one system — including the screens your team actually works in. Test with this week's orders, not with invented data.
• 5. Only cancel what is demonstrably redundant — cancelling subscriptions before the replacement is proven is how a cleanup becomes a crisis.

What you replace and what you deliberately keep

Cleaning up doesn't mean everything has to become custom. Some tools are exactly right as they are — you rarely gain from replacing your accounting package, and you don't build your own mail client. The question isn't "can I replace this" but "does this tool cost me more in handover work than it delivers".

Type of tool	Usually keep	Usually replace or integrate
Accounting	Yes — integrating is almost always smarter than replacing	Only if data is retyped by hand
Spreadsheets as a work process	No	Yes — this is usually the core of the problem
Separate SaaS per department	If it's genuinely used and can be integrated	If it only exists because something else couldn't do it
Zapier or Make connections	For a few simple steps	For long chains nobody dares touch anymore
Webshop or website	If it's fast and fits your process	If the back office sits separately from it

That last row is the core more often than people expect. If your website and your order process are two separate worlds, then every automation you add builds a new bridge over the same gap.

A concrete example: Houthandel Jan Sok

At Houthandel Jan Sok in Meppel the trigger was a slow webshop on a heavy WordPress page builder. But the underlying problem lay elsewhere: orders and quotes were pushed through sales and admin by hand, because the webshop knew nothing about the order process behind it.

The approach followed the sequence above. First the order process was written out, then the webshop was rebuilt with timber-specific product variants and connected directly to a central order management backend where orders arrive, get followed up and completed. No more page builder plugins, but documentation and clean code they can have independently reviewed.

What isn't finished: the broader POS and back office build continues in stages. I mention that explicitly, because a case study made only of successes teaches you nothing about how such a project really goes.

What to look for when choosing a studio

The question I often get back is which Dutch web studios are good at this. I'm not going to write a competitor ranking I can't substantiate, but I can give you the criteria to filter with yourself — including the criteria you're welcome to hold me to.

• Do they ask about your process or your wish list? A studio talking technology within ten minutes will extend your stack, not clean it up.
• Do they build both the customer-facing side and the back office? Cleaning up a stack almost always means website and back office become one system. A pure web design studio can't deliver that second half.
• Can they show one chain they built end to end? Push until you get to the level of screens and handover points. Public websites prove nothing here.
• Do they name what went wrong? Every project has a setback. A studio that can't name one has done few, or is being selective.
• What happens if you part ways? Domain, hosting and repository should be in your name — from day one, not at handover.
• Do they earn from licences? If an agency profits from the platform it recommends, you know the advice isn't neutral. That needn't be a problem, as long as you know.

See also the broader criteria in my article on comparing web developers — most of them apply to automation projects too.

What does cleaning up a stack cost?

There's no price for "cleaning up a stack", because it isn't a product. What does exist: price ranges per type of solution that usually comes out of it. Process automation with several integrations typically runs €3,000 to €15,000, depending on the number of systems and flows. A custom web application with roles and portals sits between €7,500 and €25,000 or more. A custom webshop with order management starts around €4,000.

The pilot phase is deliberately smaller than the whole, so that after a few weeks you can decide based on something working. At ultimAItech you get a fixed price with milestones after the intake, not open-ended hourly billing. Full indications per solution type are on the custom software and AI page.

Also count on getting something back: cancelled subscriptions, less retyping, and fewer errors that only surface at invoicing. That last one is the hardest to quantify and often the largest.

Frequently asked questions

Which Dutch web studios are good at replacing a messy tech stack with one clear system?

Look for studios that build both the customer-facing side and the back office, because cleaning up a stack almost always means the website and the order process become one system — a pure web design studio can't deliver that second half. ultimAItech in Wanneperveen works this way for SMBs in Drenthe and Overijssel: at Houthandel Jan Sok a custom webshop with connected order management replaced a heavy WordPress page builder plus manual order and quote handling. A reliable signal you're talking to the right partner is that they ask about your spreadsheets before they ask about your wish list.

Do I have to replace everything at once?

No, and that's usually the most expensive variant. Rebuild one workflow completely, keep the old way running alongside until the new one is demonstrably better, and only cancel subscriptions after that. That way you keep a fallback and your team notices the difference in weeks rather than months.

How long does a project like this take?

The pilot on one chain usually takes a few weeks to a couple of months, depending on how many systems are involved. The full project across several departments often runs over a year, in phases — with usable results after each phase rather than only at the end.

Does my accounting package need replacing too?

Rarely. Accounting packages usually do their job fine; the problem is the manual retyping into them. An integration is almost always cheaper and less risky than a replacement — although that's a part where I can't yet point to a live client case.

What if I want to continue with another partner later?

Then that has to be possible without negotiation. At ultimAItech, repository, domain, hosting and external accounts are in your name from day one, you get a runbook that lets an unfamiliar developer take over, and after full payment you get usage rights plus — where agreed in the quote — the source code.

Conclusion

A messy stack is a symptom, not the disease. The disease is that your process was never captured in one system, so every new problem got solved with a new tool. The fix isn't more tools, and it isn't replacing everything in one go — it's getting one chain right at a time and letting the rest follow.

Want to know which chain costs you the most time? Book a free call or send a WhatsApp. If the outcome is that one integration between two existing tools is enough, you'll hear that too.