The people who build your system — and who will still know it in five years.

Why we stay small — and why you benefit from it

There is a pattern in this industry that almost every client has run into. An experienced architect sits in the pitch and asks the right questions. After the signature, a team takes over that the architect never sees again. The experience you paid for was in sales. It is not in the project.

That break does not happen here, because the structure that produces it does not exist. Whoever talks to you writes the code later or owns the architecture. It is the one commitment a small team can keep and a large one can barely make.

The second point is time. A system we build, we then look after for years. That only works if the people stay. Our two founders have been here since 2012 — the same people who built LingoHub and still run it today. So we know from experience what it means to explain a year-six architecture decision in year eleven.

The third point is less comfortable. A small team cannot do everything. We do not take on work that needs three parallel development tracks over a year, and we decline when a project has to start at a time when we have no capacity. That costs us work regularly. It is still a better commitment than a team assembled after the signature.

What that means for day-to-day work

Short paths. You do not write to a mailbox, you write to a person. Questions about architecture, operations or an invoice reach someone who can answer them without checking internally.

Less lost in translation. In larger setups a requirement travels from the client to a project manager, from there into a ticket, from there to a developer who never heard the business background. Every stop costs precision. We have fewer stops.

Responsibility you can point at. When a system goes down at night, there is no question here about who is responsible. That is why we treat operations as a service in its own right and not as an appendix to the project — see Run and evolve.

Limits we say out loud. When a project needs more capacity than we have, we say so in the first conversation — not in month three.

How we hire

We hire rarely, and then for a long time. We are less interested in how many technologies someone can list than in whether someone wants to take over a system and still own it six months later. Anyone who starts here works on code that runs in production from the first month and speaks to clients directly from the first quarter.

If that interests you: our open positions, and what we explicitly do not offer, are on the careers page.