Technical discovery calls that protect your product roadmap

Why custom deals derail the roadmap

Custom deals rarely wreck a roadmap because the request sounds huge. They usually wreck it because the request sounds small.

A sales call starts with a simple ask: add one approval step, connect one data source, change who can see a page. Everyone nods, the buyer wants a number, and the team treats it like a light change. The real work shows up later, after someone has already hinted at price and timing.

That gap usually starts with a vague conversation. The call stays at the demo level instead of the work level. People talk about features, but not about who does what, where the data lives, or what rules the company already follows. If nobody asks those questions early, hidden work slips into the deal.

Teams underprice custom requests for a simple reason: they estimate the screen, not the process. A new button may take a day. The business logic behind that button can take weeks.

The usual surprises are not dramatic. That is why teams miss them. One extra approval step can involve two departments. A messy spreadsheet import can turn into cleanup rules and a migration. A private dashboard can become a permissions project. Audit logs, retention rules, and buyer exceptions add work outside the original request.

This is where technical discovery calls matter. They slow the deal down just enough to expose the parts that cost time and money. That gives the team a chance to separate real product fit from a one-off request that pulls engineers away from planned work.

If a buyer needs manager approval, imported records from two old databases, and different access rules for finance and support, that work should surface before anyone quotes. Once it does, pricing gets more honest, timelines get safer, and the roadmap has a better chance of staying intact.

Ask about workflows

Most scope problems start with a bad assumption: "We already know how they work." Usually, you do not.

During technical discovery calls, ask the team to walk through one real task from start to finish using the way they work today, not the way they wish it worked. Pick a common job first. It might be creating an order, approving a refund, onboarding a customer, or sending a monthly report. Start with, "What starts this?" Then keep going until the work is fully done.

People often skip the messy parts unless you slow them down. Ask who starts the process, who checks it, who approves it, who finishes it, and which tool each person uses. Then ask where the work gets stuck. That last question often changes the estimate.

A workflow that sounds simple in a sales conversation can hide three manual checks, two spreadsheet exports, and a manager approval that only happens on Fridays.

Pay close attention to handoffs. Every time work moves from one person or team to another, there is a chance for delay, rework, or a hidden integration. If someone says, "Then finance updates the sheet," stop there. Ask which sheet, who owns it, how often they update it, and what happens if the numbers do not match.

Spreadsheets deserve extra attention. Teams use them to track exceptions, fill gaps in old systems, and fix data by hand. If a spreadsheet sits in the middle of the workflow, your project may need imports, exports, validation rules, or a review screen that was never part of the first quote.

Ask about the odd cases too. Not every order, request, or ticket follows the normal path. Returns over a certain amount, customers in a regulated region, or missing records from an older system can trigger extra steps. Those cases may happen only 5 percent of the time, but they can create half the build effort.

A good workflow map does not need to look polished. It needs to be specific enough that another person could follow the job without guessing.

Ask about data sources

Data work hides in boring places. A deal can look simple until you learn the team needs records from five tools, two shared drives, and a folder of monthly CSV files.

During technical discovery calls, ask for a full inventory of where the needed data lives. Do not stop at the main app. Teams often mention the CRM first and forget the billing tool, support desk, spreadsheets, partner portals, or files someone emails every Friday.

A few questions usually surface the real scope. Which systems hold the data this feature needs? Who owns each system inside the company? Who can approve access? How does the data move today, if it moves at all? Are there manual exports, uploaded files, or one-time migrations in scope?

Ownership matters more than many teams expect. If the data sits in a vendor tool, your buyer may not control the API, the rate limits, or even the export rights. If one analyst has the only admin login, your timeline now depends on that person.

Then check the data itself. Ask what format it comes in, how clean it is, and how often it changes. A table in PostgreSQL is one thing. A mix of JSON payloads, PDF attachments, and hand-edited spreadsheet columns is another. If names, IDs, or timestamps do not match across systems, someone must fix that before the product can use the data safely.

Update timing changes scope too. Real-time sync needs a different design than a nightly import. A dashboard that refreshes every morning may be easy. A workflow that must react in 10 seconds can need queues, retries, monitoring, and failure handling.

One-off files deserve extra scrutiny. They sound harmless, but they create custom work fast. A client may say, "We only need to import this spreadsheet once." In practice, that often becomes a recurring exception with new column names every month.

If you leave the call with a clear map of systems, owners, formats, and update timing, custom software pricing gets much closer to reality. If you skip those questions, the hidden work usually shows up after the deal closes.

Ask about security needs

Security questions feel slow until they add three weeks of work.

A client may say "simple internal tool," then mention employee records, payment data, or customer contracts halfway through the call. That one detail can change hosting, login, logging, and who must approve the build.

Start with the data itself. Ask which records would cause real damage if someone saw, changed, or deleted them. Names and email addresses matter, but payroll files, health details, contract terms, support tickets, and internal notes often need tighter handling. If they share files with outside partners, ask who sends them, where they live now, and who can download them.

Then ask who needs access. Many teams say "all managers" when they actually mean five different roles with different limits. One person can view everything, another can edit only their region, and finance may need exports but not raw notes. Small differences like that create extra screens, approval rules, and audit logs.

Four questions usually expose the hidden work:

• Which data needs extra protection, and why?
• Who can view, edit, export, approve, or delete records?
• Do you need an audit trail that shows who changed what and when?
• How long must you keep data, and what happens when someone asks you to delete it?

After access rules, ask about reviews outside the product. Some companies need legal, compliance, IT, or security teams to approve vendors before launch. That can affect the timeline more than the code does. A security questionnaire, penetration test, single sign-on requirement, or data processing agreement may appear late if you do not ask early.

This matters in technical discovery calls because security scope hides inside casual phrases. "We just need admin access" can mean a full role matrix. "We store customer history" can mean retention rules for seven years. "Our IT team needs a look" can mean a month of review. Price the work after you hear those details, not before.

Run the call in order

Good technical discovery calls stay narrow. Start by asking for the business goal in one plain sentence. If the room cannot do that, the rest of the call will drift into guesses, wish lists, and bad custom software pricing.

A good goal sounds like this: reduce manual order entry, cut response time for support, or give managers one place to approve requests. Short is better. It gives everyone the same target.

Then move through the current process in real order. Ask where the work starts, what happens next, who touches it, where people wait, and how the work ends. Simple workflow mapping often reveals more scope than any feature list.

A practical sequence works well:

1. Write down the business outcome and how the team will judge success.
2. Walk through the current process from start to finish using a real example.
3. Name every system, user group, and exception that changes the normal flow.
4. Pause and summarize the risks, unknowns, and extra work before you discuss timing or price.
5. End with the open questions, who owns each answer, and when they will reply.

When you ask about systems, do not stop at product names. Ask what data goes in, what data comes out, who edits it, and how often it breaks. A short data source review can uncover imports, exports, old spreadsheets, shared inboxes, and manual checks that nobody mentioned at the start.

Users and edge cases matter just as much. One team may say, "Only sales uses it," then remember finance needs reports, legal needs an audit trail, and managers need approval rules. That changes the build.

Bring up security requirements before numbers. Ask who can see customer data, whether outside contractors need access, whether the company needs single sign-on, and what happens if a mistake changes or deletes records. These answers affect design, testing, and support from day one.

Before the call ends, repeat the risks in plain language. If three things still need answers, name all three and assign owners. That small habit saves weeks of rework later.

A simple example of hidden work

A client asks for "a simple onboarding flow" for new customers. On paper, it sounds small: a form, a place to upload documents, and a button that sends the record to sales. A rough quote might land at 30 hours because the request looks like basic app work.

Then the discovery call starts, and the small job stops looking small.

The form is not one form. If the customer is a sole trader, they need one set of fields. If they are a company, they need another. If they operate in two countries, the tax fields change again. One answer turns other questions on or off, and some fields need rules that block bad entries before the user can continue.

The document step adds more work. The client wants users to upload ID, proof of address, and a signed agreement. Some files need manual review. Others need checks such as file type, size limits, and whether the name on the ID matches the name in the form. If a file is missing or unclear, the system has to ask for a new upload instead of moving the case forward.

The request also touches three other systems: the CRM needs a new contact or company record, the files need secure storage with access controls, and an approval step needs routing to sales, compliance, or both.

That changes the build in a big way. Now the team has to map field names between systems, handle failed syncs, track approval status, and keep an audit trail so staff can see who approved what.

Security work shows up fast when personal data enters the picture. ID files, addresses, phone numbers, and signatures cannot sit in an open folder or move through email. The client may need role-based access, retention rules, activity logs, and clear consent text in the form.

The first quote was 30 hours. After the call, the real scope is closer to 120 hours, plus testing across edge cases and user roles. That gap is exactly why technical discovery calls matter. The hidden work was always there. The call simply exposed it before pricing locked everyone into a bad deal.

Mistakes that hide scope

The fastest way to miss scope is to start with screens and buttons. When a buyer asks for "a dashboard" or "an approval flow," many teams jump straight into features. That feels efficient, but it hides the messy part: who does what, in what order, and where work breaks today. A short process map often exposes manual reviews, exception paths, and side conversations that add weeks.

Another common mistake is asking one person to explain the whole operation. Managers describe the intended process. The people doing the work know the shortcuts, delays, and patch jobs. Sales may say orders come through the CRM, while operations quietly pulls missing details from email, spreadsheets, and chat. If you price from one viewpoint, you price the happy path and miss the real one.

Old systems create even more hidden work. Teams forget shared inboxes, exported CSV files, legacy databases, and the spreadsheet someone updates every Friday because nothing else connects to finance. Those odd pieces drive integration effort, cleanup rules, and testing. In many technical discovery calls, this is where the real cost shows up.

Security gets pushed aside too often. That can reshape the whole build. If the customer needs SSO, audit logs, role limits, approval trails, or a vendor review, you need that on the first call. Security requirements can change architecture, not just paperwork.

The last mistake is leaving with open questions but no owner for each one. Then everyone assumes someone else will check the API limit, confirm data retention rules, or find out who approves access. A vague follow-up note does not fix that.

Before the call ends, lock down a few basics. Confirm who owns the current workflow, who owns each data source, who answers security questions, which assumptions affect pricing, and when the missing answers will arrive.

This kind of disciplined review is where an experienced outside technical lead can help. Oleg Sotnikov does this work with startups and growing teams through oleg.is, especially when hidden dependencies around infrastructure, permissions, or process design keep slipping into deals late.

Check before you price

Before you send a number, stop and look for blanks. Most bad deals do not start with a bad estimate. They start with missing facts about how the work actually happens, which systems are involved, and what rules the product must follow.

A short review at the end of technical discovery calls can save weeks of rework. If the team cannot answer these points clearly, the scope is still moving:

• Can you describe the full workflow from first action to final result, including handoffs and common exceptions?
• Have you named every system involved, even the messy ones like spreadsheets, shared inboxes, and manual exports?
• Do you know who can view, edit, approve, and reject at each step?
• Do you know which data needs extra protection, such as customer records, financial details, or internal notes?
• Can you list the open questions and name who will answer each one?

If two or more answers feel vague, fixed pricing is a gamble. A range is safer. In some cases, paid discovery is the honest choice, especially when the client says the request is simple but the team still cannot map the path from input to output.

A small example shows why this matters. A company asks for a "simple dashboard" for order status. After a proper check, you learn the screen must pull data from a CRM, an old warehouse database, and a finance tool. Managers must approve some status changes. Support staff can view orders, but only finance can see refunds. Customer addresses also need tighter protection than the rest of the record. That is no longer a small add-on.

Write down what you know, what you do not know, and who owns the missing answers. Then price the work after those answers arrive. That habit protects margins, reduces surprises, and keeps the roadmap from filling up with custom work nobody fully understood.

What to do next

A discovery call only helps if the notes turn into something your team can price and build. Right after the call, write a short scope summary in plain language. Keep it tight. State what the client wants, which systems are involved, who will use the work, and what has to happen before launch.

Many technical discovery calls feel thorough, then fall apart because the estimate hides the team's assumptions. Put those assumptions next to the number, not in a separate doc nobody checks. If you assume clean API access, one approval flow, or no migration work, say that clearly.

A short handoff note should cover four things: the scope summary, the assumptions behind the estimate, the risks that can move timing or cost, and the open questions that still need answers.

Do not bury risk inside a padded estimate. Name it. If the client says their team can export the data, but nobody knows the format, size, or cleanup work, that is a risk. If legal or security review may add two weeks, write that down before you send pricing.

This is also the point where outside help can save you from a bad deal. If custom requests keep slipping past discovery and landing on the roadmap half-scoped, bring in an experienced Fractional CTO before you commit. A second technical read often catches work your team missed around integrations, infrastructure, permissions, and support load.

That is the kind of advisory work Oleg Sotnikov focuses on. His background spans startup product architecture, software delivery, infrastructure, and AI-first development, so if your team needs a sharper technical read before pricing, a review like that is often cheaper than fixing an underpriced project after the contract is signed.