We turn down more chain-infrastructure work than we take on. Not because the work isn't interesting — it's usually the most interesting work on our plate — but because the failure modes in this category are asymmetric. A bug in a marketing site costs you an afternoon. A bug in a contract holding real value can cost someone their savings, and no amount of "we'll patch it in the next release" fixes that after the fact. So before we scope anything that touches mainnet, we run through the same short list.
Is the threat model written down anywhere?
Not a pitch deck slide that says "security first" — an actual document describing who the adversaries are, what they can do if the contract has a bug, and what happens if a key is compromised. If it doesn't exist, writing it is the first engagement, before any Solidity gets written. Skipping this step is the single most common reason chain projects end up needing an incident post-mortem instead of a changelog entry.
Does the team understand what they're outsourcing?
We've seen founders hand off "the smart contract" the same way they'd hand off a marketing landing page — fire and forget. That doesn't work here. We want a technical counterpart on the client side who reviews what we build, asks uncomfortable questions, and is still around after launch. Infrastructure that nobody in-house understands is infrastructure nobody can safely operate under pressure.
Is there budget for an external audit?
We write code we're confident in, and we still don't consider our own review sufficient before anything meaningful goes to mainnet. If a project's budget has no room for a third-party audit, that's a signal the timeline is being set by something other than the actual risk — usually a fundraising deadline — and we'll say so before we start.
Is the chain choice actually justified?
A surprising number of projects reach for a chain because it's trending, not because the trust model fits the problem. Part of scoping, for us, is pressure-testing that choice: does this need a public chain at all, does it need the specific chain being proposed, and does the team understand the tradeoffs (finality time, gas cost stability, tooling maturity) they're accepting.
What we actually deliver
When an engagement clears that bar, it typically includes: a written threat model, contracts built with a test suite that tries to break them (not just confirm the happy path), a staged rollout (testnet → limited mainnet → full mainnet), and documentation a new engineer on the client's team could actually operate from — not just code comments only we understand.
If your project isn't there yet, that's fine — tell us where you are and we'll tell you honestly whether we're a fit yet, or what needs to happen first.