inparlor.
engineering#agency#custom-software#engineering

Choosing a dev agency: 12 questions to ask

Portfolio forensics, who actually writes your code, process tells, contract terms that protect you, and twelve questions that reveal builder vs bodyshop.

5 min read·May 15, 2026

Priya Nair

Technical Director · Last updated May 15, 2026

Every development agency has a great website, a slick deck, and case studies with impressive logos. None of that tells you whether they'll build you something good. The difference between a builder and a bodyshop, a team that ships durable software versus one that bills hours and leaves a mess, is invisible in the sales pitch and obvious in the answers to a dozen pointed questions.

Here are the twelve. Ask them before you sign anything. The good agencies will answer them happily, because they're the ones who win on these answers. The bodyshops will dodge, and the dodge is the data.

Portfolio forensics

The portfolio is theater until you interrogate it. Anyone can show screenshots.

1. "Can I talk to a client from a project like mine?" Not a logo, a person on a call. A builder has references who'll take the call. A bodyshop has logos and a reason every reference is "too busy this month."

2. "What did you build here versus what was already there?" Agencies love to claim credit for projects they touched for two weeks. Make them draw the line between their work and the rest. Vagueness is the answer.

3. "Show me something that went wrong and how you handled it." Every real project has a fire. An agency that claims none either hasn't shipped anything real or won't tell you the truth. The way they describe a failure tells you how they'll treat yours.

Who actually writes your code

This is the question that exposes the most agencies, and almost nobody asks it directly.

4. "Who specifically will be on my team, and how senior are they?" Names and seniority. The sales pitch features senior architects; the build often gets handed to juniors the moment you sign. You want to know the actual humans.

5. "Do you subcontract or offshore any of the work?" Not inherently bad, but you deserve to know. A four-layer chain of subcontractors means the person writing your code is three companies removed from the person who sold you the project, and accountability evaporates at every hop.

6. "Can I meet the lead engineer before I sign?" A builder says yes. A bodyshop keeps engineers walled off behind account managers because the engineers can't sell and the managers can't build.

Reading the answers

Dimension
Bodyshop answer
Builder answer
Who's on the team
'Our talented team of experts'
Named people, with seniority and roles
Meet the engineers
'You'll work with your account manager'
'Sure, let's get them on the next call'
Subcontracting
Evasive or 'we have partners'
Clear yes or no, with who and why

The process tells

How an agency works day to day predicts your experience more than any case study.

7. "How often will I see working software?" The right answer is weekly, or close. Builders demo running code on a short cadence. Bodyshops go quiet for six weeks and resurface with something that isn't what you asked for, when it's too late to change.

8. "What's your testing and QA process?" If the answer is hand-wavy, you'll be the QA team, in production, in front of your users. A real answer mentions automated tests, code review, and a deploy process, not "we test thoroughly."

9. "How do you handle scope changes mid-project?" Scope will change; the question is whether their process is built for it or fights it. A clear, calm change process is a builder tell. Defensiveness here means every change becomes a battle.

The cadence of working demos tells you more than the entire pitch deck. Software you can click beats slides you can't.

The contract terms that protect you

The contract is where good intentions meet reality. A few clauses matter more than the rest.

10. "Who owns the code and the IP?" The answer must be you, unambiguously, on payment. If they retain ownership or get cagey about a license, walk. You're paying to build an asset, not to rent one you can never leave.

11. "What happens if we part ways?" A builder hands over a clean repo, documentation, and credentials, no drama. A bodyshop makes leaving painful on purpose, because lock-in is their retention strategy. Ask specifically: can another team pick this up without you?

The maintenance story

Software isn't done at launch; that's when it starts living. The maintenance answer separates partners from order-takers.

12. "What does support look like after launch, and what does it cost?" A builder has a clear answer: a maintenance plan, a response-time commitment, and a number, typically 15 to 25 percent of the build cost per year. A bodyshop treats post-launch as your problem and disappears, then charges premium emergency rates when something breaks at 2 a.m.

The follow-up that reveals everything: "If we find a bug a month after launch, what happens?" The answer should be calm and specific, not a flinch toward a new invoice.

Putting it together

You don't need all twelve answered perfectly. You need to watch how they're answered. Builders answer pointed questions directly, even the uncomfortable ones, because directness is how they win. Bodyshops deflect, reframe, and steer you back to the deck.

A quick scoring rubric:

  1. Green flags. Named senior team, weekly demos, you own the IP, clean exit terms, a real maintenance plan, references who pick up the phone.
  2. Yellow flags. Some offshoring (fine if transparent), fixed-price-only on exploratory work, a maintenance plan that's an afterthought.
  3. Red flags. Can't name the team, won't let you meet engineers, evasive on IP, no testing process, no maintenance story, a quote that arrived before any scoping.

Two or more red flags and you're probably looking at a bodyshop, no matter how good the website is.

We wrote these questions partly because we want to be on the right side of them. When you talk to us, ask all twelve. Then tell us about your project, or look at how we've answered them in practice across our case studies.


Read next:

Work with us

The team that builds this is for hire.

Priya sets architecture and engagement strategy across Inparlor's custom-software work, advising clients on build-vs-buy, scoping, and modernization.If this is the kind of work you need, here's where to start.

Get the next one

One operating note a month. No drip sequences.

Subscribe for one substantive piece a month plus the occasional working playbook we don't publish elsewhere.

Monthly notes on shipping software. No fluff, unsubscribe any time.

Want to talk?

Get a proposal

Send a 1-page brief; we respond in 48 hours with scope, pricing, and the team that would actually run the engagement.