Software architecture
Architecture that holds up under load, under a team, over time.
Architecture design, stack selection and technical standards, then hands-on support for your teams all the way to production.
Who this is for
This engagement helps if you are:
- A founder or CTO who has to lay the foundations of a new product
- A company starting a rebuild and determined not to repeat the mistakes of v1
- A fast-growing team whose practices diverge from one developer to the next
- An organisation whose product must open up to new channels: mobile, machines, partner APIs
The warning signs
You recognise at least one of these symptoms:
- Every new feature costs more than the last one
- Two developers solve the same problem in two different ways
- Nobody can say where a new business rule belongs
- Structural technical decisions are written down nowhere
- Frontend and backend keep handing the same bugs back to each other
- You need to plug in a new client (mobile, machine, partner) and nothing was designed for it
- Build and deploy times make iteration painful
These are architecture symptoms, not code symptoms. Fixing them line by line will not be enough.
What I actually do
I work with your teams, not alongside them. The engagement runs in five stages.
1. Understand the business before the technology
- Workshops with the product and business teams
- Mapping the journeys and the rules that genuinely matter
- Identifying the non-negotiable constraints: regulatory, real-time, offline operation
2. Map what already exists
- Reading the code and the data schemas
- Spotting coupling and high-risk areas
- Measuring what costs you: build, tests, deployment
3. Define the target architecture
- Splitting into domains and responsibilities
- Stack choices argued in writing, alternatives included
- API contracts and data strategy
- Decisions recorded as ADRs, reviewed with the team
4. Equip the team
- Frontend standards: component-first, hooks, state management
- A shared design system or component library
- Continuous integration pipeline, code quality and reviews
5. Support the implementation
- Pair programming on the first structural modules
- Rolling architecture reviews
- Adjusting the target as reality pushes back
What you get
Documents your team can actually use, not a report that gathers dust in a Drive folder.
Everything is versioned in your repository, in French or English.
The architecture diagram
- An overview of components and how they exchange data
- Domain boundaries and responsibilities
- Critical data flows, degraded cases included
The technical decisions
- One ADR per structural decision
- Alternatives considered and why they lost
- Consequences accepted and triggers for revisiting
The team standards
- Code conventions and project structure
- A reference component and hook
- A code review checklist
The roadmap
- Work sequenced by dependency and by risk
- Effort estimates per batch
- What we are not doing, and why
The goal stays the same: the team can carry on without me.
How I work
No architecture in a vacuum
An architecture is only worth what the team carrying it can sustain. I start from your actual skills, budget and calendar, not from a textbook diagram.
As few layers as possible
Every abstraction is paid for in comprehension. I add one only once the cost of its absence is demonstrated, not anticipated.
Written down, therefore debatable
An undocumented decision gets re-argued every three months. ADRs are not bureaucracy: they are what lets a newcomer understand why the system is the way it is.
- The context at the time of the decision
- The options ruled out
- What should make us change our minds
Code, not just diagrams
I implement the first structural modules with the team. It is the only way to verify that an architecture works, and the only honest way to hand it over.
What changes
By the end of the engagement:
- The team knows where a new feature goes without half a day of debate
- Structural decisions are written down and can be held to account
- Technical choices match the budget and the skills actually in place
- You can hire or promote someone without starting from scratch
And you stay in control: none of it depends on my being there.
Frequently asked questions
How is this different from the stack audit?
The audit starts from what exists and produces a prioritised diagnosis. Architecture work starts from the target: we design the system to be built or rebuilt, then support its implementation. The two often follow on from each other.
How long does an architecture engagement last?
Initial scoping takes two to four weeks. Implementation support then spreads over several months part-time, often one or two days a week.
Do you work on-site or remotely?
Both. Scoping workshops benefit from being on-site, in the Paris area. The rest of the engagement runs perfectly well remotely, as it does today with teams spread across three countries.
Do you impose a particular stack?
No. My home ground is TypeScript, React, Next.js and Node, but I have also shipped in C#, Flutter, VB.NET and Symfony. The right choice depends on your constraints and your team, not on my preferences.
Do you work on systems that drive hardware?
Yes, that is my day-to-day right now: architecting a machine + cloud + applications ecosystem, with MQTT, offline state handling and degraded modes. I have also worked on kiosks and Raspberry Pi embedded systems.
What if my team disagrees with your choices?
All the better: it means they are taking ownership. ADRs exist to make disagreement explicit and documented. A decision imposed that nobody understands never survives the consultant’s departure.
Let’s talk about your architecture
- A 30-minute call to understand your context.
- Then a written, costed scoping proposal.