Every configurator supplier promises availability, speed and regular updates. The question is not whether they promise it, but how they intend to keep the promise — on a Tuesday morning in three years, when the original project team has long moved on. This is how we do it.
Three promises, three foundations
Availability, speed and updates are not separate topics. They rest on the same three foundations:
Hyperscaler infrastructure instead of our own server room
We run our systems on hyperscaler infrastructure — the same data centres that carry the largest platforms in the world. That gives us what no in-house server room can offer at a reasonable price: redundancy across several data centres, power and network that never depend on a single site, and capacity that is available within minutes instead of after a purchase approval.
For you it means: when your sales team grows, when customers start configuring online, when the quotation volume doubles at the end of a quarter, the infrastructure simply grows with it. Nobody has to order, install or write off a server.
Installed and updated by script, not by hand
Every one of our systems is described in code: servers, databases, networks, certificates, the application itself. Development, staging and production are built from exactly the same description — which is why a change that works in staging also works in production.
Manual installation is where systems slowly drift apart: one forgotten setting here, one quick fix there. Automated installation removes that drift — and with it a whole class of problems that only appear in production.
Monitored automatically — by the people who wrote the code
Our systems watch themselves. Availability, response times, error rates, failed jobs, storage and certificates are measured continuously. When a value leaves its range, an alert goes out — before a sales person or a customer notices anything.
The alert reaches the people who built the system. That is the difference to monitoring in-house: the person who sees the problem is also the person who can fix it, at any hour.
We write the code ourselves
We do not assemble configurators from a vendor platform we cannot see into. We write the code ourselves. That sounds like a detail, but it decides how a system can grow: we know exactly where every millisecond of a quotation is spent — and we can change it.
Scaling through software, not only through bigger servers
When a system gets slow, the usual answer is more hardware. It works — up to a point, and at a price that grows with every step. Because we own the code, we have a second lever:
Two ways to make a slow step fast — example
Example values. Hardware scales cost along with speed. Software optimisation is paid once — and keeps paying on every request.
Better queries, intelligent caching, results calculated once instead of on every request, data stored in the form it is read: that is where the large gains are. Hardware is still there when it is needed — but it is the second lever, not the only one. That is how we keep systems fast without passing ever higher server costs on to you.
What that means for you
Put together, the three foundations turn general promises into concrete commitments:
| What we guarantee | How we keep it |
|---|---|
| Availability | Redundant across data centres, automatic failover, monitored around the clock — recovery time agreed in writing |
| Speed | Response times agreed in writing, measured continuously in production and reported every month |
| Updates | Automated, tested in staging, released per series — with a rollback in minutes |
| Your data | Continuously backed up, exportable at any time in an open format |
None of this is an add-on. It is included — because availability, speed and updates can only be guaranteed by a team that is responsible for the code and for the system it runs on. We run what we build.
What to ask any supplier
- On which infrastructure does the system run — and what happens when a data centre fails?
- Is the system installed and updated automatically, or by hand?
- Who is alerted when something goes wrong, and can that person fix it?
- When the system gets slow: is the answer always more hardware — or can the code be optimised?
- Which of these commitments will you put in writing?
These topics are questions 15 to 19 of our buyer’s checklist for product configurators. Why running all of this in-house rarely works is covered in Why In-House Hosting Is Like Building Your Own Aircraft, and why speed matters so much in Speed Is Not a Detail.