How to Evaluate a Software Development Studio (Red Flags and Green Flags)

Choosing a software development studio is one of the highest-stakes decisions a founder or product owner makes. Pick the right one and you get a partner who accelerates your business. Pick the wrong one and you get months of delays, a codebase nobody can maintain, and a budget that evaporated with little to show for it.

We are a studio ourselves, so take everything here with a grain of salt. But we have also been on the other side — evaluating contractors, inheriting codebases from other agencies, and cleaning up projects that went sideways. We have seen what good and bad look like from multiple angles.

Here is what to actually look for.

Check the Portfolio — But Look Deeper Than Screenshots

Every studio has a portfolio page. Most of them look impressive. Pretty screenshots, big logos, polished case studies. But a portfolio only tells you what a studio wants you to see.

Here is what to actually evaluate:

Are the products live? Visit the URLs. Click around. If a studio built an app two years ago and it is still running, handling real users, and looks maintained — that is a strong signal. If the URL is dead or the app is clearly abandoned, ask why.

Is the work varied or repetitive? A studio that has only built WordPress marketing sites may struggle with a complex SaaS platform. Look for range that matches your needs. If you are building a multi-tenant platform with real-time features, you want a studio that has built something with similar technical complexity.

Can they explain the technical decisions? Ask about a specific project. Why did they choose that database? How did they handle authentication? What was the hardest technical challenge? A good studio will light up when asked these questions. A bad one will give vague answers or redirect to the designer.

When clients evaluate us, we walk them through specific projects like MindHyv or LancerSpace and explain not just what we built, but why we made the choices we did and what we would do differently today. That level of transparency is a green flag from any studio.

Ask About Their Process — Then Verify It

Every studio will tell you they have a process. Agile, Scrum, Kanban, “our own proprietary methodology” — the labels do not matter. What matters is whether the process actually exists in practice.

Green flags:

• They can describe their process without jargon. “We work in two-week sprints, you get a demo at the end of each one, and we re-prioritize before starting the next one” is clear and real.
• They have templates and documentation for their process. A scope document template, a project brief format, a deployment checklist — these are signs that the process is systematized, not improvised.
• They push back on your timeline if it is unrealistic. A studio that says yes to everything is a studio that will miss deadlines and blame scope creep.

Red flags:

• They cannot explain how they handle change requests. Every project changes. If a studio does not have a clear process for evaluating and incorporating changes, you will end up in arguments about what is “in scope” versus “out of scope.”
• They do not mention testing or QA at all. Ask specifically: “How do you test?” If the answer is “our developers test their own code,” that is a problem. You want at least some structured QA process, even if it is lightweight.
• They talk about agile but cannot describe what their actual sprint cycle looks like.

We wrote about how we scope projects and what happens when you email us — not because we think our process is unique, but because a studio that can articulate its process in writing has probably thought about it more than one that cannot.

Evaluate Communication Speed and Quality

This one is easy to test and hard to fake. Pay attention to how the studio communicates during the sales process, because that is the best-case scenario. It only gets worse from there.

Response time. How long does it take them to reply to your initial inquiry? To your follow-up questions? If they take three days to respond during the sales process — when they are motivated to impress you — imagine how slow they will be mid-project when they are juggling multiple clients.

Quality of responses. Do they answer your actual questions, or do they give canned responses that could apply to anyone? Do they ask clarifying questions that show they actually read your brief? Do they push back on anything, or just agree with everything you say?

Communication tools. Ask what tools they use for project communication. Slack, Linear, Notion, email — the specific tools matter less than whether they have a clear system. A studio that says “we’ll just use email” for a six-month project is a studio that will lose track of decisions and context.

A practical test: After your initial call, send a follow-up email with three specific questions about the project. Time how long it takes to get a response, and evaluate whether the response actually addresses all three questions. You would be surprised how many studios fail this basic test.

Transparency on Pricing — The Biggest Red Flag Detector

How a studio handles pricing tells you almost everything you need to know about how they operate.

Green flags:

• They give you a range before doing detailed scoping. “Based on what you have described, projects like this typically cost between X and Y” is honest and helpful.
• They explain what drives the cost. “The payment integration will take longer because of PCI compliance requirements” shows they are thinking about your specific project, not applying a formula.
• They are upfront about what is not included. Hosting, domain, third-party service costs, post-launch support — a good studio lists these out before you ask.
• They offer different scope options at different price points. “We can build version A for X or version B (with these additional features) for Y” shows they are trying to match your budget, not maximize their invoice.

Red flags:

• They quote a fixed price without detailed scoping. A studio that gives you an exact price after a 30-minute call is either padding the quote massively or planning to cut corners.
• The quote is significantly cheaper than everyone else. Software development has a real cost floor. A team of experienced developers costs money. If a studio’s quote is 50% below the market average, they are either using junior developers, offshore labor they are not disclosing, or planning to deliver less than you expect.
• They will not explain their rate structure. You do not need to see their profit margins, but you should understand whether you are paying for one developer or three, and what seniority level you are getting.

We have written about the fixed price vs. time and materials debate in detail. The short version: fixed price works for well-defined projects; time and materials works for projects that will evolve. Either model is fine. What is not fine is a studio that will not discuss pricing openly.

Check References — And Ask the Right Questions

Most studios will give you references. Most clients will say nice things. To get useful information, you need to ask specific questions:

• “Was there a point in the project where something went wrong? How did the studio handle it?”
• “Did the final cost match the original estimate? If not, why?”
• “Would you hire them again for a different project? Why or why not?”
• “How was the handoff at the end of the project? Were you able to maintain the product without them?”

The last question is critical. A lot of studios build products that only they can maintain. This creates a dependency that benefits the studio and hurts you. A good studio builds products that you can hand off to an internal team or a different contractor.

Ask about the codebase quality specifically. Is it well-documented? Are there tests? Can a new developer get it running locally in under an hour? These are not unreasonable expectations — they are the minimum bar for professional work.

Technical Due Diligence — What Non-Technical Founders Should Ask

If you are not technical yourself, it is hard to evaluate a studio’s technical capabilities. Here are questions that will help you assess quality without needing to read code:

“What is your tech stack and why?” The specific technologies matter less than whether they can articulate why they chose them. “We use React because it is popular” is a weak answer. “We use SvelteKit because it gives us server-side rendering out of the box, smaller bundle sizes, and faster development velocity for the types of apps we build” is a strong one.

“How do you handle deployments?” You want to hear about continuous integration, automated testing, and staging environments. If they deploy by uploading files via FTP, run.

“What happens if your lead developer leaves?” This tests for bus factor. A good studio has documentation, code reviews, and shared knowledge. A bad one has a single developer who holds all the context.

“Can I see a sample codebase or code snippet from a similar project?” They may not show client code, but they should be able to show something — an open-source project, a technical blog post with code examples, a demo application. If they have nothing to show, that is a red flag.

“How do you handle security?” At minimum, you want to hear about authentication best practices, data encryption, secure environment variable management, and regular dependency updates. For more on this topic, see our post on authentication patterns for web apps.

The Guaranteed Timeline Red Flag

This deserves its own section because it is the single most common red flag we see.

If a studio guarantees a specific launch date for a complex product before doing detailed scoping, they are either lying or planning to cut scope to hit the date. Software development is inherently uncertain. Good studios acknowledge this uncertainty and manage it through iterative development and regular check-ins.

What you should hear instead: “Based on our experience with similar projects, we estimate 12-16 weeks for the core features. We will have a more precise timeline after the discovery phase, and we will give you a demo every two weeks so you can track progress.”

That answer is less satisfying but more honest. And honesty in the sales process predicts honesty throughout the project.

Size and Structure Matter

A solo freelancer, a five-person studio, and a 200-person agency are fundamentally different experiences.

Solo freelancers are often excellent developers but have zero redundancy. If they get sick or take on too much work, your project stalls. They also tend to be weaker on design and project management.

Small studios (3-15 people) often hit a sweet spot. You get dedicated senior talent, direct communication with the people doing the work, and enough redundancy that one person’s absence does not halt the project. We are a team of four senior engineers, and that size lets us work closely with clients while maintaining the depth needed for complex projects.

Large agencies (50+ people) have the capacity for big projects but often assign junior developers to the actual work while senior people handle sales. You might be impressed by the partner you meet during the pitch, only to discover that your project is being built by developers with two years of experience.

Ask specifically: “Who will be working on my project, and what is their experience level?” Then verify this during the project — are the people you were promised actually the ones writing code?

The Post-Launch Question

A surprising number of clients do not ask about post-launch support until after launch. By then, it is too late to negotiate good terms.

Before signing a contract, ask:

• What happens after launch? Is there a support period included?
• What are your rates for ongoing maintenance and feature development?
• How do you handle handoff if we want to bring development in-house?
• What documentation will you provide at the end of the project?

A studio that plans for the end of the engagement from the beginning is a studio that has your long-term interests in mind. We wrote more about this in our post on post-launch maintenance.

Trust Your Gut, But Verify

After all the evaluation criteria and checklists, there is one more thing: how does the interaction feel? Do they listen to you? Do they ask thoughtful questions? Do they seem genuinely interested in your project, or are you just another deal to close?

The best client-studio relationships feel like partnerships, not transactions. You should feel like the studio is invested in your success, not just in billing hours. That feeling is hard to quantify, but it is easy to recognize — and it is the single best predictor of a successful project.

If you are evaluating studios and want to see how we approach client partnerships, reach out at hello@threshline.com. We are happy to walk through our process and show you real examples of our work.