Sales promises custom work: how a CTO prices requests

Why this keeps happening

Most teams do not create this problem on purpose. It starts because sales works on a shorter clock than everyone else. A rep is on a live call, a buyer wants an answer now, and saying "we can probably do that" feels safer than saying "we need to check."

That one sentence causes trouble fast. When sales commits before anyone prices the request, the company starts negotiating against its own guess. The buyer hears confidence. The team inherits risk.

Product often hears only the surface version of the ask. They hear "one extra workflow" or "a simple integration" and assume it fits the roadmap. What they do not hear is the chain behind it: admin controls, edge cases, support load, security review, billing changes, and the risk that one custom feature pulls the product in a new direction.

Engineering usually gets the details too late. By the time the request reaches them, it has already turned into a near commitment instead of a question. That changes the discussion. Engineers are no longer asked, "Should we do this?" They are asked, "How fast can you make this happen?"

A small example makes the pattern obvious. A prospect asks for a "custom approval step" before orders go through. Sales hears a checkbox. Product hears a workflow option. Engineering later finds role logic, audit logs, notifications, exception handling, testing, and support docs. What sounded like a tweak is now a real project.

The deeper problem is ownership. Sales owns the relationship, product owns the roadmap, engineering owns delivery, finance cares about margin, and support deals with the aftermath. When decision rights are spread across five people, the default answer becomes a soft yes.

That is why the same conflict repeats. The company has no clear owner who can turn a vague ask into a business decision with scope, cost, timing, and tradeoffs. A CTO often fills that gap. A fractional CTO can do it too. The job is not to kill deals. The job is to stop wishful thinking before it turns into a deadline nobody can defend.

What a technical no actually does

A technical no should not shut down the customer. It should stop the team from agreeing to the wrong version of the request.

That sounds small, but it changes everything. A customer may ask for a custom workflow, a special report, or a copy of how their old system worked. A good CTO does not answer with a flat "no" unless the idea truly makes no sense. They translate the ask into versions the company can build, support, and price without regret.

Most sales problems start when one demand gets treated like one obvious job. It rarely is. A CTO breaks it apart and asks what the client is really trying to fix. Do they need faster approvals, one export format, or a whole new module? Those are different jobs with very different costs.

Once the real need is clear, the team usually has four possible paths. They can use a workaround with the current product, build a small paid extension with firm limits, turn the request into a broader product feature, or treat it as a fully custom build with custom pricing and support terms.

That is what the technical no actually does. It turns "Can you do this?" into "Which version do you want, and what are you willing to pay for?"

A CTO also shows the impact that sales cannot see on the call. One request may look easy but create months of support work. Another may take longer to build but fit the product well and help future deals. The team needs both sides of that picture before anyone promises delivery.

Sales also needs plain language for the next customer call. Sometimes the right answer is, "We can do this as a small custom add on in three weeks, but it will stay outside the standard product." Sometimes it is, "We can cover the same outcome with a simpler change now, then fold the larger version into the product later." Those lines protect trust because they are honest.

If the company does not have CTO coverage, a fractional CTO can handle this just as well. Sales gets a safe answer, delivery gets clear scope, and vague promises stop turning into expensive surprises.

Questions to ask before saying yes

A fast yes feels helpful on a sales call. It usually creates trouble a week later. Before anyone promises custom work, someone needs answers about the problem, the users, the product fit, the technical limits, and the date.

Start with the problem, not the requested feature. If a buyer asks for a custom dashboard, ask what they cannot do today. They may want fewer manual updates, cleaner reporting, or proof for an audit. Those are different needs, and they rarely need the same build.

Then ask who will use it and how often. A screen used by one operations manager once a month should not get the same treatment as a workflow used by 80 account reps all day. The more often people touch a feature, the more exceptions appear. That changes design, testing, support, and price.

A short set of questions keeps the call honest: What exact problem will this change solve? Who uses it, and how often? Does it fit the product you already sell, or does it create a special branch for one client? Which data sources, integrations, permissions, and compliance rules are involved? What deadline matters, and what business event makes that date real?

The product fit question saves a lot of pain. Some requests improve the product for many customers. Others bend the product around one client's internal process. That does not always mean no, but it should change the price, ownership, and support terms.

Data and security questions often expose the real size of the work. A request may sound small until you learn it touches a CRM, an ERP, customer records, and approval rules across teams. At that point, the work is no longer a simple feature. It changes how systems connect and who can see what.

Deadlines need the same pressure test. "We need it this quarter" is vague. "Our contract starts on July 1 and training begins two weeks earlier" is real. A CTO slows the conversation down just enough to get those details. That pause can save months of rework and one very awkward delivery call later.

How a CTO turns a vague ask into options

A CTO starts by removing the fog. "The customer wants something custom" is too loose to price. "The customer needs invoices to sync into their ERP every night without manual export" is clear enough to discuss.

That single sentence matters more than it looks. It forces sales, product, and engineering to agree on the outcome before anyone talks about dates or price. Guessing stops there.

Next, the CTO splits the request into two parts: what the deal actually needs and what would simply be nice to include. Sales teams often mix both together because the buyer says them in one breath. If nobody separates them, the company ends up pricing the whole wish list.

A good review also looks beyond the feature itself. Is this new code, a small change, or just configuration? Does it need extra hosting, monitoring, security rules, or access setup? Who trains the customer, answers tickets, and maintains it later? Do contract terms need to change because of uptime promises, data rules, or custom support?

After that, the CTO writes real options instead of a single vague yes. One option should use the current product as much as possible. Another can add a narrow custom layer. A third can describe a broader custom build with ongoing maintenance. Each option needs three labels next to it: effort, timeline, and owner.

Effort tells finance what they are paying for. Timeline tells sales what they can safely promise. Owner tells everyone who will carry the work after the deal closes. If nobody owns an option after launch, it should not go into the proposal.

A fractional CTO can often do this in one working session with sales and engineering. The result is simple: fewer surprise builds, cleaner quotes, and choices the company can defend when the customer pushes back.

A realistic example from a sales call

A buyer is close to signing. During the final call, they ask for a special approval flow so purchase orders over $10,000 need manager sign off before release. The account executive hears a large contract and says, "Yes, we can do that."

On the surface, it sounds like one extra screen and a button. It rarely is.

A CTO joins the next call and asks a few plain questions. Who can approve? Do rules change by department? Do rejected requests need comments? Does the buyer need a full audit log? What happens when an approver is out?

The answers change the job fast. Now the team is not talking about a button. They are talking about new user roles, permission rules, email alerts, audit history, admin settings, and future support when approvals get stuck.

At that point, the CTO can turn the request into two choices.

The first choice is narrow. It has one approval step, one spending threshold, and a fixed list of approvers that an admin sets up. It writes basic audit entries that show who approved or rejected and when. It does not include delegation, multi step routing, or separate rules for each team.

That version might take two to three weeks with testing. The price is easier to explain, the support load stays smaller, and sales can say something honest: "This covers your current process, not every exception."

The second choice is much larger. It includes routing by role, different rules by team or amount, backup approvers, reminders, deeper audit logs, and admin tools so the client can change flows later. That can take eight to 12 weeks and keep pulling engineers off the roadmap after launch.

Once the buyer sees both choices, the conversation changes. They are no longer choosing between yes and no. They are choosing between "ships this month" and "matches every internal rule."

Most buyers get practical at that point. They pick the narrower version because it solves the immediate need, costs less, and goes live sooner. The company still wins the deal, sales keeps trust, and engineering avoids a promise that keeps growing after the contract is signed.

How to cost the options honestly

A single number feels tidy, but early estimates rarely deserve that much certainty. A range is more honest and more useful. Say "three to five days if we can use the current permissions model" or "eight to 12 days if we need a new admin flow." That tells the buyer what drives cost instead of hiding the risk inside one guess.

The estimate also needs to cover more than coding. Teams lose money when they price the happy path and forget the work around it. Testing takes time. Data migration takes time. Training the client team takes time. Exceptions take time, especially when the request touches old records, user roles, exports, or a third party API.

A solid estimate usually separates three kinds of work: one time work to design, build, test, and ship; ongoing work for support, monitoring, updates, and small fixes; and extra work for migration, training, and exception handling. It should also show queue impact if this request moves ahead of planned work.

That second part matters more than most teams admit. A feature that takes four days to build can still cost months of support if it adds fragile logic, manual checks, or a custom integration. If you do not price the care that comes after launch, you are not pricing the work.

It also helps to mark what the team can reuse later. A customer specific CSV export may help one deal and never matter again. Better audit history or stronger role controls may help future customers too. In that case, the company can split the cost between product budget and deal budget instead of charging one client for all of it.

One more line belongs in every estimate: what slips if this jumps the queue. If the team takes this work now, say what moves back. Maybe the onboarding fix ships two weeks later. Maybe the mobile release waits until next month. A CTO earns their keep here by turning "sure, we can do it" into a priced choice with tradeoffs everyone can see.

Mistakes that turn custom work into a mess

The mess usually starts before anyone writes a ticket. A sales call goes well, the buyer asks for something "small," and the team prices the idea from the demo they just showed. That is risky. A demo shows the happy path. The real workflow includes old data, permissions, reporting, handoffs, and support after launch.

When a company prices from that surface view, the quote looks clean and the margin looks fine. Then engineering opens the request and finds three hidden systems behind it. The work doubles, and nobody wants to explain why.

Another common mistake is hiding uncertainty because a neat number feels easier to sell. It is better to say, "Option A is likely two to three weeks. Option B needs discovery first," than to invent a precise quote nobody can defend later. Buyers can handle uncertainty when you explain what drives it. They get frustrated when the team sounds certain and then misses both budget and date.

Support gets ignored far too often. Custom work does not end at delivery. Someone has to answer questions, fix bugs, update integrations, watch performance, and own the feature when the client changes a process six months later. If the quote includes build time only, the company absorbs the rest.

Some teams also agree to deadlines before engineers review the ask. That is how a simple promise turns into late nights and awkward calls. A short technical review can save weeks of pain.

The last major mistake is changing the roadmap for one loud client without checking the wider cost. That choice can delay work for current customers, pull engineers off planned releases, and create a feature nobody else wants.

A simple rule helps: price the real workflow, not the demo path; show ranges when facts are missing; include support and maintenance in the quote; get technical review before dates go out; and protect the roadmap unless the deal clearly pays for the disruption.

A short checklist before anyone promises delivery

You do not need a long approval process. You need a small gate that forces clarity before anyone gives the customer a number or a date.

• Write the request as one plain sentence. If the team cannot explain it simply, they do not understand it yet.
• Ask engineering where the data comes from, where it goes, and which integrations change. Most custom requests get risky at the edges, not in the screen design.
• Put at least two paths on paper. One might be a full custom build, and another might be a lighter workaround with limits.
• Split the cost into build work and ongoing support. A feature that takes 30 hours to ship can still create months of follow up work.
• Give sales a short script for the customer call that explains what is included, what is not, and what still needs confirmation.

This takes less time than cleaning up a bad promise. A good script can be as simple as: we reviewed the request, there are two ways to do it, and each has a different cost, speed, and support impact.

Customers usually accept tradeoffs when you explain them clearly. They get frustrated when a team says yes too early and then walks it back later.

What to do next

Start with ownership. One person needs the final call on any deal that falls outside the standard product. If sales, product, and engineering can all promise different things, nobody owns the risk.

That person does not need to block every deal. They need to decide when a request is small enough to absorb, when it needs a paid change, and when the right answer is no.

A simple process fixes most of the chaos. Name one approver for nonstandard work. Give sales a short intake form for custom requests that asks what the buyer wants, why they need it, who will use it, what deadline matters, and what budget range exists. Add a review step for larger deals before anyone sends price, scope, or timeline. Keep a written record of what the company approved, rejected, or turned into an option.

The intake form matters more than most teams think. Sales often promises too early because there is no easy way to slow down and collect facts. A one page form creates that pause without turning every deal into a committee meeting.

Set a threshold for review. Any request above a certain revenue amount, any deal with a fixed deadline, or any ask that changes the core product should go through technical review before the quote leaves the building.

If you do not need a full time CTO, bring in a fractional CTO. For many small teams, that is enough. They need someone who can price risk, challenge bad assumptions, and protect delivery without adding a heavy management layer.

Oleg Sotnikov at oleg.is does this kind of work with startups and small businesses as a fractional CTO and advisor. He reviews risky deals, helps teams price custom requests, and puts practical delivery and infrastructure processes in place.

Do this for the next five custom asks, not someday. A light process used every week beats a perfect process nobody follows.