Skip to content
Codense
About

Copenhagen. Odense.
Codense.

Codense is Copenhagen and Odense — the two cities our consultants call home, and a reminder that dense, well-condensed code beats more of it.

We started in 2019 after one rewrite too many — the kind that is proposed in a boardroom, priced at eighteen months, and quietly abandoned at fourteen.

Every one of those projects had the same shape. Nobody had measured anything. The system was assumed to be beyond saving because it was old, and old had been confused with broken. The people who knew where the bodies were buried were never in the room.

So Codense is deliberately small and deliberately senior. Two consultants, no bench, no juniors billed at senior rates. One of us in Copenhagen and one in Odense, which is where the name comes from — and, once we noticed the pun, a decent statement of what we think good code is: condensed, not clever.

We take on fewer engagements than we could sell. Turning work down is the only thing that makes the advice worth anything: a firm that needs the contract will always find a reason you need the contract.

Odense 80 min by train · one team Copenhagen
Odense

Where half of Codense works.

Denmark

Copenhagen

And where the other half does.

Denmark

Products we run
4
Built, shipped and on our own pager.
Cities we work from
2
Copenhagen and Odense, as equals.
Senior engineers only
Always
There is nobody behind us to escalate to.
Where the data lives
Europe
European infrastructure, by default.
Why we build

We wanted to be the kind of consultancy that carries a pager.

It is easy to recommend an architecture you will never have to operate. So we started shipping our own products, and we run them ourselves.

See the products

We pay for our own shortcuts

A consultancy can leave before the second year of maintenance arrives. When it is our product, we are still there when the shortcut comes due.

Operating teaches what building cannot

Being on-call for real customers teaches you which alerts matter, which dashboards are theatre, and how a system actually fails at 03:00.

Product revenue funds honesty

We can tell a prospective client their problem is not worth solving yet, instead of taking the work to keep the lights on.

How we scale

Two founders, a network, and no bench.

We do not hire to look bigger. We bring in people we have shipped with before, by name, and we tell you who is doing what.

A network, not a roster

Senior contractors we have delivered alongside — mobile, data, design, security. Brought in for the part they are best at, and told when the part is done.

Distributed by design

Copenhagen and Odense, written communication first, decisions recorded where the work happens. It is how we have always worked, not a policy adopted in 2020.

Clients who stay

Most of our work arrives from people we have worked with before, or the person they told. That is the only sales pipeline we have ever had.

Off the record

Things that are true but not on the invoice.

  • The name

    Copenhagen and Odense, condensed. It also describes how we like code.

  • Founded on a train

    PLACEHOLDER — the first architecture sketch for Detectly was drawn between Odense and Copenhagen.

  • Coffee, measured

    PLACEHOLDER — we monitor six things in production and none of them is the espresso machine. An oversight.

  • Deploys on Friday

    We do them. That is the whole point of the rollback being rehearsed.

  • Kept in Europe

    Every product we run is hosted in the EU. It was a decision, not a default.

  • We will say no

    PLACEHOLDER — roughly one enquiry in four gets told the work is not worth doing yet.

How we work

What we will do, and what we will refuse.

These are not values on a wall. They decide which engagements we take and how they run.

  1. 01

    Quality is a speed decision

    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.

  2. 02

    Measure it or it is an opinion

    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.

  3. 03

    Write it down where it will be found

    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.

  4. 04

    Scale is measured, never assumed

    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.

  5. 05

    Build for the next order of magnitude, not the next three

    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.

  6. 06

    Boring technology, deliberately chosen

    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.

  7. 07

    Change in small, reversible steps

    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.

  8. 08

    Design for the handover from day one

    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.

  9. 09

    Easy to leave, on purpose

    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.

The founders

You meet the people who do the work.

Both of us, every time. No account managers and no bait and switch — the engineers in the first meeting are the engineers on the engagement.

  • $ whoami
mathias · odense · fullstack & infra
$ ssh hetzner-1 docker compose ps
✓app  queue  scheduler  horizon
✓postgres  redis  nginx  certbot
$ psql -c "select count(*) from checks"
a lot · and rising
$ php artisan test --parallel
✓all suites green
$ git push production main
▸build → migrate → swap · 0 downtime
$ tail -f storage/logs/laravel.log
·nothing. as it should be.

    Laravel and PHP, the Docker underneath them, and lately a fairly unreasonable amount of time spent on what AI can and cannot be trusted with in a real codebase. I care most about the part that usually gets skipped: whether the thing you built can be deployed, observed and recovered by someone who was not in the room when it was written.

  • I build the software people actually hold, and I design it before I build it. Native Android and iOS when a product needs the platform underneath it, Flutter or React Native when one codebase is the better trade -- and which of those a project should use is a decision worth making deliberately rather than by habit.

And a network we have shipped with for years

Beyond the two of us there is a network of senior contractors we have shipped with before — mobile, data, design, security. We bring them in by name when a project needs a skill we do not have, and we say so plainly rather than pretending the capability was in-house all along.

Evidence

What that has added up to.

Six years, and the engagements we are allowed to describe.

All cases
SaaS — synthetic monitoring 2026 Ongoing

A monitoring platform that keeps European data in Europe

Six monitoring tools most teams buy separately — uptime, API checks, recorded browser flows, visual regression, sitemap scanning and heartbeats — behind one dashboard, one alert engine and one on-call chain. Built and operated by us, hosted entirely in the EU.

Measured
2026
Tools in one suite
Six
Pages per full-site scan
500
Fastest check interval
60s
Detectly
Example Retail — 400k monthly orders 2025 Nine weeks

A checkout that stopped falling over on campaign days

Peak traffic took checkout down three times in one quarter. We measured where it actually bent, fixed four things, and left the load model behind.

Measured
2025
Checkout p95, before
4.2s
Checkout p95, after
780ms
Peak orders held
2x
Nordic e-commerce group
Say hello

Coffee in Copenhagen or Odense?

We are on site more often than most remote-first firms. If you are in either city, the first conversation can happen in person.

Start a conversation hej@codense.dk
Reply within
One working day
First call
One hour, free
Notice period
One month, either way
Based in
Odense & Copenhagen