Custom feature support cost: price more than build time

Why build time hides the real cost

Most feature quotes stop at launch. That is the part everyone can see: design it, build it, test it, ship it. The expensive part starts later.

When a team prices only the first release, sales hears "30 hours" and treats that as the full cost. It rarely is. A custom feature creates a separate path through the product, and that path needs attention every time a customer uses it in a way nobody expected.

The follow-up work arrives in small pieces. Support answers a question. An engineer checks logs. A product manager asks for an exception. Someone fixes a bad record by hand. None of those tasks look serious on their own, but together they eat real time because they interrupt planned work.

Upgrades add another layer. A feature that worked fine in version one can break when the product changes, a third party API changes, or the database schema moves. Even if nothing breaks, someone still has to confirm the feature still works after each release.

Manual fixes make the total even harder to spot. Teams often patch custom requests with admin actions, data edits, or small scripts. Each fix feels minor, so nobody adds it to the original estimate. A few months later, the company has paid for the same feature several times without noticing.

Picture a simple request: one client wants a special approval rule. Building it takes two days. Then support gets questions when the rule blocks an order that looks valid. Product asks engineering to add one exception. Later, billing logic changes and the rule needs another update. On paper, the feature is done. In practice, the team keeps spending time on it.

That is why build time hides the real cost. The first estimate covers delivery. It does not cover the slow drip of support, retesting, upgrades, and manual cleanup that follows.

What to count before you say yes

A feature can look cheap when you count only build hours. Then it ships, a client hits an edge case, support gets a few tickets each month, and engineering keeps revisiting the same logic after every release. That is the part most teams miss.

Before sales agrees to custom work, engineering should answer a small set of plain questions and add them to the same estimate form every time:

• How many support contacts will this create in a normal month?
• Which parts of the product are likely to break when the app, API, or dependencies change?
• Will anyone need to fix data, rerun jobs, resend files, or change settings by hand?
• Who owns the feature after launch?
• Is this a short exception or something the company may support for years?

Start with ticket volume. Do not guess from optimism. Look at similar custom work and count the actual follow-up. One ticket that takes 10 minutes is small. Four tickets a month that pull in support and engineering are not. A feature that looked minor during planning can burn three or four hours every month long after the build is done.

Then look at upgrade risk. Custom logic tied to exports, permissions, billing rules, third party APIs, or old client workflows tends to break when the main product changes. If the feature depends on a fragile part of the stack, add maintenance time now instead of acting surprised later.

Manual work deserves its own line. If someone must rerun a job, clean bad records, check logs, or patch a config by hand, that work will repeat. Even 30 minutes a week adds up to about 26 hours a year.

Ownership matters just as much. If nobody owns support after launch, the issue bounces between sales, customer success, support, and engineering. Name one owner before the deal closes. If support handles first response and engineering handles fixes, write that down.

Last, ask how long the feature needs to stay alive. A six month client exception and a permanent product branch are not the same thing. Add a review date or a retirement rule. If the client expects long term support, price it that way.

Estimate support work step by step

Start with one sentence that pins down the request. Name the user, the action, and the result. "Client admins can export orders to CSV with five custom columns" is specific enough to estimate. "Need better exports" is not.

Next, list every part of the product the feature touches. Most custom work reaches farther than the first screen people see. Check the app, API, database, permissions, logs, admin tools, email notices, docs, and any reports that might now show different data.

Only then should engineering estimate build time. Keep that number separate at first. It should cover design, coding, testing, and release work.

The miss usually happens after launch. To estimate the full cost, add the hours that arrive later:

• support tickets in the first few weeks
• bug fixes found with real customer data
• retesting when the main product changes
• manual fixes for edge cases or bad inputs

Use rough numbers you can defend. Do not fake precision. If support expects six tickets at 20 minutes each, count two hours. If engineering will spend half a day rechecking the feature during the next major update, count four hours. Small blocks are easy to ignore and expensive to absorb.

Add owner time too. Managers review the estimate, answer follow-up questions, and step in when a client reports a problem. Support writes replies, updates notes, and tests the fix before closing the ticket. If sales needs extra calls to explain limits or scope, count that time as well.

Then combine everything into one total. Sales should not get a pile of partial numbers and guess what they mean. Share a simple summary with build hours, support hours, and the full total. If your team prices work in money instead of hours, convert it before anyone says yes.

That final number changes the conversation. A feature that looks like an eight hour build can easily become 20 hours once tickets, upgrade checks, and manual fixes are included. Sales can still approve it, but now they approve the full cost instead of the pleasant part.

Use a simple scoring table

A short scorecard gives engineers a repeatable way to estimate support work and gives sales a number they can explain without guessing.

Keep the table small. If it takes more than a few minutes to fill out, people will skip it when a deal feels urgent.

The labels matter more than the math. "Support" covers tickets, user questions, and odd edge cases after launch. "Upgrade risk" measures how likely future product changes, API updates, or dependency changes are to break the feature. "Manual work" covers tasks nobody wants to do by hand, like data fixes, reprocessing, or staff only workarounds.

Use plain labels so people score the same way each week. Support can be low, medium, or high. Upgrade risk can be stable, mixed, or fragile. Manual work can be none, rare, or often. Then turn those labels into hours with a fixed chart. Do not renegotiate the scale on every deal.

Say a custom report gets scored as medium support, fragile upgrade risk, and rare manual work. Using the table above, that becomes 8 + 16 + 4 = 28 support hours. If your loaded rate is $120 an hour, the support estimate is $3,360. Put that next to build time, not underneath it as an afterthought.

This is where many teams go wrong. They quote 30 build hours, win the deal, and only later notice the feature needs 28 more hours over the next year to keep working and answer tickets. The feature looked cheap. It was not.

Review the scores once a month. If a "low" feature keeps creating tickets, move your hour ranges up. The table does not need perfect math. It needs to be fast, consistent, and honest enough to stop bad yeses.

A realistic example: custom export for one client

A client asks for a custom CSV export that matches their accounting system. The request sounds small: one new button, six fields, and a file that follows the client's import rules. An engineer estimates 10 hours to build and test it, so sales treats it like an easy yes.

The first version often is small. The trouble starts after launch.

A week later, the client asks for dates in a different format. Then they want blank values shown as "0". Next month, their accounting vendor changes the column order, so the export has to change again. None of these edits look serious on their own, but each one creates tickets, messages, review time, and another deploy.

If you price only build time, the estimate may look like this:

• Build the export logic: 8 hours
• Test the file with sample data: 2 hours
• Release and internal review: 2 hours

That is 12 hours total. It feels cheap.

But the first year tells a different story. Product updates can touch the export even when nobody meant to change it. A renamed field, a new permission rule, a tax setting update, or a library change can break the output. If the team ships every two weeks and spends 20 minutes retesting this export each release, that adds almost nine hours a year.

Support grows in quieter ways too. The client opens a ticket because one row count looks wrong. An engineer checks logs, compares database values, and sends a corrected file. If that happens twice a month and takes 45 minutes each time, that is 18 hours a year.

Then the manual checks become routine. The client asks the team to confirm a few records before payroll or month end close. At first this feels like good service. After a few months, it is recurring work that somebody has to own.

Now the real cost looks more like this:

• Format changes after launch: 6 hours
• Retesting during regular releases: 9 hours
• Support tickets and manual fixes: 18 hours
• Monthly data checks: 12 hours

That adds 45 hours after launch, on top of the original 12. A feature that looked like a one day job now eats 57 hours in a year. Sales can still approve it. They just need to price the full cost of yes.

Mistakes teams make when pricing custom work

Teams lose money on custom work when they price the build and ignore the life of the feature after launch.

Sales often makes the first mistake. A client asks for a custom report, export, or workflow tweak, and sales quotes only the delivery effort. The quote sounds reasonable because build time is easy to picture. The harder part is the slow drip of support: tickets, follow-up questions, strange edge cases, and manual fixes when the feature does not fit the main product cleanly.

Engineers make their own version of the same mistake when estimates stop at coding and QA. Upgrade work belongs in the number from day one. Libraries change, APIs move, browsers behave differently, and old assumptions break. If nobody adds that future work, the estimate looks smaller than it is.

Teams also forget the time around the feature, not just inside it. Someone has to explain how it works to support, answer the first round of customer questions, update notes, and tell future engineers why the custom path exists. Even a narrow feature can eat a few extra hours in training and handoff.

A short checklist helps catch the hidden work:

• Count expected support tickets for the first 90 days.
• Add time for future upgrades and regression checks.
• Include training, handoff notes, and customer explanations.
• Assign one owner after launch.
• Set a review date to keep or retire the feature.

Ownership is where many teams fall apart. After launch, sales thinks engineering owns the feature. Engineering thinks support owns it. Support thinks the account manager owns it. Then a bug shows up, nobody answers quickly, and the client gets frustrated. One named owner does not solve every problem, but it stops the feature from drifting.

Old custom work creates another quiet cost. Teams keep one-off features alive for years because nobody reviews them. The original client may barely use them now, but every release still has to avoid breaking them. That is how a product fills up with clutter and cost estimates turn into guesswork.

A quick check before sales commits

Sales can close a bad deal in ten minutes if nobody totals the work that starts after launch. A feature that takes 20 hours to build can turn into months of interruptions, retesting, and small fixes.

Use one short pause before anyone says yes. The goal is simple: turn a vague request into a first year cost that sales, engineering, and support all see the same way.

A quick review should answer five questions. How many support tickets will this likely create each month? What will the team need to retest after each release? If the feature fails for one client, will someone need a manual fix? Who owns the feature after launch? Did sales see the full yearly cost, not only build hours?

The first question matters because ticket volume often hides inside "small" custom work. One special workflow for one client can still create confused users, broken exports, and edge cases support has to explain again and again.

Upgrade testing is the next trap. If the feature touches billing, reports, API output, permissions, or exports, every product change can break it. That means engineering time, QA time, and sometimes customer success time too. If nobody prices that work now, the margin on the deal is fiction.

Manual fixes need their own line. Some custom features fail in ways automation cannot handle. A report may need a hand edited CSV. A data sync may need someone to rerun a job. Those fixes feel rare until the team does them every Friday.

Ownership must be explicit. One person or team should approve changes, watch ticket patterns, and decide when the custom logic needs a rewrite or retirement. If ownership stays fuzzy, the work lands on whoever is already overloaded.

A simple rule for approval

If sales cannot repeat the first year support number back to engineering, the feature is not priced yet. That number should include build time, expected tickets, retesting, manual fixes, and the owner's maintenance time.

Once the yearly number is on the table, some deals still make sense. Others need a setup fee, a higher recurring price, or a polite no.

What to do next

Use the same estimate on every custom request, even small ones. If a feature is worth building, it is worth pricing fully. That means build time, support time, upgrade work, and the manual fixes your team will almost always pick up later.

A simple rule helps: sales should not promise custom work until engineering fills out the same form every time. The support estimate should sit next to the delivery estimate, not appear a month later when the first ticket lands.

Keep the format short enough that people will actually use it, but strict enough that nothing important gets skipped. Include the request itself, build and test time, likely support tickets over 3, 6, and 12 months, upgrade risk, manual work, ownership after launch, expected revenue, and a review date.

Then look backward, not just forward. Pull a sample of old custom features and compare the original guess with what really happened. Count tickets, fixes, special handling, and time spent during product upgrades. Most teams find the same pattern quickly: a few custom features make money, and a long tail quietly drains time.

When support costs more than the feature earns, stop treating that as normal. Drop that kind of work, raise the price, or fold the request into the standard product so more than one customer pays for it. If a client only needs a slight variation, offer the standard option first and explain the tradeoff in plain language.

That also changes how sales talks about "yes." A good sales engineering handoff is not just a spec. It is a shared view of what the team will carry for the next year.

If you want an outside review, Oleg Sotnikov at oleg.is helps startups and small businesses tighten this part of the handoff as part of his fractional CTO and advisory work. A second opinion can be useful when custom work keeps winning deals but quietly draining the team afterward.