Most founders walk into agency sales calls with one question: how much does this cost? That is the wrong starting point. Cost is the output. The questions below get at the inputs -- process, contracts, pricing model, tooling, and proof -- that actually determine whether a project ships on time, on budget, and worth using.
Ask these before you sign anything.
How does an agency's process reveal whether they are a good fit?
The fastest way to evaluate an agency is to ask them to walk you through the last project they shipped. Not the case study on their website. The actual sequence of events: how did discovery work, when did wireframes land, who approved scope, how were changes handled mid-build?
A team with a repeatable process describes it the same way every time. A team running it ad hoc starts with "well, it depends on the project." Both answers are informative.
Specifically, ask about discovery. This is the phase before any code is written -- the part where your idea gets turned into a documented plan. At a disciplined agency, discovery takes roughly one week and ends with every screen, user flow, and feature written down and signed off. At an undisciplined one, discovery bleeds into development and features get defined on the fly. That is where scope creep starts, and a 2024 GoodFirms survey found 60% of software projects blow their budget by at least 20%, with scope creep named as the leading cause.
Also ask: who is your day-to-day contact? If the salesperson is the one answering now but a project manager you have never met will be running the engagement, that gap matters. You want to meet the PM and at least one lead engineer before signing.
One more thing worth asking: what happens during week one? A team with real process can tell you exactly -- discovery call Monday, wireframes by Wednesday, scope document signed off by Friday. If the answer is vague, the process probably is too.
What contract terms protect me if the project goes sideways?
Contracts get ignored until something goes wrong. By then, it is too late to negotiate. These four terms are worth reading carefully before you sign.
Milestone-based payments mean you pay as work is completed, not in a lump sum upfront. A typical structure is 25% at signing, 25% after design sign-off, 25% at the halfway mark, and 25% on delivery. If an agency asks for more than 30-40% before a single screen exists, that is unusual and worth pushing back on.
IP assignment on delivery is the clause that says you own the code once you have paid for it. Some contracts are vague here, leaving the agency with a license to the work or with ownership of reusable components they built for you. Ask directly: "Will I own 100% of the code and all related assets on final payment?" If there is any hedging, ask for the specific clause in the contract.
A scope change process should be written down, not verbal. Any feature added after sign-off should generate a written change order with a price and timeline before work starts. Agencies that handle changes informally are the ones whose clients end up with surprise invoices.
A warranty period after launch -- typically 30 to 90 days -- during which the agency fixes bugs at no charge. This is standard. If it is absent from the contract, ask for it.
None of these terms are aggressive demands. They are the baseline for professional software engagements. An agency that resists them is telling you something about how they operate when problems arise.
How should I compare fixed-price bids to time-and-materials quotes?
This is where founders get burned most often, because the two pricing models are not comparable on face value.
A fixed-price bid says: we will build exactly this scope for exactly this amount. The risk sits with the agency -- if it takes longer than they estimated, that is their problem. The catch is that scope must be locked in advance. Any change you request mid-build is a change order, and change orders are where fixed-price contracts get expensive. If the scope document is thin or ambiguous at the start, a fixed-price bid is not actually fixed.
A time-and-materials quote says: we charge by the hour or day, and the final cost depends on how long it takes. The risk sits with you. A well-run T&M engagement with clear requirements can be highly predictable. A poorly scoped one with a team that estimates slowly can run 2-3x over the original estimate.
When comparing bids, ask each agency: what is included in this scope document, and what would trigger a change order? Then look at the documents side by side. A fixed bid with a vague spec and a T&M bid with a detailed spec may actually represent the same risk -- just allocated differently.
Also compare hourly rates to the implied rate on a fixed bid. Divide the fixed price by the number of hours a similar project normally takes. If an agency quotes $50,000 for an MVP that takes roughly 400 hours to build, their implied rate is $125/hour. An AI-native team delivering the same scope for $8,000-$12,000 is not doing fewer hours of thinking -- they are spending far fewer hours on repetitive work that AI now handles. That gap is the legacy tax: the markup you pay an agency that has not updated its process since 2023.
| Pricing Model | Risk Sits With | When It Works | Watch Out For |
|---|---|---|---|
| Fixed price | Agency | Clearly scoped, stable requirements | Thin scope documents, expensive change orders |
| Time and materials | You | Exploratory projects, evolving scope | Weak estimation, slow teams, no budget ceiling |
| Fixed price with change orders | Shared | Most product builds | Vague definition of what counts as in scope |
What role does AI tooling play in an agency's efficiency today?
This question separates agencies that have adapted from those still billing 2024 rates for 2024 timelines.
Ask it directly: where does AI fit in your sprint cycle? The answer you want is specific -- something like: AI writes the first draft of standard features like login screens, form handling, and database connections; a senior developer reviews every line and focuses on what is unique to your product. That describes a workflow where AI handles the repetitive 60% of coding, and the human handles the decisions that matter.
The answer you do not want is vague: we use AI tools throughout the process. That could mean anything from genuine workflow integration to one developer occasionally using autocomplete.
Why does this matter so much? GitHub's 2025 research found developers using AI tools completed tasks 55% faster. McKinsey measured 30-45% improvement on complex engineering work. An agency that has genuinely embedded AI into its process is delivering the same output in roughly half the time -- which means either a lower price, a faster timeline, or both. One that has not is charging you for hours that an AI could have handled in minutes.
A concrete test: ask for a rough breakdown of how long their last comparable project took, week by week. An AI-native team can describe a 28-day MVP with a clear week-by-week account: discovery in week one, core build in weeks two and three, testing and launch in week four. A traditional team with a similar scope will describe a 10-14 week engagement, often with multiple weeks spent on planning before any build starts.
The agencies that figured this out early are compounding their speed advantage. The ones that have not are still quoting $50,000 for work an AI-native team ships for $12,000.
Which references and artifacts should I ask to see?
Case studies on an agency's website are marketing. References and artifacts are evidence.
Ask for two or three client references from projects in a similar category to yours -- same complexity, same type of product, similar timeline. Then call them. The questions worth asking: did the project ship on time, was the final cost within 15% of the original quote, and would you hire them again? The last one gets the most honest answer.
Beyond references, there are two artifacts worth requesting before you sign.
A sample scope document from a past project shows you how the agency defines requirements. You are looking for specificity -- every screen named, every user flow described, every feature defined well enough that you could hand it to a different team and they could build it. Vague scope documents predict overruns.
A technical handoff package from a completed project shows you what you actually receive when the engagement ends. It should include the full codebase, deployment instructions, environment setup, and documentation clear enough for another developer to take over without a three-hour onboarding call. If an agency's handoffs are thin or proprietary, your leverage after launch is limited.
| What to Ask For | What It Tells You |
|---|---|
| 2-3 client references, similar scope | Whether timelines and budgets hold in practice |
| Sample scope document | How precisely they define requirements before building |
| Sample technical handoff | What you actually receive -- and whether you can take it elsewhere |
| Team bios or LinkedIn profiles | Whether the people on the sales call are the people who build |
One last check: ask whether the team that will build your product is the same team presenting today. Some agencies win business with senior staff and then staff projects with junior developers the client has never met. The bait-and-switch does not always happen intentionally -- but it happens. Asking early makes the answer part of the record.
These questions take an hour. They can save you months.
