Kira: I'm on a call with this client — a fintech startup in São Paulo — and we've been working together eight months. My team built them a content ops pipeline. AI triage, editorial calendar, distribution across four channels, analytics dashboard. The whole thing runs on Make, Claude, and a custom prompt library we spent weeks tuning.
Santi: How much of that was your reusable stuff versus custom?
Kira: That's the thing — I didn't know. I hadn't drawn the line. And the client's CTO gets on the call and says, very casually, "So when the contract ends, we get the source for everything, right? That's standard."
Santi: Standard.
Kira: Standard. And I froze. Because half of that pipeline is my team's background IP — prompt libraries, connector templates, the scoring logic we use across six other clients. And the other half is stuff we built specifically for them. And I had no clause in the SOW that separated the two.
Santi: So you're sitting there realizing you're about to hand over the engine you run your entire agency on.
Kira: Or say no and lose the relationship. Those were my two options. Because I never put the addendum in the contract.
Santi: I had the exact same moment. Different client, different continent, same panic. Except mine was worse — I'd already handed over the code.
Kira: You gave them the source?
Santi: I gave them everything. Make scenarios, prompt files, the monitoring scripts. All of it. Because the SOW said "all deliverables become client property" and I hadn't carved out my background IP. Took me four months to rebuild what I'd given away for free.
Kira: Four months.
Santi: Four months of rebuilding tools I already owned — because I didn't have three paragraphs in a contract.
Kira: Imagine you just wrapped a six-month engagement. Your client loves the AI workflow you built them. They want to keep using it — and you want to sell that same module to three other companies next quarter. But your contract doesn't say who owns what. The client thinks they bought it. You think you built it on your own tools. And neither of you has a migration plan for what happens when the relationship ends. That scenario is playing out right now in nomad agencies and micro-SaaS shops everywhere — and it's the most expensive problem nobody writes about when they talk about productizing client work.
Santi: So today we're pulling apart the exact contract language, the migration checklist, and the pricing math that turns a one-off client win into a licensed module you can resell — without burning the relationship or giving away your IP.
Santi: So the core mistake — and I made it, Kira made it, probably half the people listening have made it — is treating everything you deliver as one blob. "Deliverables." One word in the SOW. Client pays, client owns deliverables. Done.
Kira: Right, and that feels fair until you realize the deliverables include your prompt library that took you a year to build, the connector templates you use across every client, the scoring model you trained on your own data—
Santi: The monitoring scripts, the error-handling patterns—
Kira: All of it. Lumped together with the custom dashboard you built specifically for their use case.
Santi: And the fix is a concept that's been in enterprise contracts forever but almost nobody in the nomad builder space uses — background IP versus foreground IP. Background IP is everything you brought to the engagement. Your pre-existing tools, libraries, templates, models. Foreground IP — sometimes called developed IP — is the stuff you created specifically for this client under this SOW.
Kira: And the addendum says: client owns the foreground. You keep the background. But — and this is the important part — you license the background to the client so they can actually use the thing you built them.
Santi: Exactly. They get a license to use your prompt library inside their workflow. They don't get to resell it. They don't get the source. They get runtime access under terms you define.
Kira: Okay but I can already hear someone thinking — "my client is never going to agree to that. They're paying me sixty, eighty, a hundred thousand for this build. They expect to own it."
Santi: Some will push back. But here's what I've found — most clients don't actually want your source code. They want two things. They want the system to keep working. And they want to know they're not trapped.
Kira: Not trapped. That's the data handback piece.
Santi: That's the data handback piece. You put a guaranteed data handback clause in the addendum. On termination or on request, you export their data — their data, not your tools — in a machine-readable format within thirty to sixty days. You delete your copies. You give them a deletion certificate. GDPR Article twenty-eight already requires this for personal data if you're processing as a data processor. But even outside the EU, it's just good practice.
Kira: And it completely changes the negotiation dynamic. Because now you're not saying "I'm keeping your stuff." You're saying "your data is always yours, my tools are always mine, and here's exactly how we separate them if this ends."
Santi: Right. The EU Data Act — which went into force in twenty twenty-four — is pushing this exact direction. Seamless switching between providers, limits on switching charges through twenty twenty-seven. The regulatory wind is blowing toward portability. So if you build your contracts that way from the start, you're ahead of the curve instead of scrambling to comply later.
Kira: So walk me through what the actual addendum looks like. Because I know people are going to want the structure.
Santi: Three pieces. First — the background IP schedule. This is literally a table. Component name, type, version, owner, license to client. You list every reusable thing you're bringing into the engagement. Your ETL connector? Listed. Your prompt library? Listed. Your forecasting model? Listed. Each one gets a license scope — "internal use only," "seat-based," "usage-based," whatever fits.
Kira: That sounds like a lot of work upfront.
Santi: It's maybe twenty minutes if you know your own stack. And if you can't list your reusable components in twenty minutes, you have a bigger problem — you don't actually know what you own.
Kira: Fair point. Okay, so background IP schedule is piece one. What's two?
Santi: The license grant. And this is where pricing comes in. You offer the client a license to use your module — and you give them options. Three paths that cover most situations.
Kira: Which three?
Santi: Seat-based, usage-based with caps, or revenue-share. Seat-based is simple — five users, ten dollars per seat per month, done. The client knows exactly what they're paying. Maxio's twenty twenty-five pricing trends report shows seat-only is declining, but it's still the right fit when access is tied to named humans. Agent-assist tools, back-office dashboards — anything where you can count butts in seats.
Kira: And usage-based?
Santi: Usage-based with caps. Not pure usage — that's where you get bill shock. Vertice's twenty twenty-six data suggests CFOs are pushing back on pure usage models because they can't forecast costs. So you set a base fee, a per-unit rate above a threshold, and a monthly ceiling. The client can never get a surprise bill above the cap. And you publish real-time usage meters so they can see exactly where they stand.
Kira: That's actually smart. Because the cap removes the fear, but the usage component means you capture upside when they scale.
Santi: Exactly. Deloitte's twenty twenty-six predictions call this the hybrid model — and they're seeing it accelerate specifically in AI-powered features where usage is hard to predict.
Kira: And revenue-share is the third path. When would you use that?
Santi: When your module is directly tied to revenue the client can measure. An upsell engine, a lead-gen tool, a pricing optimizer. You take a percentage of attributable revenue with a monthly minimum so you're not subsidizing zero-outcome months.
Kira: Okay but I want to push on something. Revenue-share sounds great in theory. In practice, how do you attribute? Because I've seen that fight — "our sales team closed that deal, not your module."
Santi: Yeah, you need attribution rules in the contract. Last-touch, split, uplift — whatever model you agree on, you write it down. Inclusions, exclusions, reporting frequency, source of truth. If you can't agree on attribution before you sign, don't use revenue-share. Use seat or usage instead.
Kira: Yeah — that's the kind of thing you want to learn before the invoice dispute, not during it.
Kira: Okay so we've got the addendum — background IP schedule, license with pricing paths, data handback. But none of that matters if the client doesn't trust that the migration will actually work when they need it.
Santi: Right. And this is where most productizing-your-service advice completely falls apart. They tell you to license the module but they never talk about what happens on day one of the license — when you're migrating the client from the bespoke build to the productized version — or on the last day, when they're leaving and you need to hand back their data cleanly.
Kira: So what does a migration plan actually look like for a nomad operator? Because we're not talking about enterprise-grade infrastructure teams here.
Santi: No, but the principles are the same. AWS publishes prescriptive guidance on migration cutovers — rollback plans, pre-cutover testing, staged execution. We're applying it at a smaller scale. So the checklist has three phases. Phase one is prep — you name owners, set up a shared channel, mirror the environment with masked data, and do a schema diff. Source versus target, field by field.
Kira: Wait — schema diff? For a Make scenario?
Santi: For anything with structured data. If you're moving a client from a custom Make scenario to your productized module, the field mappings might be different. The null handling might be different. If you don't diff it, you find out in production. And finding out in production means your client's data is wrong and you're debugging from a café in Lisbon at three AM. Also in this phase — rate-limit planning. Atlassian documents this explicitly for their migration platform. If you exceed API limits mid-migration, you get exceptions and partial data. You need bulk endpoints where they exist, client-side throttling, exponential backoff with jitter on four-twenty-nines.
Kira: And for the non-technical folks — that just means your migration script needs to slow down automatically when the API says "too many requests" instead of crashing.
Santi: Right. Phase two is test and cut. Dry run on one to five percent of data, reconcile counts, run the workflows that depend on migrated data. Then freeze period, final sync, switch DNS or keys or webhooks, confirm everything's green. Rollback triggers are pre-agreed — if record mismatch exceeds a threshold, if you get sustained five-hundreds, if a critical functional test fails — you revert. Point back to the old system, replay missed events, schedule a post-mortem. No heroics.
Kira: No heroics from a hammock in Gili Air.
Santi: Especially not from a hammock in Gili Air. Phase three is post-cutover — reconciliation report signed by both sides, observability on, legacy credentials cleaned up.
Kira: So here's where I want to get into the uncomfortable part. Because everything we've described — the embedded module, the integrations, the training the client's team does on your system — all of that creates switching costs. And switching costs can be a moat. But they can also be a trap.
Santi: Yeah, and there's a real tension here. The SEG twenty twenty-six report explicitly says investors reward products that are embedded in workflows and data — because that creates durable retention. But the EU Data Act is simultaneously pushing to lower switching barriers. So which is it?
Kira: Both. And I think the distinction is — are your switching costs based on value or friction? Gartner's research on customer loyalty found that what actually drives retention isn't switching costs at all. It's value enhancement — making the customer more confident and more capable. That works regardless of industry, regardless of how high or low the switching costs are.
Santi: So the calculator isn't about maximizing lock-in. It's about quantifying the real cost of switching so both sides can make an honest decision. The inputs come from academic research — Burnham, Frels, and Mahajan published a switching-cost typology that breaks it into procedural costs, financial costs, and relational costs. For our calculator, that translates to rebuild hours times your blended rate, integration rework, training hours by role, PM overhead, opportunity cost per day of freeze, and any contractual fees.
Kira: And you share that math with the buyer. You don't hide it. You walk them through the inputs and let them adjust the numbers. Because transparency is what separates a value-based switching cost from a hostage situation.
Santi: Right. You're not saying "you can't leave." You're saying "here's what leaving costs, and here's what staying delivers." Those are very different conversations.
Kira: So — that call with the São Paulo client. I want to close the loop on that. Because I did eventually sort it out. I went back, drafted a background IP schedule after the fact, proposed a license for the components my team owned, and offered a clean data handback clause for everything that was theirs. It was awkward. It took two weeks of back-and-forth. And I left money on the table because I was negotiating from a weak position.
Santi: Because you didn't have the addendum at the start.
Kira: Because I didn't have it at the start. And that's the whole point of doing this now — before the next SOW, not after the client asks the question you're not ready for.
Santi: If you take one thing from this episode, it's this — before you sign your next statement of work, attach a license addendum. List your background IP in a schedule. Pick a pricing path — seat, usage with caps, or revenue-share. Add the data handback clause. And run the switch-cost calculator so you walk into that negotiation knowing exactly what the numbers look like for both sides.
Kira: We built the whole kit for you — the Migration plus License Addendum Playbook is on the Resources page. It's the SOW addendum with all three pricing options, the background IP schedule template, the migration runbook, and the switch-cost calculator with the formulas already wired. Duplicate it, fill in the brackets, and get it in front of counsel before your next engagement.
Santi: That's the move. Do it this week.
Kira: See you Wednesday.
Santi: See you Wednesday.