Every hour of custom client work is an hour you can’t sell again. That’s the entire case for productizing — turning something you keep rebuilding from scratch into something you build once and sell repeatedly. It’s also why most attempts at it fail: people try to productize before they’ve actually repeated anything.

Find the repeat before you build the product

Don’t start from “I want a product.” Start from your own project history. Pull the last 10-15 client engagements and look for the thing you kept rebuilding with small variations:

Client A: custom Stripe + subscription dashboard, 3 weeks
Client B: custom Stripe + subscription dashboard, 2.5 weeks
Client C: custom Stripe + subscription dashboard, 3 weeks

If you’re rebuilding the same core 70% three or more times, that’s your product candidate. If you can’t find a pattern like that, you’re not ready to productize — you don’t have a repeat yet, you have a portfolio of one-offs, and forcing a product out of that is how you end up building something nobody but your last client wanted.

Start with a productized service, not a SaaS

The jump from “custom client work” to “self-serve SaaS” is enormous and most people underestimate it by years. The step in between is a productized service: same fixed scope, same fixed price, delivered by you, but no longer custom-scoped per client.

Before: "Custom subscription dashboard" — scoped per client, 2-4 weeks, $8-15k
After:  "Subscription Dashboard Package" — fixed scope, fixed price,
        $6k, 2-week delivery, same deliverable every time

You’re still doing the work by hand. What changed is you stopped re-negotiating scope and price from zero every time — you wrote the spec once and now you’re selling the same spec repeatedly. This alone cuts your sales cycle and your discovery time dramatically, before you’ve written any new code.

Then, and only then, look at what to automate

Once you’ve sold the same productized service five or six times, you’ll know exactly which parts are genuinely identical every time (automate these) and which parts are the reason clients pay a person instead of buying software (keep these manual). Don’t guess this in advance — you’ll automate the wrong half.

Identical every time → template repo, boilerplate generator, CLI scaffold
Different every time → the client's actual data model, their brand,
                        their specific integrations

The build-once-sell-many version — an actual SaaS tool instead of a productized service — only makes sense once you can point at the automatable 70% with real data from real repeats, not a guess made on day one.

Price the product differently than the service

Don’t price a product hourly, even in your head. Price it against the value of not having to hire you custom:

Custom build from scratch: $10-15k, 3-4 weeks, client risk on scope
Productized package:       $6k, 2 weeks, fixed scope, done before

Product isn't the discount version of custom. It's the
lower-risk, faster version — price it for what it removes,
not for the hours it takes you now that you've done it five times.

The trap: keeping one foot in custom work forever

The hardest part of productizing isn’t building the thing — it’s saying no to the client who wants “the package, but with three custom changes.” Every custom exception you make drags the product back toward the one-off work you were trying to leave. Either it’s a real product with a fixed scope, or it’s custom work with a template you started from. Decide which one you’re selling, on every deal, and hold the line — the product only pays off once you stop treating every sale as an opportunity to re-scope it.

---