When methodology is the loudest answer to "how do you work,"
The discipline that shows up under pressure is the actual answer.
Our working principles, the universal engagement cadence, and the disciplines that show up across every Solution, Engagement Model, and Industry we deliver.
Solutions, Engagement Models, and Industries describe what / how / who. This page describes what stays constant under pressure.
Not values copy. Each principle has a concrete operational consequence — something we do or don't do, that you can hold us to.
We design the operating model — workflows, ownership, audit-trail expectations, integration spine — before any module gets configured. The configuration is the last decision, not the first.
What this gives you: a system the business actually operates in, not a vendor's demo flow with your data poured in.
Runbooks are written during the build, not after the first incident. ADRs (Architecture Decision Records) ship in the same pull-request stream as the code that depends on them. The decision-audit phase on every migration delivers a costed options memo before scope is set.
What this gives you: the system stays knowable after the original engineer leaves.
Where an engagement includes launch or go-live, stabilisation is treated as part of the work, not an afterthought. The 6 to 12 weeks after go-live are funded, scoped, and staffed from day one. For advisory, rescue, or long-term-support work, the equivalent discipline is handover maturity, runbook completeness, or operating cadence — same principle, different shape.
What this gives you: go-live is the start of stabilisation, not the end of the engagement.
The first call is a fit assessment, not a sales call. If your engagement shape doesn't match what we deliver, we will tell you and recommend the path that does. Sometimes the right answer is "we are not the right partner for this."
What this gives you: the proposal — if there is one — reflects the operation, not the contract size.
Pair sessions, shadowing, runbook drills. The internal team operates the system in production before our team leaves. Knowledge coverage is greater than one engineer per subsystem at handoff.
What this gives you: the day the delivery team leaves is not a risk event.
We are not an EMR/EHR replacement. We are not an MES/SCADA replacement. We do not run aviation MROs, FBOs, or charter operations. Where certification (SOC 2, GxP, 21 CFR Part 11, FAA-jurisdictional rules) belongs to the client's operating environment, we design the supporting controls and evidence paths rather than claiming the certification ourselves. The boundary is the boundary; we say it out loud.
What this gives you: no surprise discovery in week eight that the engagement was scoped on a misunderstanding.
Not the configuration, not the integration, not the launch. The deliverable is confident internal ownership at year three. Every engagement structure — Implementation, Long-Term Support, Modernization, Dedicated Teams, System Rescue — is shaped around that.
What this gives you: a system that still works on year three, owned by your team, not dependent on ours.
The methodology is rarely the differentiator. The discipline that shows up under pressure is.
Regardless of whether the engagement is an Implementation, a Modernization, a System Rescue, a Dedicated Team rollout, or a Long-Term Support handover, the underlying cadence is the same.
No fixed-price delivery proposal before the operating reality has been mapped. Audit-first on rescues. Decision-audit-first on migrations. Operational mapping first on implementations.
Phases close when the business is ready, not when the project schedule wants them to. Stabilisation is funded in the original engagement, not as a phase-two negotiation.
Pair sessions, shadowing, runbook drills. The internal team operates the system before our team rotates off.
Quarterly reviews, version-upgrade routine, optimisation backlog. If the engagement transitions to Long-Term Support, the discipline continues without a re-onboarding.
Each Engagement Model carries a named discipline layer documented on its own page. Read together, they form the firm's discipline floor — the part of every engagement that is not up for negotiation.
Stabilisation scoped from day one. Runbooks during build. ADRs versioned with code. Phase-2 placeholder. Adoption measurement.
Open Implementation Long-Term SupportQuarterly optimisation cadence. Version-upgrade routine. Test coverage maintained. Data-quality monitoring. Access-control reviews. Strategic review with leadership.
Open Long-Term Support Modernization & MigrationDecision audit as deliverable. Modernization roadmap with retire / refactor / carry tags. Parallel running where practical. Rollback or contingency per phase. Reporting continuity verified pre-cutover.
Open Modernization Dedicated TeamsSelection for fit. Structured onboarding. Shared backlog and standup. Shared code review. Engineering management on our side. Retention designed in.
Open Dedicated Teams System RescueForensic audit before structural change. Triage before stabilisation. Targeted stabilisation. Knowledge reconstruction as deliverable. Decision-support assessment in writing. No forced follow-on.
Open System RescueThe scope, the timeline, the team — those are scoped per engagement. The discipline floor is the same.
Six commitments. Each phrased as "we will" or "we will not." These show up in writing on every engagement, not just on this page.
tell you honestly whether we're the right partner. Sometimes the answer is no. We will say so.
promise outcomes the engagement scope doesn't support. "We will design for X" is not "we guarantee X." We hold ourselves to that distinction in every proposal.
fund stabilisation in the original engagement. Not as a phase-two negotiation, not as a change order. The 6 to 12 weeks after go-live are scoped from day one on every Implementation engagement.
write runbooks and ADRs during the build, not after. The documentation is a deliverable, not an afterthought.
bundle a System Rescue audit into a forced rebuild quote. The audit is the audit. Any follow-on engagement is your choice and is quoted separately.
name the boundaries. What we deliver and what we don't. The Industries pages, the Solutions pages, and the Engagement Model pages each say what's out of scope. We hold that line.
Good work is collaborative, not performative. These expectations exist so both teams can make decisions clearly — not as a gate, as a shared operating baseline.
Implementation engagements without a named internal owner drift after handoff. We will ask about this in the first call.
"Cheapest delivery for the launch date" is a different engagement than the one we run. We are honest about that in scoping.
Quarterly reviews on Long-Term Support, decision-audit participation on Modernization, audit-period participation on System Rescue — these need internal time, not just our time.
Especially on System Rescue and Modernization. The audit is more accurate when the operation tells us what it already knows.
If we recommend a path you don't want to take, the conversation is "let's understand why" — not "do what the client wants." We are not a body-shop; the recommendation is part of the engagement.
The disciplines on this page were built where we run our own production: Deploy Monkey, Timenzo, and our internal Odoo operations.
Used internally on a quarterly rhythm; same cadence we sell on Long-Term Support engagements.
Internal Odoo and supporting platforms upgrade routinely; the same cadence is what we operate on client systems under support.
Our internal engineering is organised by domain rather than by project, so engineers go deep on a domain over years. The same model is what we offer as Dedicated Teams.
Internal system changes require a runbook the operating team has exercised, not just received. Same expectation on Implementation engagements.
This isn't dogfooding for show. It's how we built the discipline that the rest of the site describes. Where any of these is still being formalised rather than mature, we say so on the engagement-specific page — not here on the firm operating manifesto.
ERP Systems, AI & Automation, Cloud & DevOps, Integrations & Data, Custom Applications, Experience & Commerce Platforms.
Open Solutions If you know how you want to work with usImplementation, Long-Term Support, Modernization & Migration, Dedicated Teams, System Rescue.
Open Engagement Models If you want to see where we've deliveredManufacturing & Industrial, Retail & Commerce, Healthcare & Life Sciences, SaaS & Technology, Professional Services, Aviation & Specialised Operations.
Open IndustriesA fit-first conversation is the right next step when you want the operating discipline above as part of the engagement (not just the deliverable), you're willing to invest time on the discovery / audit / decision phase before scope is set, you have or can name an internal owner who will inherit the system, and you want a partner who tells you "no" when no is the right answer.
A different partner is probably the better fit if you want the cheapest delivery for the launch date with no stabilisation funding, you want a methodology-name as the answer to "how do you work," you want a fixed-price quote before discovery, or you want a vendor who agrees with every leadership decision regardless of operating reality.
We use the practices from those methodologies that survive contact with a real production operation — short cycles, written decisions, clear ownership, demos against operating reality. We do not "sell" the methodology name. Methodology is a tool, not an outcome.
The first call doesn't end with a proposal. It ends with a shared understanding of whether the engagement shape we deliver matches the operation you're trying to build. Sometimes the recommendation is a different engagement model. Sometimes it's "we are not the right partner — here's who might be."
Engagement Models describe the commercial shape of working with us — Implementation, Long-Term Support, Modernization & Migration, Dedicated Teams, System Rescue — what's contracted, what's delivered, what the timeline looks like. This page describes the discipline that runs underneath every engagement model, regardless of which one you pick.
We do not give fixed-price delivery proposals before understanding the operating reality — a fixed price quoted before discovery is either padded against unknown risk (you pay more than necessary) or under-scoped (the engagement becomes change-order driven). Fixed-scope diagnostics or audits may be offered separately (a System Rescue forensic audit, for example, is fixed-price). Decision audit first, scope second, delivery price third.
The 6 to 12 weeks after go-live are scoped, funded, and staffed in the original engagement. Adoption, defect resolution, reporting confidence, and process refinement happen on our time, not as change orders. Stabilisation is the part of the engagement where the system earns trust.
The engagement is designed to absorb scope change deliberately — through documented decisions, not through scope creep. Phase-2 architecture room is reserved during Phase 1 on Implementation engagements. Quarterly reviews on Long-Term Support are the cadence for evolving scope. The discipline is deliberate change, not no change.
No. This page describes principles. Concrete ranges (engagement length, team size, pricing) live on the Engagement Model pages where they belong.
No pitch in the first call. We'll tell you honestly whether we're the right partner.