A client sends you an exciting project brief. You read through it, get genuinely interested, and then ask the inevitable question: “What’s your budget?” They reply: “We’re not sure yet — what do you think it should cost?” And just like that, you’re stuck holding the bag.

This situation happens constantly in software development. Clients often have no idea what their project costs. That doesn’t mean you can’t price it confidently. It means you need a reliable process to do it for them — one that protects your margin and builds their trust at the same time.

Table of contents

  1. Why Clients Have No Budget (And Why That’s Okay)
  2. Ask the Right Discovery Questions First
  3. Use Scope-Based Estimation Instead of Guessing
  4. Present Price Anchors and Tiered Options
  5. Protect Yourself With Assumptions and Change Clauses
  6. Checklist
  7. FAQ

Why Clients Have No Budget (And Why That’s Okay) {#why-clients-have-no-budget}

Most developers treat a budget-less client as a red flag. It doesn’t have to be. Understanding why they have no number helps you respond better.

They genuinely don’t know what software costs

Your client might be a founder building their first product. They’ve never hired developers before. They have no reference point. This is common. It’s not a negotiation tactic — it’s ignorance of the market.

They’re testing the water

Some clients do have a number in mind but won’t reveal it. They’re worried you’ll inflate your quote to match their ceiling. This is a trust issue, not a budget issue. Your job is to build enough credibility that they feel safe sharing the real number.

Their internal budget isn’t approved yet

In larger companies, project managers sometimes scope the work before finance signs off. They need your quote to complete their internal business case. In this situation, they genuinely can’t tell you a number because it doesn’t exist yet.

What this means for you

In all three cases, the correct move is the same: lead with a process, not a price. Show them you know how to define scope and derive cost from it. That earns trust faster than any low-ball quote.

Ask the Right Discovery Questions First {#ask-discovery-questions}

Before you estimate anything, you need raw material to work with. A vague brief produces a vague quote. A vague quote creates disputes, scope creep, and unhappy clients.

The four categories of discovery questions

Every project needs answers across four areas before a number makes sense:

Goals — What problem does this software solve? What does success look like in six months? These answers reveal the real complexity hiding behind a simple-sounding request.

Users — Who will use it? How many? What devices? A tool used by five internal staff members is a very different project from a consumer app targeting thousands of users on day one.

Features — What must the product do to be useful? Separate the must-haves from the nice-to-haves. Push the client to make that distinction clearly. It’s one of the most valuable things you can do in early conversations.

Constraints — Are there deadlines? Existing systems to integrate with? A specific tech stack required? Compliance requirements? Each constraint adds cost. Most clients don’t volunteer this information unless you ask directly.

The one question that changes everything

Ask: “If you had to launch with only three features, what would they be?”

This forces prioritization. It reveals what the client actually values. And it gives you a foundation for a realistic MVP scope rather than a bloated wish list.

Use Scope-Based Estimation Instead of Guessing {#scope-based-estimation}

Once you have discovery answers, you can build a proper estimate. Scope-based estimation means pricing the work, not the client’s perceived value.

Break the project into functional units

Stop thinking about a “project price” as one big number. Break the work into components: authentication, dashboard, user management, API integrations, notifications, admin panel, deployment setup, and so on.

Estimate each component separately. Assign hours. Multiply by your rate. Add them up. Now you have a number you can defend line by line.

Build in estimation buffers

Every component should carry a buffer. For well-understood work, use 15–20%. For anything involving third-party APIs, legacy code, or unclear requirements, use 30–40%. This isn’t padding. It’s professional risk management.

Use a tool to speed up the process

Manual estimation in spreadsheets takes time and introduces inconsistency. Tools like devtimate’s AI cost estimation let you generate structured project estimates quickly. You input the project type, features, and complexity — it outputs a detailed breakdown you can present directly to a client or use as your internal baseline.

Separate discovery from delivery pricing

If the scope is genuinely unclear after your initial conversation, don’t guess. Price a paid discovery phase first. A one-to-two week scoping sprint for a fixed fee gives you the information you need to quote the full project accurately. It also filters out clients who aren’t serious.

Present Price Anchors and Tiered Options {#price-anchors-and-tiers}

How you present a price matters as much as the price itself. A single number with no context is hard for a client to evaluate. A structured presentation makes your quote feel considered and fair.

Use the three-tier approach

Present three scopes, not one:

Tier 1 — MVP: The smallest version of the product that delivers core value. Fast to build. Lower cost. Enough to validate the idea.

Tier 2 — Standard: The recommended option. Includes the essential features plus key quality-of-life elements. This is usually your target.

Tier 3 — Full build: The complete vision. All features, polished UX, full integrations. Higher cost, longer timeline.

Most clients pick Tier 2. But showing all three does something important: it makes your recommended option look reasonable by comparison. And it gives the client a sense of control.

Anchor with market context

If the client has truly no reference point, give them one. Tell them: “A project like this typically ranges from X to Y in the market. Here’s where we land and why.” This contextualizes your number without requiring you to justify every hour.

Show the cost of doing nothing

Clients who hesitate on price often haven’t thought about what the problem costs them right now. If their manual process wastes ten hours a week, and a team member costs $50 per hour, that’s $26,000 per year in lost productivity. Your $40,000 quote starts looking different.

Protect Yourself With Assumptions and Change Clauses {#protect-with-assumptions}

Pricing without a client budget means you’re working with incomplete information. You need to document your assumptions so you’re protected when the scope shifts.

Write explicit assumptions into every quote

Your quote should include a section called “Assumptions” or “Basis of Estimate.” List exactly what you’re including — and what you’re not. For example:

When the client later asks “why does adding X cost extra?”, you have a clear answer: it wasn’t in scope.

Use a change order process from day one

Tell clients upfront that any work outside the agreed scope will be handled through a formal change order. Describe the process briefly. This isn’t adversarial — it’s professional. It protects both parties.

Build milestone-based payments

Never quote a lump sum payable on completion for a fixed-price project. Break payments into milestones tied to deliverables. Discovery, design approval, development completion, testing, and launch are natural checkpoints.

This reduces your financial risk. It also gives the client regular proof of progress, which builds confidence and reduces the likelihood of disputes.

Know when to walk away

Some projects can’t be priced responsibly because the scope is too undefined. If a client refuses a paid discovery phase, won’t answer basic questions, and insists on a firm price for a vague brief — that’s a warning sign. A project you can’t scope accurately is a project you’re likely to lose money on. Saying no early is sometimes the most profitable decision you can make.

Checklist

✅ Conduct a structured discovery session before writing any estimate ✅ Break the project into functional components and estimate each one separately ✅ Add appropriate buffers based on uncertainty level (15–40%) ✅ Present three pricing tiers — MVP, standard, and full build ✅ Document all assumptions explicitly in your quote ✅ Include a change order clause for out-of-scope work ✅ Structure payments as milestones, not a single lump sum ✅ Use an estimation tool to speed up your process and reduce guesswork

FAQ

1. What should I do if a client absolutely refuses to share their budget? Don’t push too hard — it creates friction early. Instead, run your own scope-based estimate and present it with the three-tier option structure. If they have a ceiling, the tiered presentation will naturally surface it when they react to your numbers. You’ll learn their budget through their response even if they never say it outright.

2. Is it ever okay to ask the client to name a number first? Yes. You can frame it professionally: “To make sure I’m building the right scope for you, it would help to know the range you’re working with. Even a rough figure helps me focus on the right solution.” Most clients will respond reasonably to that framing. It’s direct without being pushy.

3. How do I avoid underpricing when I have limited information? Build your estimate from the bottom up — component by component — rather than picking a round number based on instinct. Add explicit buffers for uncertainty. If you’re still unsure, price the discovery phase as a separate engagement before committing to a delivery price.

4. Should I charge for the initial discovery and scoping work? For small, clearly-scoped projects, a free discovery call is reasonable. For anything complex or ambiguous, yes — charge for a scoping sprint. Paid discovery filters out unserious clients, funds your thinking time, and produces a far more accurate estimate for both parties.

5. What if my estimate is much higher than what the client expected? This happens. Don’t panic and don’t immediately discount. Walk them through the scope breakdown so they understand what drives the cost. Then offer the MVP tier as a starting point. If the gap is still too large after that, the project may genuinely not be the right fit — and that’s valuable information to have before you’ve invested weeks of development time.

Pricing software projects without a client budget is a skill, not a guessing game. The process is straightforward: ask good questions, scope the work carefully, present structured options, and document every assumption. Do that consistently and you’ll close more deals at better margins — with fewer disputes down the road.

If you want to speed up the estimation part, try devtimate.com/ai-cost-estimation. It helps you generate detailed, professional estimates in minutes — so you can spend less time building spreadsheets and more time closing projects.