01 / 06
Discipline
Software Design & Development
We design a system before we build it, then build it and stay on to run it. Design here means deciding what the system is made of, how its parts are allowed to depend on each other, what happens when one of them fails, and how the data is shaped. Those decisions are expensive to change later and cheap to make carefully now.
Planning is not sold separately from building. Whoever designs it is accountable for it working.
Approach
How we approach it.
The domain model is the system
Most of what a system costs over its life is decided in the data model. Get the entities and relationships right and features fall out of them. Get them wrong and every later feature pays a tax in workarounds nobody can explain.
Our largest platform runs a domain model 253 entities deep across eleven functional areas. A model that size stays workable only because the boundaries inside it are explicit and enforced.
Boundaries enforced at build time
An architecture is only real if violating it fails something. Documented layering that relies on everyone remembering it gets violated, usually by a careful person under deadline, and found six months later.
On our own platform, architecture tests run as one of three suites. Dependency rules are enforced at build time, so an illegal reference breaks the build rather than the design. It costs about a day to set up.
Microservices are not our default
Distributed architecture buys independent deployment and scaling, and charges for it daily in network failure modes, distributed transactions, observability, and the load of understanding a system nobody can run on one machine.
We default to a well-bounded monolith with the boundaries enforced as above, splitting services out where there is a specific reason: a different scaling profile, a hard isolation requirement, or a component with its own release cadence.
Stack matched to how long the system has to live
.NET 8 and 9 with SQL Server or Postgres for systems carrying operational weight. Software that runs a business for a decade needs long support horizons, a strong type system and a hiring pool that will still exist.
React or SvelteKit with Supabase where the system is lighter, the domain is simpler, and time to market matters more than depth. The list is short deliberately.
Decisions get written down
Significant architectural choices are recorded: what we chose, what the alternatives were, why. Two or three options weighed, one taken, reasoning kept.
In eighteen months, when someone asks why the tenancy works this way, the answer exists rather than being reconstructed by whoever is still here.
Where we stop
We are not a design studio. We build interfaces that hold up under real use, and where an engagement needs brand and visual design work at depth, that belongs with someone who does it all day.
Stack
What actually runs in production.
.NET 8
.NET 9
Blazor Server
Entity Framework Core
SQL Server
Postgres
Row-level security
SQLite
Redis
CQRS
Vertical-slice architecture
React
React Native
SvelteKit
Vite
Supabase
Docker
Kafka
GitHub Actions
Engagements
Typical shapes this takes.
A new system
Discovery and solution design first, then build in sprints with something working at the end of each. Duration depends on the domain, which is why we assess before we quote.
A platform extension
A new functional area inside a system that already exists, where most of the work is fitting it to the existing model without damaging it.
Replacing one part
Swapping out a component while the system keeps running, in pieces, with both alive during the transition.
Deliverables
What you get.
A written solution design
Domain model, boundaries, tenancy strategy, failure modes.
Decision records
The choices that would otherwise be forgotten, with the reasoning.
Working software each sprint
Something you can use, not a report about something you cannot.
Testable acceptance criteria
And a UAT round your own people run, with written sign-off.
A codebase inheritance document
What it does, how to run it, how to deploy it, known gotchas.
Ownership
Code, data and accounts are yours as work product from the first commit.
Reading
Related reading.
The strongest seams here are the domain-model argument, the case against microservices, and architecture tests enforced at build time. Those pieces will be linked here as they are published.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·