Ten operating principles. The work we'll take. The work we'll turn down. The commitments every engagement runs on — published, not hidden behind sales conversations. If you can read this page, you've read most of the contract.
A BridgeOne partner stays on every engagement from the first conversation to the end of the operating phase. The people who promise the architecture are the people writing the code. No "delivery team you've never met" handover. No retainer-driven roadmap drift. Same names on the invoice, the standup, and the on-call rotation.
This is the load-bearing principle. Everything else on this page exists to support it.
Roughly one in three Scope engagements ends with us telling the client not to build the thing — at least not yet, not like that, or not with us. We still hand over the Scope memo. That's the deal we struck when we agreed to the Scope fee, and it's the deal we'll keep regardless of which direction the recommendation goes.
Why this matters: the alternative is sandbagging — recommending the work we want to do rather than the work the client should do. We've watched too many consultancies do that. We won't.
Our engagement structures and rate cards are on the How we work page and available in detail on request without an NDA. If the maths doesn't fit your budget on the page, it won't fit behind a sales call either — and we'd rather you find that out before we both spend a week on a discovery process.
We don't believe price-anchoring through artificial scarcity is consistent with the rest of how we operate.
"The demo worked" is not production. "It passed UAT in a sandbox" is not production. "It's running" without observability or evals isn't production either — it's just running. Production at BridgeOne means: continuously evaluated against an agreed shipping definition, observably failing-loud rather than silently, and reversible if it goes wrong.
If we can't commit to those three properties by go-live, we say so before go-live. Not after.
We aim to have your team own the system within twelve months, ideally less. No auto-renewing retainers. No engineered dependency on us. The Operate retainer ends when your team can run the system without us — and we tell you when we think that point has been reached, even if you'd rather we stayed.
If we've done our job, we've made ourselves unnecessary for that particular system. We are completely fine with that.
If a case study is on the What we ship page, we shipped it. Names are sometimes anonymised; outcomes are sometimes summarised; references are sometimes under NDA. But the engagement is real, the partner involved is named, and the underlying contract exists.
What this looks like in practice: our case studies page has three entries today. It'll have more next year. It won't have ten by Friday because that's not how this works.
Anything we'd hand over at the end of the engagement is written as we go. Architecture decisions, model cards, eval frameworks, runbooks — all in the client's repos, all maintained in the open within the engagement. No black-box deliverable handed over at the end like a stage-managed reveal.
Before Build starts, we agree a cost envelope and the conditions under which it changes. Every week during Build, you get a written burn report: hours spent, hours remaining, risks tracked, scope changes flagged. You should never be surprised by an invoice.
If we forecast the envelope wrong, we say so as soon as we know — not when it's already breached.
During Operate, every quarter, we send a written review covering: what's running, what's changed, what's at risk, and what we'd recommend doing next. It's three to five pages. It goes to the client sponsor and the operating team. It says the uncomfortable things, in writing, on a predictable cadence.
If something's going wrong, you'll know from us before you know from the system.
The entire firm exists to close the gap between "this is what you should do" and "this is what's now running." Strategy that doesn't get built is one of the most expensive things a company can buy. We don't sell that. We sell the strategy and the system that came out of it, by the same team, with our names on both.
This is the whole pitch. Everything above is detail.
Published in advance so we don't waste anyone's time. None of these are absolute, but they're all signals — if the work falls into one of these categories, we'll probably say no, and we'll tell you why.
If the brief is strategy without implementation appetite, we're the wrong firm. We're not a deck-shop. Talk to McKinsey or BCG.
Pilots designed to satisfy a board meeting and not to reach production are exactly the work we exist to push back on. We'll say no, kindly.
We'll diagnose the data problem honestly. If the foundation isn't there, we'll recommend the foundation work first — even though it's not as glamorous to sell.
If we're being brought in to embarrass internal IT, we'll decline. The internal team has to live with the system after we leave. We work with them, not over them.
If the use case violates basic professional ethics — surveillance overreach, decision systems without human accountability, deceptive automation — we'll say no. We'd rather lose the engagement than help with that.