Express Intervention

Cloud and infrastructure engineering, from operations to the services themselves.

Renting servers from AWS, Azure or Google Cloud and deploying an app gets you a lease on a building, and tells you nothing about what's holding it up. We help you understand and run that infrastructure, and we also write the software services it's made of.

Tell us about your infrastructure

A lease on the building, and knowing what holds it up

A provider like AWS, Azure or Google Cloud rents you machines, storage and networking, a bit like renting floors in a tower. Deploying an app there settles the hosting question. It leaves open the ones that get expensive later: what happens when a machine dies, who gets alerted, how you handle more users, and why the bill keeps climbing.

Outages don't check the calendar. Picture 3 a.m.: whoever gets woken up may not have written the code, and they need to see what broke and know what to do, right now. We think that night decides how a system should be designed, far more than the tidy diagram from the architecture meeting. Kevin Vavelin spent years on banking infrastructure, where that question comes before the others.

So our work has two sides. One is architecture and operations: laying out the infrastructure, deploying it, monitoring it and keeping its cost reasonable. The other is cloud software engineering, meaning we write what nobody can rent you, like the server your devices connect to or the shared core of a platform several of your customers use.

We're a French software engineering company working remotely with clients in France and abroad, including the United States. If one well-monitored server is enough for your business, we'll tell you, and we'll talk you out of the rest. Complexity bills you every month and every night. The provider stays your call.

Capacity model · synthetic data

Survive a failure. Know the limit.

HTTP / async
Entry pointHTTPS · 96 req/s
Load balancerHealth check / exclusion
Instance A60 req/s
Instance B60 req/s
Instance CNot started
Durable queue → workerDeferred work · idempotent recovery
Shared storageRequires its own resilience strategy
Demand
96 req/s
Served
96 req/s
Rejected
0 req/s
Capacity meets demand.
Healthy instances share incoming requests. Deferred work goes through a durable queue.

Keeping it standing, and writing what stands

Most projects touch both sides, because good services suffer on sick infrastructure, and no infrastructure can rescue a badly thought-out service.

Cloud architecture and operations

One question runs through this side: does your service hold up, and at what cost? We're fans of infrastructure as code, which means describing servers and networks in files, because it swaps one person's memory for something you can read and recreate exactly. Scalability lets the system keep up as users grow. High availability keeps it serving when a component fails. Observability shows what's really going on inside, monitoring alerts the right person, and operations is the written routine that keeps all of it in shape long after launch.

  • Cloud architecture
  • Infrastructure as code
  • Automated deployment
  • Scalability
  • High availability
  • Observability and monitoring
  • Resilience and failure recovery
  • Security and access control
  • Cost optimization
  • Automation
  • Day-to-day operations

Cloud software engineering

This side is about what you can't rent. A backend, the server side of a product that users never see, becomes a distributed system the moment several programs on several machines have to act as one. That changes the job: a message can show up twice or not at all, and the program still has to get it right. An API lets two pieces of software exchange data. A multi-tenant service runs many customers on one platform, each with their data kept apart, and orchestration assigns and coordinates work across those services.

  • Cloud services specific to your business
  • Backends and distributed systems
  • APIs
  • Multi-tenant services
  • Communication systems
  • Protocols and integrations
  • Service orchestration
  • Data management
  • Platform design
  • Distributed services and background processing
  • Infrastructure components

A failing service, a slow database, a stuck deployment?

When something's broken right now, you need someone to look at it, and a big project can wait. We offer remote help with a failing service, slow queries, a server problem, a deployment or a configuration. The scope is confirmed before work starts and you get a clear written report. Diagnosis at a fixed price, from €149. VAT not applicable, art. 293 B CGI.

Get an Express Intervention

When renting stops being enough

You may recognize yourself in one of these. They're examples of what can be built or taken over, and they aren't a client list.

  • A multi-tenant SaaS platform

    The classic trap is one installation per customer, until the day nobody can keep up with them all. On a shared platform, each customer gets their own data, access and settings, kept apart from everyone else's. That separation belongs in the design from the start, because it's painful to bolt on later.

  • Infrastructure that outgrew its operations

    Nobody knows everything that's running anymore or what depends on what, and everyone's afraid to unplug anything. We take inventory, describe the whole thing in files and automate deployments, without rebuilding it all.

  • A service that has to keep running through failures

    Multiple copies of the service, a failure that stays contained instead of taking everything down, and a written recovery plan, meaning the steps to get back up after a serious incident. We insist on testing it before you need it, because a plan nobody has tried is just a theory.

  • A communication or protocol server

    A website answers and forgets. A protocol server stays connected to many devices, speaks their language and has to ride out their reconnections without losing a message, like the server behind an EV charging network. This is work we especially enjoy.

  • A cloud bill nobody can explain

    We walk through the bill line by line, find what you're paying for and not using, then rank changes by what they save and what they could break. The most tempting cut isn't always the safest one.

A language for each floor of the building

We pick based on what you already run and what your team can maintain, because a great language nobody on your side can read does you no favors. And we'll explain the choice.

  • Rust

    For infrastructure services that need to use few resources and stay predictable as load climbs.

  • Java

    For backends meant to last, and for extending a Java system already in production. It's solid, and we see no reason to run from it.

  • C++

    For components close to the operating system, where performance comes down to each operation, and for existing C++ code.

  • Swift

    For a server-side service that shares code with an iOS app, when that sharing really pays off.

  • C#

    For existing .NET backends that need to change without a rewrite.

  • AWS, Azure, Google Cloud, Oracle Cloud, Cloudflare, Vercel

    Possible targets. You choose where your infrastructure runs, and we work there.

From inventory to handoff

  1. 01

    Look at what's running

    Before we have an opinion, we look at the system, the bill, past incidents and real load. You know where you stand before anything gets decided.

  2. 02

    Pick the simplest thing that holds up

    Every architecture decision is written down with its tradeoffs and cost, so whoever reads it two years from now understands why. We stay with the simple option for as long as it's enough.

  3. 03

    Build in steps

    Services, deployment and monitoring move forward in small, tested pieces, failure scenarios included, because a recovery nobody has tried isn't worth much. You see what changes at each step.

  4. 04

    Hand it over

    As set out in the quote, you get the code, documented architecture, failure procedures and a maintenance plan. You can carry on with us or without us, and we want that to be true.

Small infrastructure, fixed price

A real server, a published offer, a simplified demo

Let's start with what isn't real. The resilience demo runs on a simplified model with simulated data. It shows a behavior and doesn't measure any system. The rest you can check.

Where to start, depending on the size of it

Cloud audit & migration

€3,000

For a small infrastructure and one target provider. €1,500 at order, €1,500 on delivery. If the audit turns up a larger scope, we tell you before the migration. VAT not applicable, art. 293 B CGI.

See the cloud offer

Senior consulting day

€900

A day to unblock an architecture decision, review a system or get to the bottom of a recurring incident. VAT not applicable, art. 293 B CGI.

See the consulting day

Engineering project

Custom quote

A service to write, a platform to design, an infrastructure to take over. Hosting, third-party licenses and ongoing maintenance are spelled out separately in the quote.

Send a brief

Frequently asked questions

A hosting provider rents you the place where your software runs. Cloud engineering decides how it runs there: what happens when something fails, how it handles load, how it gets updated, what it costs. It also includes writing the services your infrastructure needs that no provider sells off the shelf. For a small site, good hosting may be all you need, and we'll say so.

Yes, and we like starting there. Infrastructure that's running, however messy, has already met reality, which no fresh diagram has. We take it as it stands and improve it in steps. We only suggest a full rebuild when it costs less than improving what's there, and we show you why.

The one you choose, including AWS, Azure, Google Cloud, Oracle Cloud, Cloudflare or Vercel. If you're undecided, we compare the options against your constraints: cost, where your data lives, what your team knows. The decision stays yours, and it gets made on your numbers.

Most of the work happens in writing, and we like it that way: a written decision can be reread six months later, while a phone call fades. Calls are booked ahead of time. We're a French company working remotely by default, and prices are in euros.

Not necessarily, and we may talk you out of it. Microservices means breaking one large program into small independent parts. That's justified when those parts really change at different speeds or need to scale separately. Otherwise you trade a code problem for a network problem you get to operate every day. We recommend it only when the gain is clear for your situation.
Software project

Tell us what wakes you up at night.

What's running, what worries you, what you'd like to build, in whatever order it comes out. We'll reply with what we can do, what you're better off leaving as it is, and a price.

  1. 01You describe the need
  2. 02We clarify the scope
  3. 03You receive a detailed quote
Discuss a project

What do you need to ship?

Pick whatever comes closest. The brief opens on that subject, and we'll sort out the details together.

  • A clarified scope
  • A detailed quote
  • Direct contact with the engineer