The Blockchain Project Brief Template

A clear project brief dramatically improves the quality of developer proposals you receive, reduces misunderstandings, and gives you a baseline for evaluating quotes. This template covers everything a development team needs to scope your project accurately.

1. Project Overview (1 paragraph)

Describe what you're building in plain language. What does it do? For whom? What problem does it solve? Example: 'A lending protocol where users can deposit stablecoins to earn yield and borrow ETH against their stablecoin collateral, without KYC, on Arbitrum.'

2. Core User Flows (step-by-step)

List the 3–5 most important user actions. Each flow should describe: who initiates it, what they do, what happens on-chain, what happens off-chain, and what the user sees. Example flow: User connects wallet → deposits USDC → smart contract mints aUSDC representing their share → user sees balance update → user can withdraw USDC + interest at any time.

3. On-Chain vs Off-Chain Components

List everything that must be a smart contract, and everything that can be a server or database. On-chain: lending pool contract, interest rate model, collateral registry. Off-chain: frontend UI, price feed aggregation service, analytics database, user notifications.

4. Integrations Required

List every external protocol or service you need to integrate. Chainlink price feeds (ETH/USDC). Uniswap v3 for liquidations. The Graph for historical position data. WalletConnect for wallet connections. Each integration adds scope — be explicit.

5. Target Chain

State the chain explicitly. Include why you chose it. This determines what developer experience is required. Example: 'Arbitrum One. We chose it because our target users are already active in Arbitrum DeFi, and we need the liquidity ecosystem.'

6. Security Requirements

Does the contract need to be audited (yes — always)? What level of audit? Which firms do you want? Bug bounty program? Formal verification? State your requirements, not your desired cost. The security requirements should be non-negotiable.

7. Timeline and Milestones

Ideal launch date. Hard deadlines (funding milestones, partnership commitments). Key milestone dates. Note: be honest about flexibility — aggressive timelines often produce worse outcomes than reasonable ones.

8. Budget Range

State a range, not a fixed number. Development: $X–$Y. Audit: separate budget of $Z. Don't hide your budget — it wastes time for everyone. If your budget is too small for your scope, you'll find out faster and can adjust the scope rather than getting bad-faith quotes.

9. What Good Looks Like

Define success criteria. What does a successful launch look like? What metrics matter? What would make this a failure? This aligns expectations with any development partner and gives you a framework for evaluating their proposal.