We deliberately keep our engagement count low — a small number of clients at a time, not a portfolio spread thin across a rotation of junior staff and templated output. That only works as a promise if we’re also disciplined about which projects we say yes to. Saying yes to everything and being stretched thin would quietly break the same promise from the other direction. So here’s what we’re actually screening for before we agree to take something on.
Can we tell you what “done” looks like before we start
If a project can’t be described in terms of a decision it needs to support or a problem it needs to solve — if it’s really just “build us an app” with no clearer shape than that — we don’t say no outright, but we do insist on a scoping conversation first, not a straight handoff into build. A project we can’t define the finish line for is a project that’s likely to drift, and drift is expensive for both sides. See our piece on how we scope a build for what that conversation actually looks like.
Does the work match one of our two actual disciplines
We build software (SIC 62012) and we advise on technology (SIC 62020). That’s a deliberately narrow pair of disciplines, not a general “we can build anything” claim. If a request falls well outside both — something that’s really a marketing, staffing, or non-technical operations problem wearing a technical costume — we’ll say so rather than take the work and figure it out as we go. Turning down adjacent work is a smaller cost than doing unfamiliar work badly.
Is there a real decision-maker in the room
Advisory work in particular depends on being able to give a direct recommendation to someone who can act on it. If a client relationship is structured so that recommendations get diluted through several layers of internal politics before they reach a decision, the advisory work stops being useful — not because the advice is wrong, but because nothing changes as a result of it. We ask about this directly before agreeing to fractional or ongoing advisory arrangements.
Would we be comfortable being named as the ones who built it
We hold internal work to the same bar as client work — if we wouldn’t ship something for ourselves, we won’t ship it for you either. Part of evaluating a new engagement is asking honestly whether it’s a project we’d be proud to stand behind once it’s live, technically and otherwise. If the honest answer is no — because of scope, timeline pressure that would force shortcuts, or requirements we’re not confident we can deliver well — that’s a reason to say no up front rather than discover it under deadline pressure.
What this means if you’re evaluating us
If we ask more scoping questions than a typical studio before quoting a project, or push back on a request rather than agreeing to it immediately, that’s this filter working as intended — not friction for its own sake. We’d rather turn down work that’s a bad fit than take it on and let quality slip on something with our name attached.