How to Evaluate a Software Development Agency Before You Sign

You’re holding a thirty-page proposal from a development agency. It has a timeline, a tech stack diagram, screenshots of past work, and a price with more zeros than you were hoping for. You’ve read it twice, and you still can’t answer the only question that matters: is this a good deal, or am I about to hand six months of runway to the wrong people?

I’ve reviewed a lot of these proposals on behalf of founders, and I can tell you something that should take some pressure off: the polish of the proposal tells you almost nothing about the quality of the code you’ll get. Some of the best engineering teams I’ve worked with write short, plain proposals. Some of the worst outcomes I’ve seen started with the most impressive pitch deck in the room.

You don’t need to become technical to evaluate an agency. You need to know what to ask, what a good answer sounds like, and which silences in the proposal should worry you. That’s what this article gives you.

Why this is harder than hiring an employee

When you hire a developer, you get an interview process, a trial period, and months of daily contact to figure out whether you judged them right. When you sign an agency, you’re committing a large chunk of money up front, based mostly on a sales conversation, to people you may never meet again after the contract is signed. The person who charmed you in the pitch meeting is almost never the person who writes your code.

There’s also a newer version of this problem I’m seeing more every month. Founders who built a first version with Lovable, Replit, or Bolt.new are now showing up to agencies asking for help taking it further. Agencies have noticed. “We’ll productionize your AI prototype” is becoming a standard pitch, and the quality behind that pitch varies enormously. Some agencies genuinely know how to take AI-generated code to production. Others will quote you a full rebuild because a rebuild is the biggest invoice they can write.

Either way, you’re the one signing. So let’s talk about what to look for.

The incentives you can’t see in the proposal

I started my career on the other side of this table. In 2004 I was freelancing as a one-person shop, building systems for local business owners making their first real technology investments. I know what it feels like to write a proposal, and I know which recommendations actually serve the client and which ones just make the vendor’s life easier.

Most agencies are not dishonest. But their incentives are not your incentives, and the proposal will never say so. An agency proposes the stack its current bench already knows, because staffing your project with people they have is cheaper than hiring for what you need. A fixed-price agency under schedule pressure cuts corners in the places you can’t see: automated tests, deployment setup, documentation. And every agency knows that a client who depends on them for every small change is recurring revenue.

I don’t say this to make agencies sound predatory. They’re normal businesses responding to normal incentives. Your job is to ask the questions that surface where their interests and yours split, before you sign rather than after.

Five questions that separate good agencies from polished ones

Ask these in the room, out loud, and pay as much attention to how they answer as to what they say.

“Who exactly will be writing my code?”

Not the account manager. Not the “solution architect” who joined the sales call. The actual developers. Ask for their names, ask how long they’ve been with the agency, and ask to have thirty minutes with at least one of them before you sign. A confident agency will set that up without hesitation. An agency that stalls here is usually planning to staff your project with whoever is free, possibly subcontractors you’ll never be told about.

“Tell me about a project that went badly, and what you did”

Every agency has one. The good ones will tell you a real story: what went wrong, what it cost, what they changed afterward. You’re listening for honesty and for whether they took responsibility or blamed the client. An agency that claims every project shipped on time and on budget is telling you they either haven’t done much or won’t be straight with you when your project hits trouble. And your project will hit trouble. They all do.

“Walk me through how code gets from your developers to my live product”

This sounds technical, but the answer is a story anyone can follow, and it’s one of the strongest signals of engineering quality you can get in a sales meeting. What you want to hear: code gets reviewed by a second developer, automated tests run on every change, and there’s a staging environment (a private copy of your product where changes are tried before real customers see them). What should worry you: a shrug, or an answer where one developer pushes changes straight to the live product. On my own projects, a change can go from finished to deployed and verified in under five minutes because that pipeline exists. Teams without one ship slower and break more, and you’ll be paying for both.

“What happens in the ninety days after launch?”

Launch is where an agency’s incentives and yours drift furthest apart. After launch, the agency moves on to its next client, and you’re left running the product. Ask what’s included after launch: bug fixes, monitoring, support hours, and most importantly, handoff. If you bring in your own developer later, what do they receive? Documentation? A walkthrough? Ask the agency to describe the handoff package as a deliverable in the contract, not a favor they’ll get to.

“What do I own, and starting when?”

This is the question founders skip most often and regret most deeply. The code should live in a GitHub organization that you own, from the first week, not delivered as a zip file at the end. The cloud accounts (AWS, Azure, whatever they propose) should be opened in your name, on your credit card, with the agency added as collaborators. The domain, the app store listings, the third-party service accounts: yours. I’ve watched a founder discover, mid-dispute, that her entire product lived in her agency’s accounts. Every week of the argument, her product was a hostage. Contracts matter here, but account ownership matters more, because possession decides who has to sue whom.

How to read the proposal itself

A few things to check once the document is in front of you.

Fixed price versus time and materials. A fixed price feels safer, and for a small, well-defined project it can be. But software is rarely well-defined up front, and a fixed-price agency absorbs surprises by quietly cutting quality or by nickel-and-diming every change as “out of scope.” Time and materials (paying for hours worked) feels riskier but is often more honest, especially when paired with a weekly demo so you can see what your money bought. There’s no universally right answer. What matters is that the agency can explain why they proposed the model they did, in terms of your risk rather than theirs.

What’s missing matters more than what’s there. Proposals are good at listing features. Look for the words that indicate the invisible work: testing, deployment, monitoring, documentation, handoff. If none of those appear as line items or deliverables, they are not in the price, and you’ll either pay for them later or live without them.

Milestones should be working software, early. A payment schedule where you see nothing real until month four is a payment schedule designed around their cash flow. Push for a structure where something you can click on exists within the first few weeks, even if it’s small. Working software is the only progress report that can’t be faked.

Red flags to walk away from

You can’t meet the developers. If the agency won’t put the people who’ll actually build your product in front of you before signing, assume the delivery team is not the pitch team and price that in. Or walk.

Everything is confident, nothing is conditional. Real engineering estimates come with assumptions and unknowns attached. A proposal with a precise price, a precise date, and no stated assumptions isn’t confidence. It’s a document written to be signed, with the corrections to come later as change orders.

The code and accounts live with them “for convenience.” There is no version of this that benefits you. Setting up your own accounts takes an afternoon. Untangling a dispute over accounts you don’t control can take a year.

They can’t explain a technical choice in business terms. Ask why they chose their proposed framework or database and listen to the answer. “It’s what modern teams use” is not a reason. A good agency can connect every major choice to something you care about: cost, hiring, speed of change. If they can’t explain it to you, they haven’t thought about it from your side of the table, and that won’t improve after the contract is signed.

How to start, gently

Don’t sign the thirty-page proposal this week. Do these four things first.

Ask the five questions above in your next meeting, and take notes on how the room reacts. An agency that bristles at fair questions before you’ve signed won’t get easier to work with after.

Open your own GitHub organization and your own cloud account before any contract is signed. It takes an afternoon and costs almost nothing. Then make “all work happens in our accounts” a non-negotiable line in the agreement.

Propose a small paid discovery phase before the big engagement: one to two weeks where the agency digs into your product and produces a real plan. You’ll learn more about how they think in two weeks of paid work than in ten sales meetings, and if it goes badly you’re out a small check instead of six months of runway.

And get one independent technical person to read the proposal with you for an hour. Someone with no stake in whether you sign. I’ve done these reviews often, and the pattern repeats: the founder’s instinct that something was off is usually right, and they just needed someone to point at the paragraph.

The agencies that survive all of this scrutiny are, in my experience, glad you asked. Good builders like informed clients. What’s in the proposal sitting in your inbox right now that you wish someone could translate?

Ready to bring clarity? Schedule a conversation: https://lambdalynx.dev/schedule/

#FractionalCTO #StartupFounder #BuildVsBuy