We look wide to act precisely.
What guides every intervention.
- 01The relief rule
We never treat a project as flat.
The starting point can be very precise. But before stepping in, we look at what it touches around it: uses, teams, data, tools, organisation, business and technical constraints. A choice made in one place can have consequences elsewhere — our job is to see it first.
- 02The trajectory
A project is a step, not a parenthesis.
What is put in place today becomes part of what exists and the starting point for what follows. We look at what the project must solve now, and what it should enable, ease or avoid constraining tomorrow.
- 03The right place, the right level
Seeing the whole relief doesn't mean treating everything.
Depending on the context, the right answer can be to build more, simplify, reconnect, rebuild — or digitise nothing more. Not everything that can be digitised should be: some steps are better left human.
Three questions before building.
Not three steps: three questions. Depending on the answers, we keep almost everything, link a few pieces, or start again on a new foundation.
Conserving doesn't mean keeping everything that's in production. A system can work technically and still serve the business badly.
Connecting doesn't only mean building an API. It means restoring coherence between tools, domains, teams or flows that must work together.
Constructing remains essential, but it's not the default answer. We build when a tool, a layer or a rebuild is genuinely needed.
We shed light. You decide.
- Decision support
- Scoping & project ownership
- Design
- Delivery
- Integration
- Evolution
You can come in through any door, and leave after a single step if that's what makes sense.
Two readings of the project, one continuity.
Vincent.
Vincent steps in where a project must be read, clarified and scoped before it starts. His background spans project ownership support, complex project management, client relations and offer design.
His role is to make the stakes readable, the decisions coherent and the course sustainable, so the project moves forward without getting lost.
- Project management
- Project ownership
- Digital strategy
- Client direction
- Process & methods
Dorian.
Dorian steps in where an intention must become a solution. Full-stack development, software architecture, performance, deployment: he masters the technical chain from prototype to production.
His role is to make choices reliable, coherent and durable, so that technology supports the project and never becomes a breaking point.
- Full-stack
- Software architecture
- React / Next.js
- Node.js
- DevOps
- Performance
What we won't do, even when it would be easier to sell.
Recommend a technology because it's easier or more profitable for us to sell.
Add a tool without understanding what already exists and what it will touch.
Push a complete rebuild when what exists can credibly be kept or improved.
Build a feature that an existing tool already covers properly.
Create technical lock-in or an artificial dependency on us.
Limit our recommendation to what we can sell: if the key lever lies elsewhere, we say so.
These guardrails don't make us dogmatic. An already-scoped project, a standard or a SaaS can be the right answer — we deliver those too.
Don't close a door you'll need to reopen.
Being able to take back control, change provider, leave a solution.
Quality data that belongs to you and flows where it should.
Code and documentation that people other than us can take over.
Your accounts, domains and tools stay in your name.
No technology is dogma: open source is often preferable, but a proprietary solution can be the best answer when its value remains consistent with the dependency it creates.
See these principles applied
Let's talk about your project, before you decide.
Whether it's already scoped or still unclear, the starting point is the same: understanding what it touches.
Start the conversation