How to write a project brief for a Solana development team (free template)

By Jakub Malarczyk, Founder, Orivions · October 18, 2026

Key takeaways

A good brief fits on one or two pages and answers what, for whom, by when and for how much.
Separate on-chain scope (programs, accounts, tokens) from off-chain scope (frontend, indexers, keepers).
State constraints upfront: launch date, audit, integrations and who owns the keys and code.
Share a budget range; it makes quotes realistic and comparable.
Send the same brief to every team so you compare like with like.

The quality of the quotes you receive depends on the quality of the brief you send. A two-line message produces guesses; a clear one-page brief produces estimates you can compare. This guide explains what to include, and ends with a template you can copy.

Why the brief matters more on Solana

On Solana, the expensive decisions happen early: how accounts are laid out, which parts run on-chain, how the program will be upgraded and audited. A team that has to guess these things will either pad its estimate or underquote and renegotiate later. A brief that answers them upfront saves both sides time and money.

What to include

Goal and success metric: what should be true three months after launch. Teams design differently for a demo than for a protocol expecting real volume.
Users and main flows: who uses it and the three to five things they must be able to do. This drives most of the scope.
On-chain scope: programs, accounts, instructions, tokens or NFTs you expect. If you do not know, say so and ask the team to propose a design.
Off-chain scope: frontend, supported wallets, backend services, indexers, keepers and admin tools. Often half of the work.
Integrations: every external protocol, oracle, bridge or API. Each one adds code, testing and audit scope.
Constraints: launch date and why it matters, whether an audit is required, and that you will own the code, repository and upgrade authority.
What exists: designs, code, a specification, previous audits, or people on your side who will review the work.
Budget range: a range for the first release, with the audit budgeted separately.

Not sure about the technical parts? That is fine. Describe the outcome and ask each team to propose an architecture. Their proposals are a useful test of how well they understand Solana. See also Anchor vs native Rust.

Template

Copy this into a document, fill in what you know, and mark the rest as open questions.

PROJECT BRIEF

1. One-line summary
   What are you building, for whom?

2. Goal and success metric
   What should be true 3 months after launch? (users, volume, partners)

3. Users and main flows
   Who uses it, and the 3-5 things they must be able to do.

4. On-chain scope
   Programs, accounts and instructions you expect. Tokens or NFTs involved.
   Anchor, native Rust, or "you recommend".

5. Off-chain scope
   Frontend, wallets to support, backend, indexer, keepers, admin tools.

6. Integrations
   Protocols, oracles, bridges, APIs you must connect to.

7. Constraints
   Launch date and why. Audit needed (yes/no). Compliance limits.
   Who will own the code, repo and upgrade authority (should be you).

8. What already exists
   Designs, code, specification, previous audits, team members.

9. Budget range
   e.g. $15,000-25,000 for the first release, audit budgeted separately.

10. How to respond
    Deadline for proposals, what you want in them, who decides.

After you send it

Send the same brief to three to five teams and ask each for scope, milestones, team members, timeline and price. Compare the answers with the twelve questions to ask a Solana development company, and check typical costs in how much a Solana dApp costs. When you sign, structure payments around milestones as described in milestone payments for Web3 contracts.

Frequently asked questions

What should a brief for a Solana development project include?

The problem and the outcome you want, who the users are, what must happen on-chain versus off-chain, integrations with other protocols, constraints such as deadlines and audits, a budget range, and what you already have (designs, code, a specification).

Should I share my budget in a project brief?

Yes, a range. It lets teams propose a scope that fits instead of guessing, and it filters out teams that are far outside your budget before anyone spends time on a detailed estimate.

How long should a project brief be?

One to two pages is usually enough to get a first estimate. Detailed specifications come later, ideally in a short paid discovery phase with the team you choose.

Turn your brief into matches

Paste the summary of your brief into Smart Match and get verified Solana teams that fit, with a reason for each. Free for teams.

Try Smart Match →