Software
We design, build and operate our own products — and do the same for clients. What we know about shipping software comes from running it, not from advising on it.
Start a conversation
How this is usually done, and why it disappoints
A specification is written, a vendor is engaged, and something arrives months later that answers the question as it stood at the beginning.
The parts nobody wrote down — operations, monitoring, backups, the migration path, what happens when it breaks at night — turn out to be the parts that decide whether the system is usable.
We build products we then have to operate ourselves. That changes which corners get cut, because we are the ones woken up by them.
What we do
- Product development from concept to a system running in production
- Data-heavy and analytical applications, where correctness matters more than surface
- Integration with existing systems and data sources, including the awkward ones
- Operation: deployment, monitoring, backups, incident response
How we work
- Short cycles with something running early, rather than a long silence and a big reveal
- The system is deployed and observable from the first weeks, not at the end
- Written decisions: what was chosen, what was rejected, and why
- Handover that includes operations, not just a repository
What we build on
- Our own products in production, including platforms serving external users
- Infrastructure operated in the European Union, with data protection designed in from the start
- Quantitative and modelling work as a core competence, not an add-on
What we hold to
Running beats described
A demo on a laptop proves nothing about a system under load with real data. We aim to have something deployed early, because that is where the real questions appear.
Speed measured in delivery
AI-augmented development lets us iterate in days where the industry norm is quarters. We would rather show that in a working increment than quote a figure about it.
Whoever builds it, operates it
Design decisions look different when you are responsible for the incident. That is why our products and our client work follow the same standard.
Questions we are usually asked
Do you take over an existing system?
Yes, provided we can first read it and say honestly what shape it is in. Taking responsibility for code nobody has assessed helps no one.
Where does the data live?
In the European Union unless you require otherwise. For our own products this is a design constraint from the outset, not something retrofitted.
Can you work alongside our internal team?
That is usually the better arrangement. We bring delivery pace and the domain we know; your team keeps the context nobody outside the company has.
Tell us what needs to exist
Not a specification — a description of the decision or the process the system is supposed to serve. The specification is our job.
Start a conversation