On this page
Key takeaways
- A portfolio shows what a studio shipped. Your questions should reveal how it works and what happens after.
- Look for written scope, direct access to builders, and a real handover.
- Be wary of bench-style staffing, open-ended retainers, and confident promises without constraints.
- The best sign is a studio that is willing to say no or 'not yet'.
Choosing a software studio is a high-trust, low-information decision. Every website has clean case studies and confident copy. What you need to know is how the studio behaves when scope shifts, when a deadline slips, and after launch.
Here are twelve questions, grouped by what they reveal. We wrote them from the studio side; use them on us too.
Scope and fit
- 01
1. What would make you decline this project?
A good studio has real answers. A studio that accepts everything is selling capacity, not judgement.
- 02
2. How do you write scope, and when?
Look for a written statement of work with named operators and non-goals before development starts.
- 03
3. What will this not include?
The answer reveals whether they have thought about boundaries.
People and communication
- 01
4. Who will actually build this?
Names and roles. Ask whether the people in the sales conversation are the people writing code.
- 02
5. How do we communicate, and how often?
Prefer direct collaboration with the builders over layers of account management.
- 03
6. How do you handle changes mid-project?
You want a written change process, not a handshake and a surprise invoice.
Engineering practice
- 01
7. What ships in the first release, and where does it run?
A real environment beats a sequence of demos. Ask about deployment, authentication, and observability from week one.
- 02
8. How do you document decisions?
Architecture notes and trade-offs written down mean the system can outlive the engagement.
- 03
9. What do you do when something is technically risky?
Listen for how they surface risk early, not how they reassure.
After launch
- 01
10. What does handover include?
Code, runbooks, upgrade notes, and a person on your side who has used them without the studio.
- 02
11. What happens in the first ninety days?
Good studios plan a review and a second cut from real use.
- 03
12. Who owns the result?
You should own and be able to operate the system. Retainers that exist only to keep you dependent are a red flag.
Green flags and red flags
Red flags
- Yes to everything, immediately
- A bench of interchangeable developers
- Vague pricing until you have signed
- No written scope or non-goals
- Demos in place of a working environment
- Discourages talking to past clients
Green flags
- A clear 'not a fit' or 'not yet'
- Named builders, direct access
- Commercial shape agreed in writing
- Non-goals and constraints documented
- Ships to a real environment early
- Happy to connect you with past operators
Engagement models, plainly
| Model | Best for | Watch out for |
|---|---|---|
| Product build | A defined product from problem to first release | Scope creep without a change process |
| Feature development | One slice of an existing product | Unclear boundaries between your team and theirs |
| Technical partnership | Ongoing engineering for a limited, explicit scope | Turning into an open-ended bench |
| Frontend engineering | Interface, design system, application shell | A UI disconnected from the real backend |
A simple scorecard
Scope discipline (written, with non-goals) _
Direct access to the builders _
Engineering practice (deploy, observe) _
Handover quality _
Willingness to say no _
References from operators, not sponsors _How to read a proposal
A good proposal is a plan, not a pitch. It should let you compare studios on substance. Here is what to look for and what its absence tells you.
| Section | What good looks like | What its absence suggests |
|---|---|---|
| Problem statement | In your words, showing they listened | A template with your name pasted in |
| Scope and non-goals | Explicit boundaries and things left out | Scope that will expand |
| Approach and sequencing | A first release early; risks tackled first | A long design phase before anything runs |
| Team | Named people and their roles | Interchangeable resources |
| Deliverables and handover | Code, runbooks, documentation, review dates | Delivery ends at launch |
| Commercial terms | Clear model, change process, payment milestones | Surprises later |
| Assumptions and risks | Written, with mitigations | Confidence without constraints |
Pricing models compared
| Model | How it works | Good for | Watch out for |
|---|---|---|---|
| Fixed price | Agreed scope for an agreed price | Well-understood, bounded work | Rigid change process; padding to cover risk |
| Time and materials | Pay for effort at agreed rates | Discovery and evolving scope | Uncapped cost without a budget ceiling |
| Capped time and materials | T&M with a maximum | Bounded but uncertain work | A cap that quietly becomes the price |
| Retainer | Fixed monthly capacity | Ongoing product work | Paying for capacity you do not use |
Whichever you choose, insist on a written change process. Most disputes about cost are really disputes about what was in scope; the agile manifesto's preference for responding to change over following a plan [1] is a principle about collaboration, not permission to skip the paperwork.
Contract essentials, in plain language
Have a lawyer review any contract. These are the topics to make sure it addresses, not legal advice.
| Topic | Question to settle |
|---|---|
| Intellectual property | Who owns the code and designs on payment, and who owns pre-existing tools? |
| Acceptance | How is a deliverable accepted, and what happens if it is not? |
| Warranty and defects | How long are defects fixed at no cost after delivery? |
| Confidentiality | What is protected, for how long, and before the build starts? |
| Data and security | Who has access to your data and systems, and under what conditions? |
| Termination | What happens to work in progress if either side stops? |
| Third-party components | Licences of open-source and bought components used |
The first week: a kickoff checklist
Before the first line of code
- The problem, operator, and non-goals are written and agreed.
- You have direct access to the builders and a communication rhythm.
- A staging environment and deployment path exist by the end of week one.
- You have named the person who will operate the result.
- Risks are listed with owners and the first spikes scheduled.
Signs the engagement is going wrong in week three
Early warning signs
- Demos of screens but nothing deployed
- Scope discussions replacing progress
- You cannot reach the people building it
- Changes accepted verbally and not written
- Risks reassured away rather than investigated
Healthy signs
- A working slice in a real environment
- Trade-offs surfaced and decided in writing
- Direct, regular contact with the builders
- Change requests tracked with impact
- Risks raised early with a plan
If you see several warning signs, call a short reset: restate the problem, the non-goals, and the next deployable milestone. A good partner welcomes it.
We take a small number of selected engagements, write scope before we build, and hand over software you can operate. If that sounds like the kind of partner you need, the contact page asks only for the problem, the constraints, and who will run the result.
References & further reading
- 1Manifesto for Agile Software Development — Agile Manifesto authors, 2001
- 2Software Estimation: Demystifying the Black Art — Steve McConnell, Microsoft Press
- 3Shape Up: Stop Running in Circles and Ship Work that Matters — Ryan Singer, Basecamp
About the author
Product behaviour described here reflects what is implemented and tested; anything else is marked as planned. Code samples are illustrative.
All writing