Matthias Desard
Software architect and developer
I take on architecture and development work through Sater bv, from Wolfsdonk in Belgium — on the JVM, in the cloud, and increasingly around AI. Mostly for teams who would rather own their system than rent it.
Summary
- Building software for
- 11 years
- Works in
- Java 25, Spring Boot 4.1, AWS
- Also runs
- Self-hosted models, on my own hardware
- In production now
- 3 systems Hippovibe, Let’s Peppol, Glaswas Verelst
- You work with
- One person, start to finish
- Answers within
- 2 working days
- Available
- Yes, for new engagements
Three things, done properly.
-
Architecture and backend
Service boundaries, data models, and the Java and Spring code that implements them. I take the engagements where the design and the delivery are the same person’s problem — because that is where the two stop disagreeing with each other.
-
Cloud and delivery
AWS infrastructure as code, build pipelines, and static-first web that costs cents a month to run. What I hand over is something your team can operate and read, not a black box with my name on it.
-
AI that runs on your hardware
Agents, retrieval and model serving you host yourself, on hardware you already own. I build and run this for myself first, so what I tell you about latency, VRAM and what a local model can actually do comes from operating it rather than reading about it.
Things I have built.
All work-
Hippovibe
Equestrian management SaaS — eight Spring Boot services, a web app and a mobile client, in production since 2016.
Client work
2016 — now
-
Let’s Peppol
Open-source, NLnet-funded infrastructure giving Belgian companies free access to the Peppol e-invoicing network.
Open source
2025 — now
-
Glaswas Verelst
A Webflow site rebuilt as a static Astro build on S3 and CloudFront — faster, indexable, and no monthly platform fee.
Client work
2026
No surprises, in either direction.
- One person, start to finish
- You talk to the person writing the code. Nothing is handed to a delivery team you never meet, and nothing gets lost between the estimate and the commit.
- Boring where it counts
- Long-term support runtimes, the standard library before a dependency, and a plain deployment you can debug at 2am. I save the interesting choices for the parts of the system that are actually interesting.
- You own the result
- Your repository, your cloud account, your domain. Documented as it is built, so ending the engagement is a decision rather than a rescue operation.
Have something that needs building?
Tell me what you are building and what is in the way. If it is not a good fit, I will say so and point you somewhere better.