Engineering

How we build and run software

We don't hand over a zip file and wish you luck. We build your software, and we run it ourselves: on our own platform, with the same pipeline, checks and monitoring for every customer.

Plan an intro callRead how we deploy

In short

What that means for you

  • Your data stays in Europe

    Our own Kubernetes and virtualisation clusters run at Hetzner in Falkenstein, Germany and Helsinki, Finland. Everything falls under the GDPR.

  • Every change is checked

    Every change goes through a merge request, code review by a developer and automatic tests and security scans, before it reaches production.

  • Updates without downtime

    New versions roll out next to the old ones. Traffic only moves over once the new version is healthy.

  • We notice problems first

    Grafana, New Relic and Sentry watch the platform and the applications, so we usually know about an error before you do.

By role

Depending on your role

Not everyone who looks at a development partner cares about Kubernetes. Here's what our way of working means, depending on where you sit.

  • CEO or owner

    Continuity and less risk. Your software doesn't depend on one person: a fixed team knows it, every change is recorded in Git, and it runs on a platform we maintain.

    What that looks like
    • Data stays within Europe, under the GDPR.
    • An ISO/IEC 27001 certified way of working.
    • Uptime and response times agreed in an SLA, if you need them.

  • CFO or finance manager

    Costs you can plan for. A fixed monthly fee for development, SLA and hosting, so your software doesn't turn into an open-ended invoice.

    What that means
    • Fixed monthly costs possible for development, SLA and hosting.
    • Capacity that scales up or down when you need it.
    • One supplier for building, running and hosting your software.

  • CTO

    A setup you'd choose yourself: Kubernetes, GitLab CI/CD, configuration in Git, and monitoring with Grafana, New Relic and Sentry.

    The details
    • Every change through a merge request and code review.
    • Static code analysis and container scanning in every pipeline.
    • Separate development, test, acceptance and production environments.
    • Direct contact with the developers who build it.

    Read From merge request to production and how our platform is set up.

  • IT manager or head of operations

    Software that keeps running, and one less thing to worry about. We host it, watch it and update it, and we're usually on an issue before your users notice.

    How we keep it running
    • Monitoring with Grafana, New Relic and Sentry, day and night.
    • Updates without downtime: new versions only take over once they're healthy.
    • Backups every day, on clusters in Germany and Finland.
    • Uptime and response times agreed in an SLA, if you need them.

  • Product owner

    Short cycles, and you can see everything. Every change can be tried on acceptance before it goes live.

    Day to day
    • Message any developer or designer on your team directly.
    • A prototype first, before the real build.
    • Questions, improvements and bug fixes picked up in hours, not next sprint.

  • Marketeer

    A website that loads fast, is easy to find in search engines and AI answers, and that your team can change in a CMS without calling a developer. Like this one.

    What you get
    • Pages built from blocks your team can combine and reorder.
    • Structured data and metadata for search engines and AI answer engines.
    • Images that are resized and compressed automatically.
    • Preview your changes before you publish them.

The platform

We run our own Kubernetes and virtualisation clusters, with nodes in two locations: Falkenstein in Germany and Helsinki in Finland. On top of that we run the services most applications need, set up to keep working when a server fails: MySQL clusters, Ceph and S3 storage, load balancers and automatic incremental backups and snapshots.

Application data is backed up every day. Backups are encrypted, kept for at least two weeks and stored in a separate location, at DigitalOcean Spaces in Amsterdam or Frankfurt.

Read more about how the platform is set up.

From idea to production

How a change reaches production

  1. Merge request

    Every change starts as a merge request in our own GitLab. Nothing goes straight to production.

  2. Code review

    Another developer reviews the change. AI can help write code, but a person decides whether it gets merged.

  3. Automatic checks

    The pipeline builds the application, runs the tests, scans the code and the container image for known vulnerabilities, and stops if anything fails.

  4. Acceptance

    The change goes to an acceptance environment with test data, where you can try it before it goes live.

  5. Production

    A rolling update without downtime, with HTTPS certificates that renew themselves. Then we keep an eye on errors and performance.

Separate environments, separate data

Most applications have a development, test, acceptance and production environment. Only production contains real data; the other environments use test data. All code lives in our own GitLab server, so we always know who changed what, and why.

Read the full walkthrough of our pipeline, or our information security policy.

Technologies

What we work with

Taken from our projects: every technology here is used in at least one of them. Open one to see where.

Want to see how this would work for your application?

We're happy to walk your team through the platform and the pipeline. Usually that's a good start for the conversation about hosting and SLAs.

Plan an intro call