# Pricing custom work without breaking your product plan > Pricing custom work gets simpler when you separate setup, support, and roadmap items, so client deals do not turn into product branches. ## Why custom deals slowly break the product Custom work rarely hurts you on day one. It hurts you later. A client asks for a special approval step, a custom report, or a different billing rule. It sounds small, so the deal looks profitable. You charge for the build and move on. But the feature is not the real cost. The real cost is the exception that stays behind. Once that exception ships, your team has to remember it every time they touch the product. Support replies get longer. QA needs extra checks. New hires need the backstory for why one customer works differently. A fix that should take an afternoon turns into two days because someone has to ask, "Will this break that custom flow?" That is where margin leaks out. The original work might take 20 hours. The follow-up can keep showing up for months. Custom work also slows the whole product down. Product improvements help every customer at once. Client-specific changes help one customer and add more conditions to your code, tests, docs, and release process. After a few deals like that, releases start to feel risky. People delay them. Simple improvements pile up. This happens fast in a small SaaS company. You start with a clean workflow tool. One customer gets a special export. Another gets a different user role. A third wants something close to the first request, but not quite the same. Now you do not have a clear product decision. You have a pile of private deals. That is the real problem. Product work improves the main path for everyone. Custom work creates side rules, side tests, and side support. If you do not separate those costs early, each new deal looks good on paper and gets more expensive in real life. ## Split the work into three buckets Most bad custom deals start with one vague number. The client sees a single price, but your team is really taking on three different kinds of work: setup, support, and roadmap work. Those do not cost the same, and they should not be priced the same. Setup is the one-time work that gets the customer live. That usually includes data import, configuration, training, and launch help. Support is the repeat work that starts after launch. It includes questions, small changes, bug triage, extra meetings, and the steady stream of "can you also..." requests. Roadmap work is product work. If the request could help more than one customer, treat it as a product decision instead of hiding it inside one deal. Put each bucket on its own line in the quote. That small change improves the whole conversation. A setup fee feels finite because it is. Support feels ongoing because it is. Roadmap work stays separate, so you do not quietly promise a product feature in the middle of a sales process. Use the same names everywhere. If you say "setup" on the sales call, say "setup" again in the proposal and on the invoice. If one document says "support" and another says "success package," people fill in the blanks with their own assumptions. A clean structure also protects the roadmap. Shared ideas go through normal product review. One-off work gets paid for. Repeat help does not disappear inside a project fee and quietly eat your margin. ## Decide what belongs in setup Setup should cover the work that takes a customer from signed quote to a clean first launch. It should not become a bucket for every request that shows up before or after go-live. Most setup packages are pretty ordinary: importing old data, configuring roles and permissions, training admins or daily users, running launch checks, and doing one final handoff. Deals get messy when setup starts absorbing everything. If a customer needs six workshops, three test imports, and manual cleanup of broken legacy data, that is extra paid work. It is not part of a vague onboarding promise. Put limits in writing. Say how many meetings are included. Say how many training sessions are included and how long they are. Put a cap on migration volume, revision rounds, and manual cleanup. If the migration will take 25 hours, price 25 hours. If training needs two sessions, write down two sessions. The end date matters as much as the price. Setup should stop on a clear handoff point, such as "10 business days after import sign-off" or "after the first live-week review." After that, support pricing starts. Without that line, customers keep pulling setup work forward for weeks. It also helps to state what setup does not include. Custom features, open-ended cleanup, new reports, extra training, and post-launch support should stay outside setup unless the quote lists them. A short scope keeps you out of a common trap: every sale turning into its own mini product. ## Price support without hiding it Many teams bury support inside the project price because it feels easier at the time. It is almost always a mistake. When support is hidden, the client assumes help is unlimited. Your team starts doing unpaid work every week. The project looked healthy when it closed, but the margin keeps shrinking after launch. Support needs its own line item and plain rules. State your support hours, response times, and what counts as a normal request. If you answer messages Monday to Friday, say that. If urgent issues get a reply within four hours, write that down. Do not lump bug fixes, advice, and change requests into the same bucket. They are different. - A bug fix means the work does not match the agreed scope. - Advice means the client wants help using, planning, or reviewing something. - A change request means they want new work. A simple monthly plan works better than open-ended help. Most small SaaS deals only need a few options: a business-hours email plan, a small monthly block of advisory time, a plan with minor fixes and a hard cap on hours, or a higher tier with faster response times. Rush work and weekend work need separate pricing. If you do not price them separately, clients learn that every request can become urgent for free. Review support usage every month. Look at how many requests came in, what kind they were, and which ones turned into new work. If one client uses twice the hours in their plan, update the next invoice or move them to a different plan. Teams that do this keep scope under control and avoid building a hidden second product for one account. ## Put shared requests on the roadmap Some requests look custom at first, but they are really product signals. If more than one customer will want the same thing, treat it as roadmap work. Do not bury it inside a private deal. A quick test helps. Ask three questions: - Does this solve a common pain? - Does it fit the product you want to sell next year? - Will it still make sense six months from now? If the answer is yes, stop treating it like a custom favor. Before you commit, estimate the product value. Will the feature help future sales? Will it reduce support load? Will it remove awkward workarounds inside your own team? If it only helps one customer in one narrow case, keep it custom. If it can help many customers, move it into the main product. Build shared features in the main codebase from the start. Do not hide them in a client branch just because one customer asked first. A small team can support one clean version of a feature. It struggles when every deal creates a copy. Say this clearly in the quote. Most clients accept a simple explanation: "This workflow is custom for your team. The reporting option may later become part of the standard product." That gives them clarity without promising exclusivity you cannot afford. Sometimes co-funding can work. A client pays for part of the build and you move the reusable part onto the roadmap. That only works when the math works. Count build time, testing, support, and long-term maintenance. If the client contribution does not cover that extra burden, you are still underpricing the work. One rule is enough: client-specific work stays custom, shared product work goes on the roadmap, and each gets priced on its own. ## How to quote the deal A good quote keeps the sale simple and protects the product. Do not send one total number with fuzzy notes. Break the deal into parts so both sides can see what they are buying, when it ends, and what happens after launch. 1. Start with the standard product. Put the normal plan or license first, using the same base price you offer similar customers. 2. Add setup as a separate line. Name each item, set a limit, and include a date. For example: import up to 5,000 records, connect one payment provider, and train two staff sessions by May 30. 3. Add support as its own plan. Match it to the client's real needs. 4. Move reusable feature ideas out of the quote. If a request could help several customers, put it in a roadmap note instead of the setup price. 5. State what the quote does not include. Call out extra integrations, feature development, cleanup beyond the agreed limit, and on-site work if you do not offer it. This structure cuts down on arguments later. It also gives you a clean way to say yes without quietly promising custom product branches. If a client pushes you to bundle support into setup, push back. Bundling hides the real cost and makes renewal awkward. When the first support issue lands three months later, you want a price and a boundary already on paper. A quote does not need to be long. It just needs to be clear. ## A simple example from a small SaaS sale A small SaaS team is close to signing a new customer. The buyer likes the product, but asks for three extras: SSO for employee login, help importing old data, and a few changes to the weekly report. This is where teams often make a mess. They wrap everything into one large quote, promise to "make it work," and end up maintaining a version of the product that only one customer needs. The clean version is simpler. The import work belongs in setup. The customer needs help mapping old fields, cleaning bad records, and loading the first batch. Training fits there too, because it happens once at the start. The report changes and day-to-day questions should not hide inside setup. Those requests tend to continue after launch. Put them under monthly support, with a clear amount and a clear limit. SSO is different. If this is the only customer asking for it, pause. If several customers or active prospects need SSO, then it belongs in product planning, not in a private feature deal. The quote might look like this: - $3,000 setup fee for import and training - $500 per month for support, including report edits and questions - SSO is not part of this quote and will go through product review if demand stays strong That structure keeps the sale honest. The customer sees what they pay once, what they pay each month, and what is still product work. The company keeps one product, one codebase, and one roadmap. ## Mistakes that create one-off products One-off products usually do not start with a huge decision. They start with a rushed quote, a friendly sales call, or one small promise made to close the deal. A common mistake is hiding setup work inside the first-year price. It looks neat, but it blurs the line between one-time work and recurring service. When renewal comes around, the customer thinks the custom effort is part of the normal subscription. Another problem starts on the call itself. Someone says, "Yes, we can add that," before product or engineering reviews the request. Now the quote includes a feature, not just a service. That is how sales promises turn into roadmap debt. Small undefined changes cause just as much damage. "A few edits" sounds harmless until it means extra fields, new reports, another approval step, and three review rounds. If you do not set the limit, the customer will set it for you. Watch for a few warning signs. Your quote is drifting into one-off territory when setup, migration, and training sit inside one annual number, promised features have no product review behind them, "minor changes" have no count or time limit, nobody checks whether the request helps more than one customer, and old exceptions stay in the contract year after year. That last point matters more than most teams admit. Special contracts almost never stay small. A custom support rule turns into a custom workflow, then a custom release process, then a custom renewal argument. A short product review before you send the quote can stop most of this. Two questions are usually enough: can we reuse this, and when does this exception end? ## Checks before you send the quote If a quote takes ten minutes to explain, it is probably too messy. Read it once as if you were hearing it for the first time. If someone on your team cannot explain the full price in about a minute, split it again until it is clear. Do one quick review before sending: - Make sure every line has an owner. - Make sure every line has a limit. - Make sure the end point is clear. - Check with engineering if the deal needs special code or a separate deployment path. - Check that the support plan matches the real workload, not the optimistic version from the sales call. One simple test works well: imagine a second customer asks for the same package next week. Could you sell it again with only minor edits? If yes, the structure is probably clean. If no, move some of that work into the roadmap or charge for the extra setup now. This is where founders often get too optimistic. They price the build, then hide meetings, support, edge cases, and internal coordination inside goodwill. The quote looks smaller. The work does not. Sometimes it helps to get a second pair of eyes before the proposal goes out. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this is exactly the sort of scope and product boundary problem he helps founders clean up. ## What to do next Pull your last five signed deals and sort every promised task into three buckets: setup, ongoing support, or roadmap work. Do it on paper or in a spreadsheet. If one task keeps bouncing between buckets, your quote process is still too loose. Then update your proposal template. Keep setup, support, and roadmap work on separate lines every time. Use a simple rule for custom requests: if only one customer will use it, price it as setup or paid custom work, not as product. Use that rule on every deal, even when a prospect pushes for an exception. Most product mess starts with one "special case" that felt harmless at the time. You do not need a perfect quote. You need a quote your team can still live with a year from now.