Skip to content

Rebuild, when it is the cheapest option

A rebuild is not decided under the pressure of an outage. It is decided with figures.

When should you rebuild?

When keeping the tool alive costs more than replacing it.

The health check tells you, with your own figures: what the tool costs if you keep it alive for another 12 months, compared with the price of a rebuild. As long as the first amount is the lower one, we fix and stabilize.

The day the balance tips, the rebuild is no longer a gamble: it is the cheapest option, and you know why.

Planning a tender? Start with a requirements specification: what the tool must do, and what it must stop doing.

How we rebuild

Three phases, each priced and invoiced separately.

  1. Customisation

    We tailor the new tool to the way you work, based on what the health check showed.

  2. Development

    We build the new tool, at the price announced for this phase.

  3. Delivery

    The new tool goes live, documented, and takes over from the old one.

You can stop after each phase.

Do you have a technical team? We rebuild alongside it, and hand back a documented tool it can keep evolving.

What we build

  • Web and mobile applications

    The tool your team uses every day, in a browser or on a phone.

  • APIs

    So that your tool exchanges data with everything else, instead of your team copying it by hand.

  • Migrations

    Moving off a framework or language version at end of life: AngularJS, Symfony 2, an old PHP or Java version, among others.

  • Security

    Fixing the vulnerabilities the health check found.

A mobile application is not always the right answer, so we start by checking whether a responsive site would do the job just as well. When an app is genuinely justified, we build it in React Native, together with the API and the back end behind it, and we publish it to the App Store and Google Play.

Frequently asked questions

We are already planning a rebuild. Why start with a health check?

Precisely for that reason: the health check tells you what the rebuild must contain, and what the current tool costs you until then. You decide with figures, not under the pressure of an outage.

What if the tool can still hold out?

Then we do not rebuild it. We first fix what pays back the most, and we keep it alive: that is the second step, stabilize.

Should you rewrite your software?

Not necessarily, even if it runs on outdated technology. Depending on what the health check shows, we can secure it, upgrade it step by step, or rewrite it when that becomes the cheapest option. See your application runs on outdated technology.

The three-step takeover

Rebuilding is the third step. We never propose it before a health check and a first result.

  1. two weeks

    Scope

    In two weeks, a health check of your tool: what it costs you, what will break first, what you can save.

    The health check
  2. fixed price

    Stabilize

    We first fix what pays back the most, at a fixed price, then we keep the tool alive.

    Stabilize
  3. if needed

    Rebuild

    When it becomes the cheapest option. Not before.

Never without a health check

Before any talk of a rebuild, we measure what your tool costs you today.

Not ready yet? Take the free self‑assessment: ten questions, your score straight away.