Price custom technical work without losing product margin

Why quotes go wrong

Early startup quotes often hide two jobs inside one price. One part moves the product forward for every future customer. The other part exists because a single buyer asked for it. When those get bundled together, the quote looks clean, but the math breaks.

This usually starts with pressure. A founder wants revenue, a known logo, or enough cash to keep the team moving. So the team offers a friendly price and tells itself, "We'll reuse some of this later." Sometimes that's true. Often it's only partly true.

Reusable product work can pay back over many future deals. Client-specific work usually can't. A custom integration, a special report, or an odd approval flow might matter a lot to one customer, but it rarely helps the next ten. If one customer ends up paying for both types of work without a clear split, you can accidentally fund your roadmap with a deal that never had enough margin.

The damage shows up later, not on day one. A few weeks after launch, the customer asks for small changes, extra support, or edge cases nobody discussed in the quote. Each request sounds reasonable. Together, they turn a healthy project into a slow leak.

Founders also forget the tail of the work. They price the build and miss everything that follows: support, fixes, rollout help, account management, and the cost of keeping that custom path alive every time the product changes. That's where margins disappear.

Oleg Sotnikov sees this pattern often in Fractional CTO work with startups. A team wins a custom deal, ships fast, then spends months carrying code that helps one client and slows everyone else down. The delivery wasn't the problem. The quote was. It mixed product investment with client work and treated them like the same thing.

Separate product work from client work

Before anyone estimates hours, sort every task into one of two buckets.

The first bucket is reusable product work. This is work that makes the product better for many customers, not just the one asking for it. A cleaner onboarding flow, a faster search, or a settings page every account can use belongs here. A customer may have pushed you to build it sooner, but that doesn't mean their quote should carry the full cost.

The second bucket is client work. This is anything tied to one customer's process, data, reporting style, or internal rules. Think custom fields for one team, a private integration, a report format nobody else wants, or a workflow that only makes sense inside that account.

Mixed tasks cause most pricing mistakes. A dashboard may rely on a reporting engine you want in the core product, but one customer may also want a custom export and unusual permission rules. Don't estimate that as one blob. Split the shared engine from the client-specific layer and price them differently.

Ownership matters too. One person needs to decide what each task is before estimating starts. If nobody owns that call, sales gets optimistic, engineers absorb the cost later, and product work slips into custom quotes by accident.

A simple rule works well:

• If many future customers benefit, treat it as product investment.
• If it exists for one customer's process, treat it as paid custom work.
• If it does both, break it apart before pricing.

That sounds obvious, but teams ignore it all the time. Getting strict about scope, ownership, and reuse saves real money.

Four questions before estimating

When every request feels urgent, teams start building before they decide who should pay for it. A better habit is to write each task on its own line and ask four plain questions.

First, will other customers want this soon? If you can already picture two or three future buyers asking for the same thing, the task leans toward product work. If it only makes sense for one account, start from the assumption that it's custom.

Second, was this already on your roadmap? Sometimes a customer asks for something you planned to build anyway. In that case, the client shouldn't carry the full cost of work that helps the company regardless. They might pay for faster delivery, extra setup, or custom reporting around it, but not for the whole feature.

Third, can you reuse more than the code? Reuse includes tests, UI patterns, deployment steps, support docs, and the process your team follows next time. A feature can sound custom and still turn into a reusable module. The reverse is true too. A feature can sound reusable and still create a long tail of special support and manual fixes.

Fourth, if this client leaves next month, who still benefits from the work? That question cuts through wishful thinking fast. If your team still wants the feature, it's product spend. If nobody would keep it, it's client work.

Most teams only need three labels after that: product funded, shared cost, and client funded.

If a task gets three product-leaning answers, keep it on the roadmap. If it gets three client-leaning answers, put it in the proposal as paid custom work. If the answers split, share the cost and explain the split in plain language.

Turn the answers into pricing rules

The rule itself should stay boring: the client pays for work that exists because of that client, and your company pays for work you'd want anyway.

That means customer-specific flows, approval rules, data formats, private integrations, and custom reports belong in the client quote. It also means you bill for the full shape of that work, not just the coding. Planning, testing, rollout, fixes, and support all count.

Roadmap work belongs in the roadmap budget. If a task makes the core product better for many customers, don't hide that cost inside a client deal just because one buyer asked first. That makes one quote look better and the business look worse a few months later.

Mixed tasks need a real split, not gut feel. If an integration takes 6 hours for one client's odd field mapping and 14 hours to improve the shared import engine, bill the 6 client hours and fund the 14 product hours internally. No split is perfect, but this is far better than arguing about it after the project slips.

A reusable pricing structure helps:

• Client-only work: bill 100% to the client.
• Roadmap work: pay from product budget.
• Mixed work: divide the hours before sending the quote.
• Fuzzy work: sell a short discovery phase first or add a buffer.

That last line matters more than most founders expect. Vague requirements are expensive. On a small AI first team, one unclear request can burn days in rework, prompt tuning, testing, or integration fixes.

Add a clear buffer, often 15% to 30%, or cap the first phase at discovery and re-estimate once the unknowns are gone. Clients usually accept that when you explain it clearly: they pay for what's unique to them, and you invest in the parts that improve the product for everyone else.

Build a quote clients can follow

A good quote does two things at once. It helps the client understand what they're buying, and it protects your margin.

Make the split visible. Use separate line items for product work, client work, discovery, revisions, testing, and support. If you may keep part of the work in the core product, say so. If another part exists only for that client's data, workflow, or reporting needs, say that too.

Next to each line item, write the assumption in plain language. Don't bury it in a note at the end. If a dashboard assumes one data source, write that. If an integration assumes a stable API and one authentication method, write that too. Small details prevent the classic "we thought that was included" argument.

Discovery should stay short and capped. Give it a fixed price, a limit in hours, or both. That gives you room to inspect data quality, access issues, and edge cases without drifting into unpaid design and engineering.

Revisions, testing, and support need hard edges. Say how many revision rounds are included. Say whether testing covers only the agreed workflow or also messy historical data and old edge cases. Say whether support means bug fixes only or bug fixes plus small adjustments.

One detail matters a lot: name the trigger for a new quote. If the client adds a second data source, asks for another user role, or changes the approval flow, that is new work. Put that rule in writing before the project starts.

This is often where founders get help from an outside operator. A clean quote structure sounds simple, but it takes discipline when a deal is live and everyone wants to say yes.

Example from an early startup

A small SaaS startup sold inventory tools to independent retailers. One retailer asked for a custom inventory flow: upload supplier spreadsheets, match old SKU formats, and push nightly stock updates into the dashboard.

At first, the founders treated the whole request as custom work for that one retailer. The quote looked simple, but the pricing was off.

After a short review, the split became clearer. The shared import engine was product work. It parsed messy CSV files, mapped columns, caught bad rows, and saved import rules that future customers could use too. The unusual weekly stock-loss report was retailer work because nobody else had asked for that format. Setup and testing with that retailer's sample files were retailer work too.

The numbers changed fast. The import engine took about 70 hours. The custom report and setup took 18 hours. If the startup billed all 88 hours to the retailer, the quote came out high enough to scare the client away.

Once the team split the work, they priced the 18 client hours as services and moved the 70 product hours back to the roadmap. The new proposal was easier to defend. The retailer paid for the report, setup, and work tied to its process. The startup paid for the import engine because it expected to reuse it in future deals.

That also cleaned up the internal story. Sales stopped calling the whole feature "custom." Product could track the shared engine as investment instead of hiding it as a discount inside a client quote.

That's the moment that protects margin. The client pays for what only they need. Your company funds what it plans to sell again.

Mistakes that kill margin

Most teams don't lose money on custom work in one dramatic moment. They lose it in small, polite decisions.

The first mistake is calling almost every request product work so the deal stays cheap. That feels smart when you're trying to close revenue. It stops feeling smart when you realize the feature exists only because one customer asked for it and nobody else wants it.

The second mistake is hiding setup work inside a general engineering estimate. Discovery calls, environment setup, data cleanup, access control, testing on the client's stack, deployment checks, and handoff meetings all take time. If you don't name that work, you won't charge for it.

The third mistake is open-ended support. A founder says, "We'll handle small fixes for a while." The client hears ongoing access. The engineers hear random interruptions for months. Support needs a stop point: how long it lasts, what counts as a bug, how fast you respond, and what turns into new billable work.

The fourth mistake is scope drift disguised as small requests. One extra report, one extra integration, one extra admin screen. Each request sounds minor on its own. Together, they swallow the margin.

Small teams feel this quickly. A startup might quote a dashboard for a pilot customer and quietly include custom roles, private exports, and after-launch tweaks without separating them. The client thinks the quote covers everything. The team spends two extra sprints on work nobody else will ever use.

Margin disappears long before the invoice looks wrong. It disappears when founders avoid naming the work clearly. Product work is product work. Client work is client work. Setup is setup. Support is support.

Check the proposal before you send it

Most bad quotes fail before the client sees them. They mix reusable work with custom work, skip rollout effort, and assume the schedule will go perfectly.

Do one short review before sending anything:

• Put a real paying customer next to every custom task.
• Put a product owner next to every reusable task.
• Add time for testing, rollout, fixes, and support.
• Check whether the quote still works if the project slips by two weeks.

That last test is blunt, but useful. Projects rarely slip because one developer writes slow code. They slip because feedback arrives late, access is missing, test data is messy, or one small client change touches five screens.

If a two-week delay wipes out the margin after meetings, QA, deployment, and support, the quote is too thin even if the engineering estimate looks fine.

This is where experience helps. Someone who has run delivery at scale usually spots the hidden work fast: migration scripts, handoff calls, monitoring, rollback plans, and post-launch fixes. None of those items sounds huge alone. Together, they can erase the profit on a small deal.

What to do with your next deal

Use your next live proposal as the test case. Before you send it, label every task as either product work you want for the business anyway or client work that exists because this buyer asked for it. If a task feels mixed, split it into two lines and price them differently.

That one habit makes margin problems easier to see. It also stops you from burying roadmap costs inside a customer project.

Then look backward for a moment. Review a few older deals and mark the hours your team absorbed without charging for them. Most startups find a pattern fast. Maybe you keep giving away special exports, custom roles, one customer dashboards, or extra setup because each item looks small when it comes in. Added together, they can wipe out a project's profit.

After that, write one team rule short enough to use under pressure. Something like: if you wouldn't keep the feature for other customers, the client pays for it. Sales can use that rule, product can use it, and engineering can point to it when a deal starts drifting.

If the scope still feels fuzzy, get a second set of eyes before you commit. Oleg Sotnikov at oleg.is works with startups on architecture, delivery, and Fractional CTO support, and this kind of quote review is often where hidden custom work shows up before it gets priced too low.

Do it once on a real deal. A live quote forces clear decisions, and clear decisions protect margin.