How to Choose a Software Development Agency: A Buyer's Filter

The three engagement models, and the honest tradeoff of each

Before evaluating a single agency, decide how you want to buy. Most bad engagements are a mismatch between model and problem, not a bad team.

Model	You pay for	Best when	The honest catch
Fixed-price project	A defined scope for a defined number	Scope is genuinely known: a spec or prototype exists	They price your risk plus a margin for being wrong. You pay a premium for certainty, and every change becomes a negotiation
Time & materials	Hours, billed as worked	Scope will change: discovery-heavy work, R&D, ongoing product	All the budget risk is yours. Without a cap and weekly demos, "we're 80% done" can last four months
Dedicated team	Named people, monthly, full-time	6+ months of roadmap and someone in-house to direct it	You are now a manager. Without a product owner with real availability, you're paying full rate for a team waiting on decisions

Two things nobody tells you about this table:

1. Fixed-price isn't safer than T&M, it's differently risky. It shifts delivery risk to the agency and scope risk to you. The moment requirements move you're in change-order territory, where they have pricing power and you have a half-built product. And a fixed price against a vague brief is the worst of both: the agency either pads (you overpay) or doesn't (you're about to meet a team suddenly very interested in what's "in scope"). Scope first, fix the price second.
2. Dedicated team is sold as the flexible option when it's really the stickiest: highest revenue for the agency, hardest to exit. Right for a funded company with a roadmap; notice when it's pitched to a founder who needs one product built once.

Sensible default: fixed price on a small scoped piece of work, then T&M or a dedicated team once you've seen how they perform.

Where to actually look, and how to read each source skeptically

Directories (Clutch, DesignRush, GoodFirms). Fine for a longlist, weak as a ranking. Placement is influenced by paid tiers, and reviews are usually collected by the agency, so the agency chooses who gets asked. Not fake, but a selected sample. Read for detail: does the review name the project, the duration, the budget band, something that went wrong?

Referrals. The strongest signal, with one adjustment: ask what went wrong and how it was handled. "They were great" is a feeling. "We lost three weeks on payments when we changed the requirement mid-build, and here's what they did" is data.

GitHub and open-source presence. Underrated. You don't need to read the code: look at whether it exists, whether commits come from more than one or two accounts, and whether anything is recent. Public repos show you something a portfolio page can't fake.

Portfolio work. The only question worth asking of a case study: can I verify this? Client named, product live, can I open it? NDAs are legitimate, but if nothing is verifiable, that's a pattern. Ours is at /portfolio: apply the same test.

How to read a proposal: real estimate vs aspirational one

Proposals that look alike can mean completely different things.

A real estimate contains:

• Named assumptions. "One user role, Stripe only, no offline mode, admin panel is CRUD." Assumptions are where the price actually lives; a proposal without them is a wish.
• Line items by feature or workstream, with hours attached, not one number for "development".
• Explicit exclusions. A quote 25% cheaper than the rest has usually moved QA, design, PM or post-launch fixes into "not included": the most common reason two quotes for identical scope differ by 40%.
• A written change process, a named team with seniority and allocation, and payment tied to deliverables rather than the calendar.

An aspirational estimate contains: a range wide enough to survive any outcome, a timeline with no milestones, a "team of 5–8 developers", the word approximately doing heavy lifting, and a total that arrived within 48 hours of a 30-minute call.

That last one matters most. A precise-looking number produced fast, without scoping, isn't an estimate, it's a placeholder designed to win the deal. The real number surfaces during the build, when you're already committed. One free test: divide the total by the hourly rate and ask whether that many hours plausibly builds what you described.

The questions that expose weak agencies

Each question below is chosen because a strong agency answers it immediately and a weak one has to improvise. Ask on a call, not by email: you're evaluating the hesitation as much as the content. Ask them of every agency you're considering, including us.

1. "Who exactly will write my code, and can I meet them before I sign?"

A good answer sounds like: "Priya leads it, four years with us, here's her GitHub. She's full-time on your build, with a second engineer part-time from week three. Let's put her on the next call and you can ask about the architecture directly."

A bad answer sounds like: "You'll be assigned a dedicated team of experienced developers." Or "you'll work with your project manager, who'll coordinate with the engineers." Or "we allocate resources once the contract is signed."

Why it works: Agencies sell with senior staff and deliver with whoever's free. If they won't name people before you sign, they don't know who it'll be. Watch too for answers that route through a PM: every layer between you and the builders degrades information.

2. "What's your team's actual seniority mix on my project?"

A good answer sounds like: "Two engineers, both 6+ years. We don't put juniors on client payments code. Our model is small and senior, which is why our hourly isn't the cheapest you'll see."

A bad answer sounds like: "We have 40 developers across all seniority levels." Or "our senior architect oversees all projects", where oversees is doing enormous work. One distant architect reviewing five juniors' output is the most common structure behind bad outsourcing stories.

3. "What is your estimate based on, and what happens when it's wrong?"

A good answer sounds like: "A prototype and a written technical plan, broken down by feature. Here are the three assumptions most likely to break. If we're wrong inside our own estimate, that's our cost. If you change scope, here's the written change process."

A bad answer sounds like: "We're very accurate, we've done hundreds of these." Or "we'd rather not commit until we get into development." Or silence, followed by a range.

4. "Do you charge for discovery and scoping? And if not, why not?"

A good answer sounds like: "Yes, a paid engagement with its own deliverables, credited against the build if you continue." Or, honestly: "No, but the cost of scoping sits inside our build price. Free discovery isn't free; it's amortised across the clients who sign."

A bad answer sounds like: "Discovery is completely free, no obligation!", delivered as generosity, with no acknowledgement of the economics.

Why it works: Against our own industry's interest: free scoping usually means it's priced into the build, or it isn't real scoping. An agency giving away two weeks of senior time is recovering it elsewhere, or running a sales exercise dressed as discovery. The first is normal and fine; pretending free work is costless is not. Paid discovery buys one thing worth the money: you own the output and can walk away with it.

5. "Who owns the IP, and when does ownership transfer?"

A good answer sounds like: "You own everything on payment, assigned in the contract. We'll flag open-source licences and third-party components with usage terms. If we reuse an internal library, you get a perpetual licence in writing."

A bad answer sounds like: "Of course you own it", with nothing in the contract. Or "we retain rights to our frameworks and components", undefined.

6. "What happens to the code and infrastructure if we part ways in month three?"

A good answer sounds like: "Code lives in your GitHub org from day one, we're collaborators on your repo, not the reverse. Cloud accounts are in your name, on your billing. Revoke our access this afternoon and nothing breaks. The contract has 30-day notice both ways."

A bad answer sounds like: "We'd hand everything over at the end of the project." Or "it's in our repository, we'll transfer it at completion." Or "that's never happened."

Why it works: The highest-leverage question here, and almost nobody asks it. If code and infrastructure live under the agency's accounts, you don't have a vendor, you have a hostage situation waiting for a disagreement. Ask early: it's nearly impossible to fix later.

7. "Walk me through a project that went wrong and what you did about it."

A good answer sounds like: a specific story with a date, a real mistake, a cost, and what changed afterwards. "We underestimated a legacy data migration by three weeks, ate the overrun, and now run a paid data audit before quoting anything that touches an existing database."

A bad answer sounds like: "We've been fortunate, all our projects have gone well." Or a story where the client was the problem. Or a humblebrag failure ("we cared too much about quality and went over on polish").

8. "What does handover look like, concretely?"

A good answer sounds like: "A README that gets a new engineer running locally in under an hour, architecture notes, documented environment variables, CI/CD in your accounts, a deploy/rollback runbook, and a recorded walkthrough, whether or not you continue with us."

A bad answer sounds like: "We provide full documentation at project close." (Which documentation?) Or "our code is self-documenting." Or genuine surprise at the question.

9. "What's your change process, in writing?"

A good answer sounds like: "Written request, priced in days and dollars within 48 hours, approved by you before we build, with the timeline shift stated up front. Here's a blank change form from a live project."

A bad answer sounds like: "We're agile, we're flexible, we just absorb small changes." That sounds generous and is the mechanism by which projects slip four weeks with nobody able to say when it happened.

10. "What are our guaranteed overlap hours, and who do I message at 9am my time?"

A good answer sounds like: "Four hours of guaranteed overlap, in the contract. Shared Slack with the engineers in it, not just a PM. Async standup by 9am your time daily. If something's on fire, here's the number."

A bad answer sounds like: "We're very responsive, usually within 24 hours." Or "your project manager will keep you updated with weekly reports."

Red flags and deal-breakers

Some of these are signals to probe. Some end the conversation.

Red flag	What it usually means
A 10x price range with no scoping ("$20k–$200k")	Nothing has been estimated. The range exists so no outcome can be called wrong
Won't name the engineers before signing	Staffing gets decided after the deal closes, based on who's free
No written change process	Scope disputes get settled by whoever has leverage, not you, mid-build
"We'll figure that out in development"	About a core flow: the estimate excludes the hardest part of your product
Pressure to sign before scoping	Urgency sold instead of clarity. Real capacity limits get explained, not weaponised
Portfolio work you can't verify	Sometimes NDAs. If it's everything, it's a pattern
Code or cloud accounts under their control	The hardest item here to fix after the fact
Everything routes through a salesperson or PM	You'll never speak to the person who understands your system
Won't put overlap hours, notice period or IP transfer in the contract	Deal-breaker. Unwritten isn't committed

The last row is the general principle: anything an agency will say but won't write is not a commitment. No need to be adversarial about it. "Great, can we get that in the SOW?" is a complete sentence, and the reaction tells you everything.

Offshore, nearshore, onshore: the honest version

We're an India-based studio; most of our clients are in the US and Europe. Take this as testimony rather than marketing, including the parts that don't flatter us.

	Onshore (US/EU)	Nearshore (LatAm, Eastern Europe)	Offshore (India, SE Asia)
Blended hourly	$120–$250	$45–$80	$15–$25 (ours ~$20)
Timezone overlap with US	Full	4–8 hours	2–4 hours, deliberately scheduled
Best fit	Enterprise procurement, on-site or heavily regulated work	Teams wanting near-full-day overlap who can pay for it	Founders who want senior engineers without US overhead and will manage async

The savings are real and they're not a skill discount: the gap between $20/hour and $200/hour is cost of living and overhead, not talent. The bad outsourcing stories are also real. We've inherited enough of those codebases to name the failure modes:

• The body shop. Five juniors under one distant "architect" who reviews at a glance. Looks like progress for six weeks, then doesn't survive contact with real load.
• The PM wall. You never speak to an engineer. Your requirement is transcribed by someone whose job is keeping the call pleasant, then transcribed again into a ticket. What gets built is a copy of a copy.
• The spec as contract. The team builds exactly what's written, including the obviously wrong parts, because deviation costs them money. Nobody says "this flow doesn't make sense": that's the incentive structure, not a personality flaw.
• Timezone theatre. "We work in your timezone" means one person answers Slack at 8pm while the engineers are asleep for every decision you need.
• Silent lock-in. No documentation, infrastructure under the vendor's accounts, a codebase only they can navigate.

Test for all five in one call: speak to the engineer alone, no PM; ask them to disagree with something in your brief (a team that can't find one questionable decision in your plan won't push back in month three either, the highest-signal 60 seconds in the process); get the overlap window in writing; confirm the repo and cloud accounts are yours on day one; and ask for weekly working software rather than status reports.

Vendors that pass those five are usually fine regardless of geography; vendors that fail them are usually a disaster regardless of geography. Distance amplifies process problems. It doesn't create them.

De-risk it with a paid trial before you commit

Stop trying to pick correctly from the outside. You can't evaluate an agency from a proposal; you can from two weeks of work.

Structure a small, paid, scoped first engagement. Paid, not free, so it's real work with real accountability and you own the output. It should be fixed-price and short (one to three weeks), produce something you keep and can hand to another team, end with a fixed quote for the build, be credited against that build if you continue, and involve the actual people who'd do the real work.

You're buying information: do they hit the date, ask good questions, tell you when you're wrong, and write code a senior engineer would recognise. Our version is the Scoping Sprint: $2,300 fixed, two weeks, with a clickable prototype, technical plan, and a fixed quote (a number, not a range), credited in full if you build with us. If you don't, you own everything and can take it to any other agency. That's not generosity; it's the only structure that makes the offer honest.

Ask every agency on your shortlist for their equivalent. What matters isn't the specifics but whether they'll commit to a small piece of paid work with a defined deliverable and a fixed price before asking you to sign a six-figure build. (How we run projects →)

What it should actually cost

Sanity-check ranges from our published guides, at our blended senior rate of ~$20/hour. US and Western European agencies quote several times these figures for equivalent scope; that spread is cost of living and overhead, not quality.

What you're building	Typical range	Detail
MVP	$5,000–$25,000	MVP cost guide →
Website / web app	$5,000–$50,000+	Web app cost guide →
Mobile app	$10,000–$50,000	Mobile app cost guide →
SaaS platform	$5,000–$150,000+	SaaS cost guide →
Scoping Sprint	$2,300 fixed, 2 weeks	What's included →

A quote far below a range should worry you as much as one far above: someone misunderstood the scope, or plans to recover the difference in change orders. Budget maintenance at 15–20% of build cost per year; a product you can't afford to change after launch was a bad purchase whatever you paid.

Now judge us by our own checklist

It would be dishonest to write the above without running it against ourselves.

Where we hold up: you meet the engineers before you sign, not a salesperson. We're small and senior by design, with no junior pyramid, because we don't have the volume to run one. Prices are published (Scoping Sprint at $2,300, ranges across every guide we write). Quotes are fixed, based on a prototype and a plan. Your repo and cloud accounts are yours from day one. And we have failure stories: ask on the call.

Where we're the wrong choice, genuinely:

• You need a 40-person squad next month. We're a small senior team. Any studio our size claiming otherwise plans to subcontract you. Hire a vendor with real bench depth.
• You need full-day overlap with US hours. We guarantee overlap in writing and it works for most clients, but if you need an engineer live at 4pm Pacific daily, nearshore is the better structural fit.
• You have enterprise procurement requirements such as SOC 2 as a precondition, MSAs with insurance thresholds, or on-site presence. Not our intake.
• You want the cheapest possible number. You can find cheaper. You'll get a junior team, and the rework costs more than the gap.
• You need a body to fill a seat in an existing eng org. That's staff augmentation; we build products end to end. (What that means →)
• You haven't validated demand. We turn down builds where nobody's spoken to customers: twenty conversations and a Figma prototype kill a bad idea for a few hundred dollars instead of $15,000. (Where we start instead →)

If we're still a fit, tell us what you're building. If we're not, use the questions above on whoever is: they work just as well on the agency you pick instead of us. That's the point of the page.

Written by Pranav Begade, founder of Sapient Codelabs, a senior product engineering studio that has shipped 100+ products for 60+ clients and runs three of its own. We wrote this guide to be usable against us. Prices reflect our current rates as of 2026.