We have no cloud
of our own to sell you.
The constraint first, the provider after.
Anyone reselling a cloud will explain why that one is the right answer, whatever the question was. We resell nothing: we work on Azure and DigitalOcean for machines, on Kinsta and Sevalla when a managed platform is what's needed, and the choice starts from how you are built - not from a price list.
There is no right provider. There's the right one for your constraints.
This is, simplified, the conversation we have at the start of every project. Tick what applies to you and watch the answer move.
The questions first, the provider's name after.
We have no default answer, and whoever does is selling something. Tick one or two constraints above: the first conversation we have with you is exactly this one, only longer.
What it runs on today, what it costs and what broke last time. Three answers that often decide on their own.
Microsoft Azure.
If the identities are already in Microsoft and there are requirements to document, Azure saves months: the accounts are the ones you have, and it brings the certifications with it. You pay in complexity and on the bill, not in work.
DigitalOcean would cost less and be simpler - but without the identities and the compliance side you're asking for here.
DigitalOcean.
Real machines, a price you can read in one line and no surprise at the end of the month. It's the most frequent choice when you need control over the machine without paying for a hyperscaler's ecosystem.
Azure has more ready-made services, and Kinsta would take the machine out of the picture. Neither is any use to you for what you've ticked.
Kinsta.
For WordPress and the like there's no reason to manage a server: cache, staging, backups and certificates are already in there. Whoever works inside it never has to know what a VM is.
Your own VM would be more flexible, but with these constraints that's flexibility you'd pay for without using.
Sevalla.
Bespoke applications that scale up on their own when traffic grows, with nobody having to watch the machine. It costs a little control and gives back time.
A machine on DigitalOcean costs less, provided somebody keeps an eye on it. Here you said there's nobody.
The bars are a game, not an algorithm: the real choice is made by talking. But the order they move in is the right one.
Often the answer is stay where you are. If the infrastructure you have holds up and costs the right amount, migrating it is spending with no return: you fix what's wrong and move on.
This isn't a decision to be taken once and for all. We build applications in containers - the same thing runs locally, in test and in production - so moving them from one provider to another is days of work, not months. It's why we can afford not to have a favourite: if in two years the numbers add up better somewhere else, we move.
We don't resell cloud. So we have no favourite to steer you towards.
We keep the machines up. After day one, too.
Set up is the short part. The long one is what comes after: the updates, the backups nobody ever tries restoring, the certificates that expire on a Saturday.
Setting the machines up
It starts from what has to run on them, not from a size on a price list. Network, access, certificates and separate environments are decided once and written down somewhere - not reconstructed from memory at the next change.
Maintenance, not surveillance
System updates, runtime versions, disk space, expiring certificates. These are the things that make no news until they stop everything on a Friday afternoon.
Backups somebody has tested
A backup that has never been restored isn't a backup. We run the tests, and you know how often and how long it takes to come back up.
Costs you can read
We know what you're paying and why. If a test environment has been left running for three months we say so, even though we're not the ones paying the bill.
The first to know something is wrong shouldn't be your client
On the machines we watch that the services respond and that they're not running out of space or memory. On the applications there's Sentry on every project: when a user hits an error we see it with the line of code and the steps that caused it, without having to ask them what they were doing.
It means a share of the problems closes before anyone notices - and that when you write to us, the answer is often already "we're looking at it".
- On the machines
- Services responding, space, memory, certificates about to expire
- On the applications
- Sentry: the error, the line of code and what caused it
- Who the alerts go to
- Us - not an address of yours somebody has to man
When the site is down an investigation shouldn't have to start.
With software and infrastructure split between two vendors, the first half-day of every problem goes like this:
"That's a server problem, ask them."
"The server is up, it's the code throwing errors."
"Everything shows green on our side."
If we keep both the software and the machine it runs on, that phone call doesn't exist: there's one number and nobody to convince. It works the other way round too - if someone else builds the software, we work with them without asking you to change.
If you already have an in-house sysadmin who knows your machines, you don't need us for the infrastructure: we lend a hand when it helps and stop there. This service makes sense when nobody in the company wants - quite reasonably - the responsibility for a server that has to stay up.
Where we have already done it.
Real projects where this service went into production. Same logic, different contexts.
Wholesale ecosystem for collections and media
Orders, replenishments, media and catalogues in a single platform, integrated with the company ERP.
ResultEnd-to-end digitised wholesale process, catalogues generated automatically, evolving since 2019.
Read the case study →Company DWH with middleware and MCP
ERP, HR and other application data centralised and queryable through AI - with no technical skills.
ResultA single source of data, permission-based access, interoperability across every company application.
Read the case study →The questions that come before the provider's name.
Do you resell cloud?
No, and we have no favourite to steer you towards. We work on Azure and DigitalOcean for machines, on Kinsta and Sevalla when a managed platform is what's needed - and the choice starts from your constraints, not from a price list.
How do you choose between Azure, DigitalOcean, Kinsta and Sevalla?
From the questions, before the name: whether you're already inside Microsoft 365, whether the budget is tight, whether traffic spikes, whether you need access to the VM, whether there are certifications to meet, whether the data has to stay in Europe. Often the answer is to stay where you are.
What if we want to change provider later?
You can. We build applications in containers: moving them from one provider to another is days of work, not months. It's also why we can afford not to have a favourite.
What does management cover after set up?
Updates, runtime versions, disk space, certificates. Backups somebody has actually tried restoring. Monitoring on both machines and applications, with Sentry on every project. And one single contact for software and infrastructure - so when the site is down, no investigation into whose fault it is has to start.