What you get, and in what steps
The Triple E says what the client gets on every project. The method says in what order it happens and what is delivered at each stage.
The Triple E
Three principles, one delivery promise
The values say how we are internally. The Triple E says what the client gets on every project — and it holds on all three, or it does not hold.
-
Empathy
Empathy
We understand the client's business as if it were ours. We listen to the need, but the technical translation is ours: we show them what they actually need and build it with them.
We listen to the request and hand back what is actually needed.
-
Efficiency
Efficiency
We look after the client's budget as if it were ours. Not the cheapest solution, nor the simplest: the one with the best ratio between what it costs and what it gives back.
What carries a cost has to carry a value.
-
Excellence
Excellence
Quality in what you see and in what you don't. Finished doesn't mean it runs: it means it runs well, securely and at scale — that it can grow without being rebuilt.
Finished means it can take growth.
How we treat people
A project is made by people on both sides
Projects rarely fall over because of the technology. They fall over because someone was not there, was never told, or never got to it in time.
-
The person who sells it is the person who solves it
Whoever is in the first meeting is still there when the system goes into production. The same people carry the project end to end: whoever understands the problem is the one who builds it and the one who answers for it afterwards.
-
One team for as long as the project lasts
Your people and ours work as a single team, towards the same objective and in full view of everyone. And if you would rather hand it over whole, we take it that way: what changes is how involved you are, not how much we tell you.
-
It keeps running without us
Whoever will operate the system takes part while it is being built, rather than meeting it on training day. When the project ends, your team can run it on its own.
-
A team treated well delivers better
People who are comfortable, supported and up for it are not an internal perk: they are the reason the quality of your project does not depend on who gets assigned to it.
How we work
Five stages, five concrete outputs
The client knows which stage they are in and what they get when it ends.
Business problem in Working solution out
-
01
Discovery
A real diagnosis of the business, not a requirements checklist. We understand the problem before proposing anything.
What happens inside
We talk to the people who run the process, not only to whoever signs. We watch the business working: where work comes in, where it gets stuck, what is held together by spreadsheets and memory. Technology comes up last.
What we ask of you
Access to the people who do the work every day, and honesty about what is not working. Tidy documentation is not required: if it existed, the problem would be a different one.
We move on when
The problem fits on one page and you agree with that page. And if the diagnosis says nothing needs to be built, we say so: you keep the map, and the project ends there.
Output A diagnosis and a map of the problem
-
02
Solution design
The diagnosis becomes a technical and commercial proposal, with a defined scope and reasoned decisions.
What happens inside
The diagnosis becomes decisions: what gets built, what gets bought, what stays as it is. Every decision carries its reasoning in writing — including the alternatives we discarded, and why.
What we ask of you
Decisions. This stage produces options with different costs and timelines, and the path is yours to choose. Our job is that you choose informed — not to push you toward the expensive one.
We move on when
There is a scope agreed by both sides: what is in, what is out, and what “finished” means. On a fixed-scope project that means a document agreed before the first line of code; on an agile engagement it is agreed iteration by iteration, on the same criteria. What does not change is that nothing gets built on a “we will see later”.
Output Technical proposal and closed scope
-
03
Development
Iterative construction, with visibility for the client throughout. No black boxes.
What happens inside
Iterative construction with partial deliveries that work: what we show you runs and can be touched — not progress percentages or screenshots. The code and the decisions stay in sight.
What we ask of you
Time from the people who will use the system, to try the deliveries as they come out instead of everything at the end. A deviation caught early is cheap to fix; the same deviation in the final delivery costs the project.
We move on when
What was built covers the scope closed in stage 02 and works in the test environment. Against that list — not against a feeling of “done”.
Output Working partial deliveries
-
04
Rollout
Into production, and verified in the client's own reality — not only in staging.
What happens inside
The solution goes into production with real data and real people: migration, permissions, training for those who will operate it. This is the stage where a good share of providers has already left.
What we ask of you
A project point person on your side with the authority to decide on the spot: without one, every small question stalls the flow and stretches the timeline. And early word of anything odd — the first days in production are information, not a nuisance.
We move on when
The system solves, in production, the problem written on the discovery page. Not when it compiles, not when it demos: when the business uses it and it works.
Output The solution running in production
-
05
Support and evolution
Maintenance, post-project support and continuous improvement as the business changes.
What happens inside
Response times agreed in writing, monitoring, and an improvement plan prioritised by impact and reviewed with you. The solution keeps up with the business as it grows, instead of slowing it down.
What we ask of you
That you tell us when the business changes — a new channel, more volume, a different rule. Knowing early is what keeps the system from falling behind.
And when it ends
It does not end on a date: it lasts as long as the system lives. And if the business has changed enough to need a different architecture, we say that too — before you find out by paying maintenance on something that no longer fits.
Output A support and improvement plan
