Three things we sell on, nine principles behind them, and a process that lets you stop after the second step. None of it is complicated. Most of it is just unfashionable.
01 / 03
Teams treat quality as the thing you trade away when you are in a hurry. It is the opposite: the systems that ship fastest in year three are the ones that were tested properly in year one. We are not interested in craftsmanship as an aesthetic — we are interested in being able to change something on a Friday.
Every engagement leaves behind a pipeline that runs the full suite in under ten minutes.
Lead time, change failure rate, p95 latency, coverage on the paths that matter. We take a baseline in the first week and report against it at the end, including when the number moved the wrong way. Consultancies that only report good news are not reporting.
Baseline in week one, published numbers at every milestone.
Documentation in a wiki rots quietly. Decision records next to the code, checked by CI and reviewed in the same pull request as the change, survive. The test for good documentation is whether it answers the question a maintainer will ask two years from now.
Architecture decision records for every choice that would be expensive to reverse.
02 / 03
Almost every performance problem we are called into turns out to be somewhere other than where the team was looking. We measure production before we touch anything, and we build the load model from your real traffic shape rather than an average request per second.
No optimisation merged without a before and after figure attached.
Designing for a hundred times your current load is a way of paying today for a future that may not arrive. We design for ten times, and we make sure the step after that is a known, priced piece of work rather than a surprise.
Every architecture we hand over names its next bottleneck explicitly.
Novelty has a carrying cost that lands on whoever is on call. We default to tools with long support windows, deep documentation and a hiring pool in Denmark. When we do reach for something unusual, the decision record has to say what it buys and what it costs.
New technology needs a written case, not enthusiasm.
03 / 03
Big-bang cutovers concentrate all of a project's risk into one weekend, usually the weekend the people who built it are least available. We migrate seam by seam, so that every step ships on its own and every step can be reversed on its own.
No migration plan with an irreversible step in it leaves our hands.
The measure of our work is what your team can do after we leave. That means your conventions rather than ours, pairing instead of hero work, and the deliberate spreading of knowledge even when it slows a sprint down. We write the exit plan in week one and review it at every milestone.
Exit plan agreed before the first line of code.
Monthly rolling contracts, one month notice either way, and no proprietary framework of ours in your codebase. A consultancy that has to be difficult to fire has stopped competing on the work. We would rather be re-hired than retained.
One month notice, both directions, in every contract we write.
The diagnosis is a complete deliverable in its own right — an assessment, a baseline and priced options. If it concludes the work is not worth doing, that is where we stop and say so.
One hour, free
You describe the problem; we ask uncomfortable questions. By the end of it we will tell you honestly whether this is work we are good at — and roughly a third of the time, we point people somewhere else.
One to four weeks, fixed price
We get into the code, the pipeline, the data and the incident history, and take a baseline of the numbers we intend to move. Nothing large gets proposed before this — quotes given without reading the system are guesses with an invoice attached.
A few days
A scope, a price, a named team and an exit plan — all before the work starts. Monthly rolling, one month notice either way. If the diagnosis says the work is not worth doing, we say so and stop here.
Two-week cycles
We ship to production every cycle, working inside your process and your repository. You get a demo, the current numbers against the baseline, and an honest note about anything that is going worse than planned.
Built in from week one
The last stretch of every engagement inverts: your engineers write, ours review. We are finished when your team has shipped a meaningful change without us in the room.
Money, notice periods and what happens when we leave — answered here rather than on a second call.
Diagnosis work is fixed price and typically runs between DKK 60,000 and DKK 180,000 depending on system size. Delivery is billed monthly per engineer at a single day rate — no separate rates for senior people we then do not send. You will have the number in writing before anything starts, and we do not quote large work before reading the system.
For diagnosis and reviews, yes. For build and modernisation work, no — and we will explain why in the first conversation. Fixed-price delivery moves risk onto whoever is worst placed to manage it and rewards defending the scope instead of doing the right thing. We use monthly rolling terms with one month notice, which gives you the same protection with none of that incentive.
That is the default. We use your repository, your board, your conventions and your definition of done. Where we think a practice is holding you back we will make the case for changing it, and then we will do it your way if you disagree.
Deepest in PHP and Laravel, plus TypeScript, PostgreSQL and MySQL, and the usual cloud platforms. We also read and modernise systems in languages we would not choose to start a new project in — that is most of what legacy modernisation is. If it is genuinely outside our range, we will say so in the first call.
Diagnosis work can usually begin within two weeks. Delivery capacity depends on the quarter — we staff engagements from the people who are actually free, and we will tell you honestly when the next real availability is rather than starting late with borrowed time.
Both, deliberately. The team is split between Copenhagen and Odense and works remote-first, but we are on site for the parts that need it — kick-off, event storming, incident reviews and anything where reading a room matters. For Danish clients that is typically a day or two a fortnight; for clients further afield we agree a rhythm up front.
The exit plan written in week one is what happens. The final stretch inverts the working relationship — your engineers write, we review — and we consider ourselves finished when your team has shipped something meaningful without us. After that the phone still works, at no cost for short questions.
An hour on a call, no charge and no deck. We will tell you honestly whether this is work we are good at — and if it is not, who to talk to instead.