What we say no to (and why saying no is the service)
Three gates every engagement passes before we take it: it has to be expressible as code, it has to reach production in the window, and it has to be in our domain.
What we say no to (and why saying no is the service)
Most firms will take your money for almost anything. The pitch deck says "full service," the scope is whatever you describe, and the disqualifying questions never get asked because the goal is to close. The trouble shows up later, when the team that said yes to everything turns out to be the right team for none of it.
We run a narrow practice on purpose, and the first thing we do with an inbound engagement is try to talk ourselves out of it. Not as theater — as the actual service. Telling you fast and straight that we're the wrong team is more valuable than a slow, expensive discovery that arrives at the same answer after you've spent the budget.
There are three gates.
Gate one: can it be expressed as code?
We don't take engagements where the infrastructure can't be infrastructure-as-code. This isn't dogma for its own sake; it's the foundation everything else depends on. If the environment is a hand-built server that someone configured by hand years ago and nobody can reproduce, we can't give you the things we're actually good at — pipelines that don't drift, environments you can rebuild, changes that get reviewed before they ship. We can help you get to a place where the infrastructure is code. But if the engagement is "keep operating this irreproducible thing by hand," that's not us, and we'll say so.
Gate two: can it reach production in the window?
We don't take work that can't reach production inside the engagement window. A proof of concept that's designed to stay a proof of concept is a different business than ours. We've seen too many AI pilots and cloud migrations that were structured, from the start, never to ship — endless discovery, perpetual "phase one," a demo that impresses and then sits. If the shape of the engagement doesn't have a real production cutover in it, the engagement is theater, and we're not interested in being well-paid set dressing.
Gate three: is it in our domain?
We do cloud architecture, production AI, full-stack and mobile delivery, and the technical lead role on multi-vendor programs. If your work touches AWS, AI, mobile, or a complex multi-vendor program, we're probably a fit. If it's squarely in a domain we don't practice, the honest move is to tell you that and, where we can, point you somewhere better. A firm that claims everything is in its domain is telling you it has no domain.
Why the gates protect you, not us
It's tempting to read disqualification as the firm protecting its own time. It does that, but that's not the point. The gates protect you. Every engagement we take seriously is one we're not splitting attention away from to babysit work we should have declined. The narrow practice is what makes the senior delivery real — the Cloud Architect can actually be on every engagement because there aren't forty of them, half mismatched to the team.
There's a line we use: we take a narrow set of engagements seriously over a wide set of pitches. The gates are how we keep that promise. When you write to us, you'll get a straight answer about whether we're the right team, fast — and if the answer is no, you'll have saved a discovery cycle finding out.
The willingness to say no is not a limitation on the service. On a serious technical program, it is the service.
Want a straight answer on whether we're the right team? Start a conversation.