How to choose a development studio in 2026: 10 questions and the red flags
TL;DR To choose a development studio, ask every studio on your shortlist the same ten questions and judge each answer on what they can show you. The ones that matter most are who will build it, who owns the code, how the price is set and how changes are handled. Walk away from a team you only meet after signing, code kept in the studio's accounts, or a fixed price with no written scope.
- Ask to meet the people who will actually build your product, and ask whether the same people will be in the sprint reviews.
- Under US copyright law the studio owns the code it writes unless it signs a written assignment, so a work for hire clause alone is not enough.
- The code, hosting, domain and app store accounts should all sit in accounts you own.
- A fixed price should come with a written scope that says what is included and what is not.
- Expect working software you can use every one or two weeks, and scope changes priced in writing before anyone builds them.
In this article
- The ten questions to ask before you sign
- Who will actually build it?
- How to check their work is real
- Who owns the code at the end
- Is the budget realistic?
- What happens when the plan changes
- What happens after launch
- Freelancer, studio or an in-house team?
- How to protect your idea
- How to use the scorecard
- When we are not the right fit
- Questions for us
To choose a development studio, ask every studio on your shortlist the same ten questions before you sign, and judge each one on what it can show you rather than what it says. The answers that matter most are who will actually build your product, who owns the code at the end, how the price is worked out and what happens when the plan changes.
The three red flags I would walk away from are a team you only meet after signing, code that stays in the studio's accounts until the final payment, and a fixed price given before anyone has written down the scope. Each one is a common way founders end up paying for something they cannot use.
Honestly, I am writing this from the other side of the table, since Axtra Studios is a studio and you may well be choosing between us and someone else. So this guide gives the questions, what a good answer sounds like and the red flags, plus a scorecard you can download, and the same questions apply to us.
Development studioA small team of designers and engineers that designs, builds and launches software for clients, with the same people from the first call to launch, which is really different from a staffing agency that rents out developers by the hour.
The ten questions to ask before you sign
Ask every studio the same questions, ideally on a call where the people who would build your product are present. The table below is the short version, and the sections after it go through the ones that cause the most trouble.
| Ask | A good answer | A red flag |
|---|---|---|
| Who exactly will work on my project, and can I meet them? | Names and roles, and the same people on the first call and in the sprint reviews | A team assigned only after you sign |
| Can I see things you built that are live? | Links you can open on the call, with their role on each one stated plainly | Only mockups, or an NDA as the reason for everything |
| Who owns the code, the designs and the accounts? | A written copyright assignment, and code, hosting and domains in your name | Code kept on their side until the final payment |
| How is the price worked out? | A written scope, priced in milestones you pay as each one is delivered | One fixed number on the first call, with no breakdown |
| What happens when the scope changes? | Changes estimated in writing before anyone builds them | Changes discovered on the invoice |
| How often will I see working software? | A build you can use yourself every one or two weeks | Status reports and screenshots until the end |
| How do you test it? | A named QA person, real devices and automated tests on the main flows | The developers test their own work |
| What would you leave out of version one? | A real opinion on what to cut, and why | Yes to every feature on your list |
| What happens after launch? | A support plan with response times and a monthly cost | No plan, or maintenance only they can do |
| What happens if we part ways halfway? | You pay for the delivered milestones and get everything handed over | Kill fees, long notice periods or code held back |
Ten questions to ask a development studio before you sign · Source: Drawn from what founders report going wrong with agencies in public forums, and from how Axtra Studios works.
You will notice most of the good answers are things the studio can show you, like a name, a link, a contract clause or a working build. That is really the whole test, because anyone can say the right thing on a sales call, and only a studio that already works this way can show it to you.
Who will actually build it?
The most common complaint about agencies is that senior people win the work and junior people do it. So ask for the names and roles of the people on your project, ask to meet the lead developer and the designer before you sign, and ask whether those same people will be in the sprint reviews.
A good studio will be happy to answer, because the team is the product they are selling. At Axtra Studios the co-founders lead every project, so Zafar on strategy and the client relationship, me on engineering and Subhan on delivery, with our designers, developers and QA working alongside us, and there is no account manager between you and the people building it.
How to check their work is real
Ask for links to things they built that are live, and open them while you are on the call. A website, a web app you can sign in to or an App Store listing tells you far more than a slide of logos, and it is worth asking exactly what they did on each one, since building something and contributing to it are different claims.
We try to be precise about this on our own pages. Colota, for example, is an open-source app where our page describes the team as a significant contributor, not the builder, because that is what happened, and a studio that is careful about small claims like that is usually careful about bigger ones.
For reviews, a directory like Clutch is more useful than the testimonials on a studio's own site. Clutch says every review there comes from someone who signed in with LinkedIn, Google or a company email, and an editor checks that the reviewer really represents the client company. Even so, I would ask for one past client you can actually talk to.
Who owns the code at the end
This is the question founders most often get wrong, and the law makes it easy to get wrong. Under US copyright law, the person who writes the code owns it by default, and the US Copyright Office explains that software ordered from an outside studio does not fall into the narrow list of work that can be "made for hire" by contract.
So a clause saying the work is "work made for hire" is not enough on its own. What gives you the code is a written assignment of the copyright, signed by the studio, since the Copyright Act says a transfer of copyright is only valid in writing. Ask to see that clause before you sign, and I would honestly have a lawyer read the contract either way.
The practical side matters just as much. The code should sit in a GitHub account you own from the first day, and the hosting, the domain, the database and the app store accounts should all be in your name, so nothing can be held back if you part ways. That is how we work on every project, and you should expect it from anyone you hire.
Is the budget realistic?
A studio that gives you a fixed price on the first call has either built the same thing many times before or is guessing. A range after a short call is fine and useful, but a fixed price should come with a written scope that lists what is included and, just as important, what is not.
If the quotes you get are far apart, look at what each one includes before you look at the number. The cheapest quote often leaves out design, testing, the admin panel or the launch itself, and those come back later as change requests. Our cost guides for web apps, mobile apps and MVPs give the hours behind each type of build, so you have something to compare against.
What happens when the plan changes
The plan will change, because you will learn things once real people use the product. So ask how often you will see working software, and the right answer is a build you can use yourself every one or two weeks, not a status report.
Then ask what a change costs. Changes inside the agreed scope should be part of the work, and changes to the scope should be estimated in writing before anyone builds them, so you decide with the number in front of you and not after the invoice arrives.
What happens after launch
Ask what support looks like once the product is live, how quickly they respond when something breaks and what that costs each month. A studio that has no answer is probably planning to move on to the next project the week you launch.
Ask too what happens if you want another team to take over later. The right answer is documentation, a recorded walkthrough and a handover of every account, and the wrong one is a maintenance contract that only they can work under.
Freelancer, studio or an in-house team?
A studio is not always the right choice, and it is worth deciding that before you compare studios. The table below is how I would honestly think about it.
| Option | Best when | Watch out for |
|---|---|---|
| A freelancer | You have a technical lead and need one skill, or the job is small and clear | One person is a single point of failure, and design, testing and planning are usually on you |
| A studio | You need a whole product designed, built and launched by one team | Who actually does the work, who owns the code and what support costs after launch |
| An in-house team | The product is the business and you can hire and manage engineers | Hiring takes months, and you need a technical lead to hire well |
Freelancer, studio or in-house team · Source: Axtra Studios.
If you are not technical and you need a whole product designed and built, a studio is usually the safest choice, because one team owns the result. If you already have a technical lead and need more hands, a freelancer or a hire may fit better and cost less.
How to protect your idea
Ask the studio to sign a mutual NDA before you share the details, and most will sign without a fuss. Beyond that, the real protection is the contract, so the copyright assignment, the code in your own accounts and a clear clause on confidentiality.
It is also worth knowing that an idea on its own is rarely what gets copied. The hard part is building it well and getting it in front of the right people, which is why the questions above about the team, the ownership and the process protect you far more than secrecy does.
How to use the scorecard
Our studio scorecard is a plain spreadsheet with these questions, a weight for each one and a column for up to three studios. Score each answer 0, 1 or 2 after the call, multiply by the weight, and the total will show you what your instinct after the calls may have missed.
I would weight ownership, the team and the way changes are priced the highest, since those are the ones that are hardest to fix later. And if two studios score close together, pick the one whose people you would most like to be on a call with every week for the next few months.
When we are not the right fit
If your budget is under about ten thousand dollars, a freelancer or a no-code tool is the better choice, and if you need people to join your own team for the long term, hiring them is better than renting them from a studio. We will tell you that on the first call.
Where we fit is a founder or a business that needs a product designed, built and launched by one team, so a web app, a mobile app or an MVP with the code and accounts in your name.
Questions for us
The same ten questions apply to us, and we are really happy for you to ask them. Book a call and we will answer them with the people who would build your product, show you live work, and send you a written scope priced in milestones.
If you are still working out the budget, our cost guides above are the place to start, and if you already have a prototype built with an AI tool, our guide to taking an AI-built prototype to production covers what to look for there.
The ownership rules in this guide come from the US Copyright Office's Circular 30 on works made for hire and section 204 of the Copyright Act, and the review checks from Clutch's methodology, all checked on October 5, 2026. This is general information, not legal advice, and everything here follows our editorial policy.
