iThink Creatives
Checklist

10 questions to ask a developer or agency before you trust their estimate

What to ask before you sign, what a good answer sounds like, and what should make you pause. No technical background needed.

Updated ยท 5 min read

Short answer

Before you sign, ask how the estimate was built, what it leaves out, how changes will be handled, who will own the code and accounts, and how you will see progress along the way. How clearly and calmly a developer answers these tells you more than the price does.

Most founders compare quotes on price and timeline. Those are the two numbers a proposal is most likely to get wrong. The questions below get at the things that decide whether a project goes well: how honest the plan is, what you actually own, and how you will know if things are slipping.

You don't need to understand the technical answers. You need to notice whether the answers are clear, specific and written down. Vague answers now usually turn into expensive surprises later.

Prefer paper? Download the one-page PDF version to print or share with a co-founder.

01Can they explain the plan in plain language?

Ask them to walk you through what they will build first, second and third, and why that order. A good developer can translate. If they can't explain it to you now, while they are trying to win your business, it won't get easier later.

Good answerThey explain it in your words, check you followed, and connect each part to something your customers will do.
Red flagEvery answer is jargon, or you hear "don't worry, we'll handle all of that."

02What exactly is included in the estimate?

Ask for a written breakdown, not a single number. A lump sum with a one-paragraph scope is the easiest place for cost and scope to drift, because nobody can point to what was promised.

Good answerA list of features or phases, each with its own time or cost, plus the assumptions they made.
Red flagOne total, a short description, and pressure to sign quickly.

03What is explicitly not included?

The gaps matter as much as the scope. Common ones: hosting and server costs, third-party services (payments, SMS, email, maps), app store fees, bug fixes after launch, ongoing maintenance, content entry, and design changes after sign-off.

Good answerThey name the exclusions without being asked and give you a rough idea of what those will cost.
Red flag"Everything is included." It never is.

04How do you handle changes mid-project?

Your requirements will change. That's normal. What matters is whether there is an agreed way to handle it, so a small change doesn't quietly become a big bill.

Good answerYou ask, they tell you the impact on time and cost, you approve in writing before work starts.
Red flagChanges get absorbed without discussion and show up on the final invoice, or every change turns into an argument.

05Can I see and test work in progress, not just at the end?

Working software you can click through, every week or two, is the single best early warning system you have. Slides and screenshots don't count.

Good answerRegular demos on a test link you can open on your own phone, and access to their task board.
Red flag"You'll see it when it's ready."

Want someone experienced to look at your project? The first 15-minute call is free.

06Who will own the code and the accounts?

This is the question founders most often forget. The code should live in a repository (on GitHub, GitLab or Bitbucket) under your company's account, with you as an owner. The same goes for hosting, the domain, the database, app store accounts and every paid service the product uses. The contract should say the intellectual property transfers to you on payment.

Good answer"We'll set everything up under your accounts and add ourselves as members."
Red flag"We'll keep it under our accounts for now, it's easier." Easier for whom?

07What happens if I want to switch developers later?

Nobody likes asking this at the start, which is exactly why you should. Their reaction tells you a lot. See our guide on switching developers without losing your product for what a clean handover involves.

Good answerThey describe a handover: documentation, credentials, a notice period and help during the transition.
Red flagDefensiveness, or a custom in-house framework that only they can work with.

08How do you estimate time, and how often are you right?

Ask for a real example: a past project's original estimate and what it actually took. The gap, and how they explain it, tells you more than any number on your own proposal.

Good answerRanges rather than exact figures, honest past examples, and they point out which parts of your project are hardest to predict.
Red flagVery precise numbers with no uncertainty, or a claim that they have never missed a deadline.

09Is the setup right-sized for where we are today?

An early product needs the simplest setup that proves the idea and can grow later. Some teams build for a million users on day one, which costs more and slows you down. Others skip basics like backups and security. Ask what they would add later, and when.

Good answer"We'll start simple, here's what we'd change once you have real traffic, and here's how your data is backed up."
Red flagA long list of impressive-sounding tools for a product with no users yet, or no answer at all on backups.

10Would you be comfortable with someone else reviewing the work?

A confident team welcomes a second opinion. They know good work holds up. This is also a fair thing to agree on up front, so a review later doesn't feel like an accusation.

Good answer"Of course. We're happy to walk a reviewer through it."
Red flagResistance, or a claim that the code is confidential. You're paying for it. It's yours.

What to do if some answers worry you

One weak answer isn't a reason to walk away. A pattern is. If several answers were vague, try these before you sign:

  • Ask for the answers in writing. Clear commitments are easy to write down. Vague ones get harder to write.
  • Get a second quote using the same list of features, so you're comparing like with like.
  • Put ownership in the contract: accounts in your name, IP transfer on payment, and a handover clause.
  • Get an outside read of the proposal. An experienced technical person can often tell in an hour whether an estimate is realistic. That's one of the things an independent technical review covers.

Already signed and not sure how it's going? Read how to tell if your developer is doing a good job.

Written by iThink CreativesiThink Creatives is run by a technology leader with 15+ years leading engineering and data teams, including years on the client side of the table: managing outsourced projects, external vendors and consultants. Last updated 25 September 2026.

Not sure how your project is really going?

Book a free 15-minute call. Tell us what's happening and we'll tell you honestly whether a review would help. If it wouldn't, we'll say so.