About Roy Berris

What I do

The business knows what it means, and the software has to match that exactly. My job is to close that gap, in both directions. I do that in three ways:

• // Design

  Solution design for clients, from scoping and estimates to advice on technology choices.

• // Lead

  Guiding development teams as a tech lead, with reviews and shared standards.

• // Build

  Still hands-on, mostly in .NET and Next.js.

I approach every system with solution architecture and Domain-Driven Design (DDD). Cloud and AI tooling I work with from the architecture side: I decide how they fit together. The systems I work on:

• Websites & CMS platforms
• Integrations & APIs
• Legacy modernization
• Custom business apps

How I work

I started tinkering with computers as a kid and never stopped. I still want to know how something works before I trust it.

I ask "why" a lot, I say what I think, and I keep it short. I'm pragmatic: a design that ships and holds up beats a perfect one on paper. And I like teaching, because explaining a decision is the best test of whether I understand it.

What I stand for

I'm relaxed about most things. These are the few I'm strict about.

Truth lives in one place

The business confirms one description of the domain, and everything technical is derived from it. A problem found further down goes back up to be decided there, never patched below.

Evidence is not a specification

A sketch is not the truth, and what a system does today is not automatically what it should do. I don't invent names for things the business hasn't named.

Precise language

Vague words turn into vague code. I once opened a pull request only to fix one wrong word in an ADR. The part the business confirms stays in their language, often Dutch.

Clean boundaries

An external system gets no bounded context of its own, a legacy landscape is described from the outside, and dependencies run one way.

Reliable AI, not only fast AI

I use AI agents a lot, with guardrails. The agent that just wrote something is the worst one to check it, so every step gets a fresh one.

Someone lives with the decision

A decision isn't done when it merges. I think about the teams that consume a contract and write the consequences down in an ADR.

Speaking and writing

I speak about this work at events like DF23, the Dutch Umbraco community conference, and Umbraco Community Day 2023. All my sessions are on Sessionize.

Berris.dev is where I write it down. It's a mapped database rather than a classic blog: every post is a node, grouped into clusters. Browse the map or the index. I use AI as a writing partner, not a ghostwriter, and I own every technical claim. More on that in AI-Assisted Blogging.