Orivions / Blog / Hiring a Solana development company
How to hire a Solana development company: 12 questions to ask before you sign
By Jakub Malarczyk, Founder, Orivions ·
- Judge a Solana team by what it has shipped to mainnet, not by its pitch deck.
- Insist on named engineers, a written scope with milestones and explicit assumptions.
- Ask how they test on-chain code and who runs the external audit before launch.
- Own your code, repository, upgrade authority and deployment keys from day one.
- Tie payments to accepted milestones, and plan for maintenance after launch.
Most bad outsourcing outcomes are visible in the first call, if you ask the right questions. Whether you need a full product team or a few engineers to extend an existing protocol, these are the twelve questions we would ask any Solana development company before signing.
1. Which Solana programs have you shipped to mainnet?
Ask for program addresses, repositories or live products, not logos. Mainnet experience with real users is different from hackathon demos and devnet prototypes.
2. Anchor or native Rust — and why for our project?
Anchor removes a lot of boilerplate and many classes of account-validation mistakes; native Rust gives more control over compute and account layout. A good team explains the trade-off for your case instead of defaulting to whatever they always use.
3. Who exactly will work on this, and how much of their time?
Get names, seniority and allocation. The senior engineer on the sales call is not always the one writing your program.
4. How do you scope and estimate?
Look for a short paid discovery or specification phase, milestones with clear acceptance criteria and an explicit list of assumptions. A large fixed quote from a two-paragraph brief is a guess.
5. How will you design the accounts and keep within compute limits?
Account layout, PDAs, transaction size and compute units shape what is possible on Solana. Teams that think about these early avoid expensive rewrites later.
6. How do you test on-chain code?
Expect unit and integration tests run against a local validator or a lightweight test runtime such as LiteSVM, tests for failure paths (wrong signer, wrong account) and, for anything holding funds, fuzzing or invariant tests.
7. How do you handle security reviews and the external audit?
Internal peer review is the minimum. For programs that hold user funds, plan an independent audit before mainnet and agree who coordinates it and who fixes the findings. Our guide to choosing an auditor covers what to look for.
8. What off-chain infrastructure does this need?
Indexers, RPC providers, keepers or cranks, monitoring and alerting are often where projects break in production. Make sure they are part of the scope and the budget.
9. Who owns the code, the repository and the upgrade authority?
You should own all IP, the repository should live in your organisation from day one, and the program upgrade authority and deployment keys should sit in a wallet or multisig you control.
10. How will we communicate and track progress?
Agree a weekly demo or written update, access to the repository and issue tracker, and a single accountable contact on their side.
11. What happens after launch?
Ask about bug-fix warranties, maintenance retainers, response times for incidents and how knowledge is handed over if you take development in-house.
12. How are payments tied to delivery?
Pay per accepted milestone, not per month of activity. Fixed-price per milestone works for well-scoped work; time-and-materials with a cap works better for exploratory work.
Related reading: how to choose a Solana smart contract auditor. To compare verified teams and indicative price ranges, see Solana development companies.
Frequently asked questions
Should I hire a Solana development company or freelancers?
A company is usually the safer choice when you need several roles at once (on-chain Rust, frontend, DevOps), a single accountable contract and continuity if one engineer leaves. Experienced freelancers can be faster and cheaper for a well-scoped, single-person task.
Do I need a separate audit if my development company tests its code?
Yes. Internal testing and an independent audit catch different problems. A team reviewing its own code shares the same assumptions; an external auditor does not. For any program that holds user funds, budget for an independent audit before mainnet.
Who should own the code and the program upgrade authority?
You should. The contract should state that all code and IP transfer to you, the repository should live in your organisation, and the program upgrade authority should be a wallet or multisig you control, not the developer.
Find a verified Solana development team
Describe what you are building in plain English. Smart Match suggests verified development companies with a reason for each match. Free for teams.
Get matched →