01
Architecture is chosen, not copied
No architecture is good or bad in itself. The most expensive mistake we see in inherited projects is having chosen by fashion: microservices for a three-person team, abstraction layers for requirements that don’t exist yet, serverless infrastructure for constant traffic. All of that gets paid for in months of delay and a cloud bill nobody can explain.
We decide with four questions, in this order:
1. How much do the parts of the system talk to each other?
If the different areas of the business are tightly interwoven, everything stays together. Separating what is actually inseparable only adds complexity.
2. Are the requirements really settled?
When the business rules are defined and stable, it pays to isolate the logic from the rest of the system so it survives any change of technology. If you’re still validating the product or iterating every week, that same decision slows you down. Every structure has its moment.
3. How big is the team?
Small team: a single, well-organised system, nothing more. Large team: the same system, but with strictly separated areas inside, so several people can work in parallel without stepping on each other. This step is mandatory before considering splitting anything.
4. Is there a specific bottleneck?
Only when one specific part receives far more traffic than the rest and needs to grow on its own do we extract it and deploy it separately. That’s a scaling decision, not a starting point.
The result of this analysis is yours, whoever comes after us. And we explain it in writing: what was decided, why, and at what point it would make sense to change it.
02
What that means in practice
Starting simple is not starting badly. A well-structured system can grow piece by piece when the business asks for it. What has no cheap fix is having made things complicated from day one.
Automated tests from the start, not at the end. Every change validates itself: when someone touches something that breaks something else, the system warns before it reaches production — not on a Tuesday morning with clients calling.
And explicit error handling. Systems fail: an external API goes down, a payment gets stuck halfway, the network drops. The difference between professional and improvised software is what happens at that moment — whether it recovers, alerts and leaves a trace, or breaks silently.
03
What we build
- Custom web applications and platforms.
- APIs and integrations between systems that don’t talk to each other.
- Backends that hold up under real load.
- Migrations of old systems nobody dares to touch any more.
- Rescues: inherited projects with no documentation, no tests and the original developer nowhere to be found — often over-architected by someone who wanted to use the latest thing.
04
No black boxes
We deliver in increments, not in a single big bang at the end. Every two weeks there’s something working that you can see and try, and from there you decide. If halfway through the business changes priorities, we change — without renegotiating the whole project.
05
The code is yours
Repository, architecture documentation, deployment environment and technical decisions explained. No artificial dependencies, no odd licences, no parts only we know how to touch. If tomorrow you want to take it to your internal team or another provider, you can — and if you do, we’ve done our job well.
06
And we say no when we should
Some projects shouldn’t be custom-built. If what you need already exists, costs €40 a month and works well, we’ll tell you even if it costs us the job. Same with technology: if you ask us for microservices and your team is two people, we’ll explain why that will cost you double and take three times as long.
What you get
Software in production, with tests, documentation and automated deployment. An architecture justified in writing. And a system your team can maintain without depending on us.
Tell us what you need
We’ll tell you how we’d approach it — and if it shouldn’t be custom-built, we’ll tell you that too.