what we do, and what we don't
We build new software, get old software back in shape and keep both running after launch. We take on a whole project or a clearly bounded sub-project, and we stand behind it.
where we come in
new software
Your process lives in spreadsheets, email and scattered applications, and no standard software fits it. Or you have an idea for a digital product or a customer portal, but nobody to build it.
We turn it into a working application. We sharpen the idea with you, design the architecture, build the software and put it into operation. Instead of copying data from one list to the next, your people then work in software that knows their process.
modernisation
Your old software holds the business back, and the people who built it are long gone. Or a previous vendor left you code nobody can maintain.
We take the software on, learn how it works and get it back in shape. After that it runs, and it can change again when your business does.
keeping it running
After launch, we keep your application running and develop it further with you as new needs come up. Whoever led your project stays responsible for it.
We do this for software we've built or modernised ourselves. We know it well enough to stand behind it.
when your project is missing a piece
Your own development team is building, but it's short of time or know-how for one particular part.
We take on exactly that part as a sub-project, such as a module, a migration or an interface to another system. It's clearly bounded, has its own deliverables, and we answer for it as we would for a whole project.
what we don't do
We don't place specialists in your team by the hour. We take on a project or a sub-project, answer for the result and agree every step with you.
Tenders that come with a finished specification and a fixed price aren't for us. We begin with a starter project, so you see a first version of your software running before you commit.
We leave operations on their own, design on its own and customising standard software such as SAP to others. We can only answer for work we see through from start to finish.
We don't build websites that present your company. We build portals for your customers, or software your people work with.
Sometimes the right software is already for sale. Then we'll tell you in the first conversation, even if it means we don't get the job.
the technology behind it
From here it gets technical: what we build with, where your software runs and what's yours.
Pick a block to see what it does.
Browser
The people who use your application, anywhere in the world.
Cloudflare Worker
Renders the React pages on the server, in a data centre close to the browser.
Cloudflare Tunnel
Connects Cloudflare to your cluster, encrypted, with no ports open to the outside.
Backend
The backend in Java with Spring, in several replicas: if one fails, the others take over.
Valkey
Keeps frequently used data in memory, so answers come back fast.
Elasticsearch
Full-text search across your data.
PostgreSQL
The database your data lives in.
what we build with
Java with Spring on the backend, React or Angular on the frontend. We stick to established technology that plenty of development teams know, so others can maintain your software too. Our strengths are software architecture and DevOps from start to finish, whether we're building, modernising or running your software.
Coding agents are part of our everyday work. So we set them clear guardrails. The more code agents write, the more sound software principles count.
how we build
Whatever can be automated, we automate: tests, dependency updates and the checks before every release. Anyone new to the project has the software running locally on their first day and knows within minutes whether a change works.
Pick a step to see what it does.
Pull request · formatting, lint, architecture rules, integration tests, review by a coding agent
Only code that passes every check gets into your software, down to integration tests against real databases in containers. These are also the guardrails for coding agents: code an agent writes gets in only once it passes them.
Preview · frontend, backend, its own database schema and search index
You can try every change before it goes live, in a complete environment of its own with its own data. It's linked from the pull request and the ticket, and e2e tests play through whole user journeys there.
Test · automatic after every merge to main
You always test the latest state of your software, without waiting for anyone to deploy it. Every merge to main lands in the test environment automatically.
Production · release at the press of a button, release notes, a message to the team
A person decides when a release goes live, at the press of a button. Release notes and a message to the team follow, so everyone knows what's running in production.
Feature request · as a ticket from a department or the IT team
What your department or IT team asks for reaches your software the same way as any other change. Every feature request arrives as a ticket, becomes a pull request and goes through the same checks.
Dependency updates · as pull requests, with the same checks
Your software stays up to date. Dependency updates arrive on their own as pull requests and go through the same checks as any other change.
GitOps · every deploy a commit
You can trace and revert every deploy. With GitOps, each deploy is a commit.
Monitoring · OpenTelemetry: traces, metrics, logs
You see how your software runs in production, and we catch errors before your users report them. With OpenTelemetry, traces, metrics and logs from frontend and backend come together in one place.
An example of how we set up the pipeline on our projects by default. where your software runs
We run frontends and portals on Cloudflare Workers, and light backends too. They need no servers of their own for anyone to run and patch. Protection against attacks and encrypted connections come with the platform, and your application runs close to the people who use it.
Other backends run wherever suits you, including your own servers, and connect through Cloudflare Tunnel. With Cloudflare Access, your team reaches internal applications securely from anywhere, without a VPN. If your IT rules require another platform, we follow them.
Every change runs in its own preview first and is tested there automatically before it goes live. This website works that way too, by the way.
Thomas moved the frontends of customer portals used by millions of people a month onto Cloudflare Workers.
where your data lives
Your stored data stays in the EU. Only the code runs close to the people who use your application.
moving onto cloudflare
We move existing applications onto Cloudflare and answer for the move, on our own or with your IT team, who get to know the platform along the way. That can be the whole application or just what sits in front of it: DNS, caching or Cloudflare Access.
your team
If your company has an IT team, we lead the project and your team works alongside us. In the process, they get to know the software and the platform well enough to run and develop both themselves afterwards.
what's yours
The code is yours, along with the repository, the documentation and the deployment set-up, and your Cloudflare account is your own. Nothing ties you to us.