How to Evaluate a Dev Shop (Without Being Technical)

You're a founder or operator who needs software built. You're not a developer. How do you evaluate a dev shop without being able to assess the quality of their code?

This is a real problem, and the answer isn't "hire a technical advisor to review their work." Here are the signals that matter — and the red flags that tell you to walk away.

What to Evaluate Before You Sign

Ask about their deployment process.

Ask directly: "What happens between writing code and something being live for users?" A shop that deploys well will describe a clear, automated process — code review, automated checks, deployment pipeline, live URL. A shop that doesn't will say something vague about "pushing to the server" or will tell you they'll "handle that later."

Deployment process is a proxy for engineering discipline. Shops with good deployment practices tend to have good practices everywhere.

Ask to see something they've shipped.

Not a case study. Not a logo wall. Ask to actually use a product they've delivered. Click around. Is it fast? Does it work on your phone? Does it feel like something a real person built for real users?

A shop that can't show you working software has a problem.

Ask how they handle scope changes.

Every project encounters changes. A scope change mid-engagement isn't a failure — it's normal. What matters is how the shop handles it. Do they have a clear process? Do they communicate proactively? Or do they just absorb the change and quietly build something different than what was agreed on?

Ask for a specific example of a time the scope changed and how they handled it.

Ask who will actually be working on your project.

Some shops sell with senior engineers and deliver with junior contractors. There's nothing inherently wrong with junior developers, but you should know who's writing your code. Ask directly: who will be on this project, what's their experience level, and will that team stay consistent throughout the engagement?

Red Flags During Evaluation

They're reluctant to give you a timeline.

A shop that won't commit to any timeline — even a rough one — is either not confident in their own estimates or has learned that vague timelines give them room to slip. Neither is good. Estimates can be wrong. Refusing to make them is a different problem.

They have more process than output.

Some shops are very good at the engagement before the engagement: discovery workshops, detailed project plans, stakeholder alignment sessions. If the ratio of planning to shipping is high, that's a signal about how they work.

They don't push back on your ideas.

A dev shop that agrees with everything you say isn't a partner — they're an order-taker. Good shops will tell you when they think something is a bad idea, when a scope is too large for the timeline, or when a technical approach has significant tradeoffs. If every conversation ends with enthusiastic agreement, something is off.

They can't explain what they'll build in plain language.

Technical jargon is sometimes necessary. But a shop that can't explain what they're building, why, and how it benefits users without resorting to buzzwords is either unclear on the work themselves or not confident in your ability to evaluate it. Both are problems.

The Signal That Matters Most

The best signal is how the shop behaves in the conversation before you've hired them.

Do they ask good questions? Are they focused on your problem, or on selling their services? Do they tell you things you didn't want to hear? Are they specific about what they'll deliver and when?

A shop that behaves like a partner before you've signed is likely to behave like a partner after. A shop that behaves like a vendor before you've signed will behave like one after too.

You can evaluate that without reading a line of code.

For a deeper look at what "fully managed" actually means in practice — and the specific responsibilities a shop should own — see What 'Fully Managed' Actually Means.