Pricing technical discovery without draining engineering time

What goes wrong when discovery stays free

Free discovery rarely stays small. A sales call turns into "just one more estimate," then an engineer loses half a day reading notes, joining meetings, and guessing at risks nobody has mapped yet. The team calls it helpful. The calendar calls it lost build time.

The first problem is timing. Sales wants numbers before scope exists, so engineers get pulled in too early. They are asked for effort, dates, and technical answers while basic questions are still open: what needs to be built, what must connect, who owns the data, and what "done" even means.

That guesswork creates fake certainty. A rough answer from an engineer often becomes a promise in the client's notes. Later, when the hard parts show up - old APIs, messy permissions, missing requirements, unclear workflows - the team looks slow or expensive even though nobody had enough information to estimate well.

Free discovery also grows by itself. A 30-minute intro becomes a follow-up workshop, then a security review, then a small prototype to check feasibility. None of those requests sounds unreasonable on its own. Together, they can eat a full sprint.

Meanwhile, roadmap work slips. Product tasks move back because senior engineers keep jumping into presales requests, and those requests usually need the same few people every time. Small teams feel this fast. One or two unpaid investigations can push real customer work into next week, then next month.

Clients learn from the pattern too. If you answer one deep technical question for free, many will assume the next round is free as well. After every call, they expect another estimate, another review, another opinion. The boundary keeps moving, and your team trains the client to expect more unpaid work.

That is why paid discovery matters. It is not about being difficult. It protects engineering time, keeps the roadmap intact, and makes sure promises rest on facts instead of hopeful guesses.

What belongs in a paid discovery package

A paid discovery package works best when it answers one business decision, not every open question. If the client wants to know whether a product can launch in 12 weeks, keep the work aimed at that. If they want a migration plan, make that the goal instead.

Start with scope, not a day rate. The fee feels fair when the client can see a clear boundary around the work and a clear result at the end.

Set a fixed time box before anyone starts. For most software deals, 5 to 10 working days is enough to inspect the current setup, talk to the right people, and write a useful recommendation. Longer than that, and discovery starts turning into design work or early delivery.

Write down the exact questions the team will answer. Keep them concrete: what problem should be solved first, what systems or teams affect the work, what blocks delivery or cost, what can be estimated now with confidence, and what should wait because the risk is still too high.

That list does two jobs. It keeps engineering focused, and it gives sales something real to sell instead of vague "assessment" language.

The package also needs hard exclusions. Say plainly that discovery does not include feature work, production fixes, deep implementation, or half-day workshop marathons with every stakeholder in the company. A couple of short sessions are fine. Six sprawling meetings usually mean the client wants consulting without calling it that.

Choose a small team on purpose. Sales should manage the commercial side and keep the goal clear. Product should test business needs and priorities. Engineering should join only where technical judgment changes the answer. In many cases, one senior engineer or a fractional CTO is enough for the technical part. Pulling in three developers too early is expensive and rarely useful.

A strong package leaves the client with a decision document, a rough plan, known risks, and a realistic next step. That is enough to buy with confidence, and small enough to protect the roadmap.

When to move from sales talk to paid work

A sales conversation should confirm fit, budget range, timeline, and whether the problem is real. Once your team starts inspecting systems, shaping architecture, or answering questions that depend on technical review, the work has moved into paid discovery.

The best moment to make that switch is right after the first strong fit call. If both sides agree the project is real and worth pursuing, do not keep digging for free. Free calls help qualify. Paid work helps define what will actually be built.

Custom integrations are usually the clearest line. A basic website, simple app, or standard setup may only need a light presales chat. The moment a prospect says they need Salesforce, SAP, an ERP, an internal API, or a legacy database tied in, the risk jumps. That work needs investigation, and investigation has a price.

The same applies when an estimate needs more than rough numbers. If your team must review sample data, inspect logs, sketch system diagrams, or check security and compliance limits before giving a reliable quote, stop calling it presales. It is project work.

One warning sign gets missed a lot: the same engineer joins twice. The first call can make sense if sales needs help checking fit. A second technical session usually means the prospect is already consuming delivery time. At that point, the roadmap starts paying for someone else's uncertainty.

A simple rule helps sales hold the line without sounding defensive:

• The first fit call is free.
• If engineering needs to inspect, map, or validate, discovery is paid.
• If custom integrations appear, discovery is paid.
• If a quote depends on diagrams, sample data, or a second technical session, discovery is paid.

Most prospects accept this when you say it early. It also protects your best people from spending half their week on deals that may never close.

In practice, advisors and fractional CTOs often use this boundary to keep delivery teams focused. It is one of the simplest ways to protect roadmap time without making sales feel blocked.

How to price discovery

Start with a fixed fee, not an hourly guess. The first package should feel small, clear, and easy to approve. For most teams, a short paid discovery package works best when it covers one defined problem over 5 to 10 business days.

Name the deliverables before you name the price. If the client gets an architecture note, scope summary, risk list, rough effort estimate, and recommended next steps, the fee feels concrete. If you skip that step, the price sounds like you are charging for conversations.

A simple pricing method

Use a short time box and price the package around the real effort inside it.

1. Set the time box first.
2. List the exact outputs the client will receive.
3. Count the senior hours needed for meetings, review, writing, and internal discussion.
4. Set one fixed fee, then define the rate for anything outside the package.

This is where teams usually get it wrong. They count only workshop hours and forget prep, internal review, writing, and follow-up questions. A senior engineer may spend 2 hours in meetings and 6 more turning messy facts into something useful.

Then check the fee against your real cost, not your hope. Use the loaded cost of the people involved, especially if a staff engineer, architect, or fractional CTO joins the work. If senior staff time costs your company $150 an hour and discovery takes 12 hours total, your floor is already $1,800 before margin.

A fixed fee also needs a fence around it. Put the scope in writing and add a clear rate for anything outside it. Extra stakeholder interviews, deep code review, vendor comparisons, or revised estimates after major scope changes should move to a separate hourly or daily rate.

A simple example makes the math clear. Say a one-week discovery includes two calls, one system review, a written findings document, and a build estimate. The team expects 10 senior hours and 3 hours of coordination. At a real internal cost of $160 an hour, the work costs $2,080. Pricing that package at $2,500 is sensible. Pricing it at $900 is presales engineering time wearing a nicer shirt.

If the number feels high, shrink the package before you cut the fee. Smaller scope protects the roadmap better than cheaper senior time.

Deliverables that make the fee feel fair

A discovery fee feels reasonable when the client can point to a small set of concrete outputs and say, "Yes, we can use this." If they only get meetings, loose notes, and a vague estimate, they will treat the work as expensive presales.

Good deliverables reduce uncertainty. They also save your engineering team from repeating the same early investigation after the deal closes.

A solid package usually includes five things: a short problem statement in plain language, a simple map of the current process and the proposed change, a list of assumptions and risks, a rough architecture sketch with integration notes, and a cost range with a first delivery plan.

Each item should help the buyer make a decision. The problem statement aligns the internal team. The process map exposes gaps. The risk list shows what could block progress. The architecture sketch proves that you looked at the real constraints, whether that means legacy systems, third-party APIs, team handoffs, or security rules.

The estimate should stay honest. A range like "$40k to $70k for phase one" is better than a single number you know will move later. Pair it with a first delivery plan such as "4 weeks, one product lead, two engineers, weekly review," and the client can see how the work starts.

Once the outputs are clear, the fee feels easier to defend. You are not charging for "thinking." You are charging for a decision package that cuts waste on both sides and protects the roadmap from open-ended presales work.

A simple example from a software deal

A buyer asks whether your software can "just connect" to their ERP so orders sync each night. Sales hears a small add-on: one API, a few field mappings, maybe a week of work.

A senior engineer joins the first call and spots the real issue fast. The buyer's ERP treats one company as several billing entities, while your product stores one customer record with a simpler account structure. The field names look close enough, but the data model is different.

That changes the job. The team now has to sort out duplicate records, old contracts, tax rules, and which system owns each field after the sync starts. Support has limits too. If the buyer expects custom alerting, weekend coverage, or hands-on migration help, the normal support plan does not cover that work.

Instead of pulling more engineers into free meetings, the company offers a short paid discovery package. One product lead and one engineer handle it over five business days. The main engineering team keeps moving on roadmap work.

By the end, the buyer gets a scope document with the integration flow, migration tasks, and open risks; a staged estimate for the first release, follow-up work, and ongoing support; a short list of buyer responsibilities such as test access and sample data; and clear limits on support, monitoring, and post-launch fixes.

That fee feels fair because the buyer leaves with something concrete. They can take the scope document to procurement, compare phases, and decide whether the project still makes sense.

The company gets clarity too. It can see whether the deal fits its product, whether the margin still works, and whether the request belongs in the roadmap later.

If the team kept discovery free, it could lose 20 to 30 engineering hours before anyone understood the real scope. Paid discovery works best when it catches this kind of hidden complexity early. Sales stops guessing, engineering time stays protected, and one small group handles the investigation without slowing the rest of the business.

Mistakes that drain engineering time

Most mistakes start before anyone sends a proposal. Sales wants momentum, the client wants answers, and engineering gets pulled in to keep the deal alive. That feels helpful for a week. Then the roadmap slips.

One common error is letting sales promise free technical workshops. A single workshop rarely stays single. It turns into follow-up calls, architecture sketches, rough estimates, and message threads that nobody scoped or approved. At that point, your team is doing discovery work without the fee.

Pulling senior engineers into every early call is another fast way to burn time. Senior people should join when a real buying process starts, not when a prospect is still comparing options. If your best engineer spends four hours a week on uncertain deals, that cost lands on active customers.

Treating discovery as a discount on delivery creates a different problem. Clients stop seeing discovery as real work with its own value. Your team still investigates risks, reviews systems, and writes recommendations, but the fee looks optional. That setup attracts people who want free thinking before they commit.

Vague notes make it worse. If the output is a loose recap email, clients will keep asking for clarification because they do not feel they received a finished piece of work. Named outputs set a boundary and cut down the back-and-forth.

A cleaner rule set is simple. Sales handles early qualification. One technical lead joins only after budget and need are clear. Discovery has fixed outputs and a fixed end date. New questions after sign-off start a new package.

The last mistake is the quiet one: continuing to answer questions after the package ends. Teams do this to be polite. Clients read it as part of the fee. Two extra calls and three extra emails can eat half a sprint.

Small software firms run into this a lot. The team says presales is "just a few chats," but those chats keep dragging senior people away from delivery. Put a line around the work, name the deliverables, and stop doing unpaid consulting in pieces.

A short checklist before you send a proposal

Before you send a paid discovery proposal, stop for ten minutes and test it like an engineer would. Most bad discovery work starts with a package that sounds fine on a call but turns fuzzy the moment someone asks, "What exactly are we buying?"

A short review catches most of the waste:

• Confirm the basics: who will buy, what problem they want fixed, and when they need an answer.
• Define the output in plain language and keep each deliverable easy to name.
• Put hard limits on time, meetings, and revision rounds.
• State what sits outside the fee.
• Give one person final approval before the proposal goes out.

A simple test helps. Hand the proposal to someone who was not on the sales call. Ask them what the client will receive, how long it will take, and what happens if the client asks for more. If they hesitate, rewrite it.

Say a prospect wants an AI workflow audit for their support team. A tight package might promise two interviews, one process map, one risk summary, and a budget range within five business days. It should also say that the fee does not include prompt building, tool setup, or staff training. That kind of boundary keeps the roadmap safe and makes discovery pricing much easier.

When this checklist becomes routine, engineering spends less time guessing and more time building.

What to do next

Start with one document your sales team can use without asking engineering for help. Keep it to one page. State what the discovery covers, what it does not cover, how long it takes, who joins, and what the client gets at the end. If your team cannot explain the offer in a few plain sentences, it is still too fuzzy.

The package should feel concrete. Promise a fixed set of outputs, not open-ended access to your engineers. A short architecture note, a risk list, an estimate range, and a clear recommendation are usually enough.

Then measure the leak. On your next five deals, track every hour engineers spend before a contract starts. Include calls, messages, rough estimates, diagram reviews, and follow-up questions. Many teams guess this number and guess wrong. Once you see the real cost, paid discovery stops sounding awkward and starts looking normal.

Train account leads to spot the moment free scoping should end. That moment usually comes when the buyer asks for technical options, delivery planning, integration review, or custom risk analysis. Sales can still lead the conversation, but they should know when to pause and move the work into a paid step.

A short rollout plan is enough:

• Write the one-page offer and test it on one live deal.
• Set a rule for how many free engineer hours a deal can use.
• Review the next five deals and log presales engineering time.
• Give sales a short script for moving from free calls to paid discovery.

If the same problems keep coming back, an outside review can help. Oleg Sotnikov at oleg.is advises startups and small teams on product architecture, infrastructure, and AI-first software delivery, and this kind of presales drift is exactly the sort of operational leak a fractional CTO can spot quickly.

Make the offer small, clear, and repeatable. That is usually enough to protect roadmap time and keep good sales conversations moving.