Java is the basis of almost every system we build — not out of habit, but because robustness, tooling and the availability of developers matter more across the lifetime of an application than short-term convenience. We work on current LTS versions and keep applications deliberately up to date instead of deferring upgrades until a security incident forces the issue.
Development
Software that is still maintainable in year three.
We build backends, middleware and integrations — on a stack we have run in production for years, and in a shape an in-house team can carry forward on its own later.
- Java and Spring ecosystem
- Operated in containers
- The source code is yours
We build the systems that work behind the interface: APIs, middleware, integrations and the data paths in between. Usually where something existing has to keep running or be replaced — rarely on a greenfield.
Our stack is deliberately narrow. We do not use the technologies below occasionally; we know them from production — with their strengths, their operating costs, and the points where they get uncomfortable under load.
Java
Spring
Spring and Spring Boot form the foundation of our services — from a single API backend to landscapes of dozens of services. In past projects we broke monoliths down into independently deployable Spring Boot services and built event-driven middleware mediating between producing and presenting systems. We deliberately pick which Spring building blocks a project actually needs, rather than pulling in the entire ecosystem by reflex.
Magnolia CMS
We have worked with Magnolia since 2017 — across eCommerce, retail, publishing and public institutions. The focus lies where standard functionality ends: custom modules, connections to shop and specialist systems, automated content delivery, hybrid use both headless and non-headless, and features tailored to how a particular editorial team actually works.
Elasticsearch
We use Elasticsearch where search has to be more than an input field: as an index of its own alongside the system of record, replicated across clusters and deliberately laid out to keep read access away from the repository. That includes tooling for operations — such as a CMS module automating the configuration and indexing of entire workspaces.
RabbitMQ
RabbitMQ is our tool of choice when systems should communicate in a decoupled way without one outage breaking the chain. We used it to build a communication layer between editorial and publishing systems, laid out to be redundant and fault-tolerant, running under real load in daily publishing operations.
Apache Kafka
Kafka comes into play when data streams need not just transporting but repeatable processing — for instance when downstream systems should be able to replay a history. We have used Kafka in architecture concepts for cross-channel content delivery, and we also advise on where it does not belong: not every queue needs a log, and not every log needs Kafka.
Docker
Containers are not an end in themselves for us but the precondition for an application behaving the same locally, in test and in production. We ship applications in containers and use the same technique during development — including integration tests against real databases and brokers rather than stand-ins.
Kubernetes
We run Kubernetes where several services interact and where fault tolerance and scaling are genuinely needed — for instance with containerised eCommerce platforms and services that have to absorb substantial load peaks around scheduled publications. For smaller landscapes we advise against it just as openly: the operational effort has to match the benefit.
Docker Swarm
Docker Swarm is the pragmatic alternative when containers need orchestrating but a full Kubernetes would be oversized. We have operated middleware landscapes in publishing with it and value the low barrier to entry — while naming the limits honestly once a landscape outgrows it.
Amazon Web Services
On AWS we build and operate applications from virtual servers and object storage through to serverless building blocks. More important to us than the service catalogue is the cost side: we lay out architectures so the monthly bill stays predictable and a later move remains possible, instead of quietly binding you to speciality services.