Code that runs when there is work, and costs nothing otherwise

Some of your work happens only now and then. A nightly export to your accounting system. A form that is filled in a few times a day. A processing job that suddenly gets thousands of lines at once around the month-end close. A server runs for it, doing nothing the rest of the time, yet it costs money every month and needs maintenance. Serverless turns that around: the code starts when there is work, and is not there otherwise.

When serverless fits and when it does not

Serverless is not a better version of a server. It is a different model. It fits work that arrives in small pieces and finishes quickly: a notification from your online store, an order that arrives as a file and must be processed, a daily check of your stock files, a peak that happens 3 days a month. It fits poorly with a process that computes for hours on end, with software that must keep a connection open permanently, or with a package that simply expects a machine with a disk.

In the free intake, we look at what you run now and how often it is really on. If half of your work turns out to belong on a regular server, we tell you right away. Usually it becomes a mix of both, and then the conversation belongs more to Cloud architecture or Hybrid cloud than to a full switch. If you are still moving away from your own server room, Cloud migration is the step that comes before this one.

What goes away when the server does

The biggest advantage is not on the bill. It is the work that disappears. No operating system to update. No disk quietly filling up. No restart because memory ran out. No capacity to estimate 6 months ahead. If ten times as many requests arrive on a Tuesday morning, the platform starts more instances and later fewer, without anyone doing anything.

What remains is the work we take over: the functions themselves, the permissions around them, the log, and the alerts when something goes wrong. We set up monitoring that notices when a function fails or runs longer than agreed, with an escalation that we fix with you in advance. That system watches day and night and rings the bell.

Connecting to what you already have

Serverless functions are rarely a complete system on their own. They are the glue between things you already use: your accounting package, your online store, your file storage, your database. A function reads an incoming order, checks that the rules are met, writes it to the right system, and sends an alert if something is wrong. We usually keep files in Object storage (S3), so a function does not need to store anything itself and you can also find the files separately.

We build this up step by step. Within 10 business days, a first function runs on real data, so you see what it does before we move the rest. The code, the configuration, and the scripts to roll everything out again go in your own repository, and the data stays in European data centers. You are the owner, including of infrastructure that now exists only on paper.

Cost, cold starts, and lock-in

Paying per call sounds cheap, and for work that comes along now and then, it is. But a function that runs all day eventually becomes more expensive than a fixed machine at a fixed price. We calculate that in advance on your own volumes, not on an example. The same calculation belongs to Cloud cost optimization if you are already in the cloud and the amount comes out a bit higher every month.

We always raise two things ourselves. A function that has not been used for a while needs a cold start, which costs the first call a few hundred milliseconds extra. Nobody notices that in a nightly job, but someone waiting at a service desk does. And serverless ties you to a platform more strongly than a regular server does. So we keep your own logic as separate as possible from the vendor's services, and we write out the setup in scripts, so a later switch is work and not a rebuild and rethink of everything you have.