Software Licensing vs Equity: Why I Kept My IP

The Deal That Was Quietly Becoming a Startup

The conversation started where most of my work starts: build us a system. A client running several window-treatment companies wanted one piece of software to handle the whole operation across all of them. Quoting, scheduling, inventory, customer follow-up. The kind of thing they'd been duct-taping together with spreadsheets and three different SaaS subscriptions.

I said yes. I started building. And somewhere over the following weeks, the thing quietly stopped being a build engagement and started becoming a startup.

The language shifted. "Our software." "When we launch this to other companies." "The three of us." Suddenly there was a cap table forming in someone's head, and I was the technical co-founder who'd own a minority slice of a software company I was writing entirely by myself.

Here's the part that should have stopped me earlier. One of the would-be co-founders had never put in a dollar. Hadn't written a line of code. Hadn't taken on any build risk. The structure drifting onto the table would have handed the operators majority ownership of software that only I touched.

And I almost signed it.

Not because I'm careless. Because the relationship was good. We liked each other. The momentum felt real, and when momentum feels real, the structure underneath it stops getting scrutinized. You ride the energy and tell yourself you'll formalize the details later.

That's the trap. The better the relationship, the easier it is to agree to a structure you'd reject instantly from a stranger. I was about to give away the majority of an asset, while keeping 100% of the work of building and maintaining it.

The thing that saved me wasn't a gut feeling. It was running the actual math on software licensing vs equity, and realizing the deal I was about to sign had the incentives pointed the wrong way.

Software Licensing vs Equity: The Math That Changed My Mind

What equity actually costs the solo builder

Equity sounds like alignment. We're partners, we share the upside, we're in this together. That framing works when multiple people share the build.

It falls apart when one person builds the whole thing.

When I take equity for software I write alone, here's what actually happens: I dilute my ownership of something I build, maintain, debug, and improve every single week, in exchange for a slice of an outcome I'm fully responsible for creating. The operators own a majority on paper. I own the labor in reality.

And the labor never stops. Software isn't a painting you hand over once. It needs updates, new features, fixes when an API changes, improvements when the business grows. Every one of those hours, under an equity deal, transfers value to people who own the asset but don't build it.

That's not partnership. That's a structure where my ongoing work permanently enriches owners who took on none of the build risk. (This is exactly why I build instead of just advise, when you're the one writing the code, the ownership question is the whole game.)

Why a license keeps the value where the work is

A license flips it. I keep 100% of the IP. The client pays to use it.

Equity vs License for a Solo Builder

If the system delivers value, they keep paying because it's worth more than it costs. If it stops delivering, they stop. Payment ties directly to actual use and benefit, not to a one-time paper transfer of an asset I'll be feeding for years.

The comparison, in plain terms:

• Equity: I give away ownership of an asset I solely build and maintain, forever, for a slice of an outcome I'm responsible for.
• License: I keep the asset, the client pays for the right to use it, and payment scales with the value they get.

This is genuinely different from a co-founder situation. If three people are building the product together, sharing nights and risk and revenue gaps, equity is the right tool. Shared build, shared ownership.

But when one person builds it, equity is structurally lopsided. The math doesn't favor the builder, it favors whoever negotiated the cap table. Once I saw that clearly, the choice made itself.

Who Owns Software a Consultant Builds for You?

The default no one reads: IP belongs to the creator

Here's the thing most clients get wrong, and it's worth saying plainly because it cuts both ways.

Who Owns Consultant-Built Software by Default

Absent a signed work-for-hire or assignment agreement, the person who writes the code owns it. That's the legal default in most cases. Paying someone to build software does not, by itself, transfer ownership of that software to you.

Most clients assume the opposite. They assume "I paid for development" means "I own the output." It doesn't, unless that transfer is in writing and signed.

So the answer to who owns AI built software is uncomfortable for a lot of business owners: probably the consultant who built it, unless you papered the ownership transfer explicitly.

Why no work-for-hire was ever signed

In my window-treatment engagement, no assignment agreement was ever signed. No work-for-hire clause. Nothing transferring the IP from me to them.

Which meant, by default, the software was mine. Not because I schemed it that way. Because consultant IP ownership defaults to the creator, and nobody had put anything different in writing.

I'm not telling you this to teach builders how to trap clients. The opposite. The point is that ownership has to be deliberate. When it drifts, when nobody writes it down, you end up in exactly the ambiguous place I was in: a half-formed startup where everyone assumed something different about who owned what.

A clean license fixes the ambiguity for everyone. It tells the client exactly what they get: the right to use the software, not the right to own it. No surprises if the relationship ends. No fights over an asset nobody clearly defined.

Deliberate beats drift, every time.

How I Restructured It: License Plus Fractional Retainer

One system that runs the whole workflow

I went back to the operators with a clean reframe. You run your companies. I own my software. I build you one system that runs your entire workflow, and you license it.

That's the deliverable: a single system handling quoting, scheduling, inventory, follow-up, all of it. Not a stack of disconnected tools, one engine that runs the operation. (It's the same shape as an AI configurator I own and license out, one system that replaces an entire category of software the client was paying for separately.)

Onboarding fee plus usage that triggers above a buffer

The pricing had three parts, and the structure is where the alignment lives.

One: a one-time onboarding and setup fee. This covers the real cost of building and deploying the system into their specific operation. Day-one work, paid for on day one.

Two: a usage fee that only triggers after I've grown their revenue past a defined buffer. This is the piece I'm proudest of. I don't charge usage from dollar one. The usage fee kicks in only once the system has pushed their revenue above an agreed threshold. Below the buffer, they pay nothing on usage. Above it, I share in the growth the software created.

The logic: I get paid more when they're genuinely better off, and not before. It de-risks the whole thing for them. If my system doesn't move their numbers, the usage fee never activates. That's value based software pricing done honestly. My upside is bolted directly to their results.

The optional month-to-month retainer

Three: an optional month-to-month retainer. This gives me recurring income from day one and gives them continuous improvement. The system keeps getting sharper because someone whose job is to sharpen it stays attached to it.

Three-Part License Pricing Structure

I want to be precise about what this retainer is, because the word gets abused. It's not a part-time helper who answers emails. It's ongoing ownership of their AI function. I'm responsible for the system that runs their business, and I keep making it better. (That distinction is the whole difference between a CAIO and an AI consultant, one owns the outcome, the other rents you advice.)

Put together, the structure aligns everyone. They get full use of a system that runs their operation, they only pay growth fees once they're actually growing, and they get a builder who stays on the hook to improve it. I keep my IP, get paid for the build, share in real results, and have recurring income that doesn't depend on landing the next deal.

Same software. Completely different incentives.

The Risk I Almost Missed: Client-Side Bankruptcy

Here's the part I didn't catch. A lawyer did.

Client Bankruptcy IP Risk and Protection

When you license software to a client running multiple companies, there's a risk that doesn't occur to most solo builders until it's too late. If one of those companies hits financial trouble, a poorly structured license can get pulled into a bankruptcy estate or contested by creditors.

Translation: if the business goes under, my software, the IP I supposedly owned, could get treated as an asset of their failing company. Tangled up in proceedings I had no control over.

The license had to be drafted specifically to keep my IP from being treated as the client's asset. Clear ownership language. Clean separation between the right to use and the underlying property. Terms that survive the client's financial state, whatever it turns out to be.

I want to be honest about this: I would not have thought of it on my own. I'm good at building systems and structuring deals. I am not a bankruptcy attorney, and it showed. The risk only surfaced because I ran the license past someone whose job is to spot exactly this kind of thing.

That's the lesson, and it's the one builders skip. You can do brilliant work structuring how you capture value, and still lose all of it because you didn't protect the structure legally. The two jobs are separate. Capture the value with smart deal design. Protect it with a short legal review. Skip the second step and the first one can evaporate the moment a client hits trouble.

A few hundred dollars of legal time protected an asset I'd spent weeks building. Cheapest insurance I've bought.

A Framework for Solo Builders Structuring Value Capture

This generalizes well beyond window treatments. Same logic applies whether you're building for a manufacturer, a financial firm, or a fitness business. Here's the framework I use now.

Solo Builder Value-Capture Framework

Default to licensing, not equity, when you build alone

If you're the only one building it, default to license plus retainer. Full stop. Equity is for people who share the build risk, the late nights, the revenue gaps. If you're carrying the whole technical load yourself, equity hands your ongoing labor to owners who don't build. Don't do it.

Make ownership deliberate and put it in writing

Never let ownership drift. The moment "build us a system" starts sounding like "our software," stop and define who owns what, in writing, signed. Ambiguity always resolves in favor of whoever has the better lawyer later. Resolve it early, on paper, when everyone's still friendly.

Tie payment to outcomes you can actually move

Build your variable payment around a metric you can genuinely influence, like revenue above a defined buffer. Not a flat fee that ignores whether you delivered. Not a vanity metric you can't control. Pick the number your work actually moves, and tie your upside to it. That's what makes value based software pricing fair instead of arbitrary.

Keep recurring income from day one

Always carve out recurring income. The retainer isn't greed, it's survival. It means you're not living deal-to-deal, scrambling for the next project to make rent. Recurring revenue lets you do better work because you're not negotiating from desperation.

Get a short legal review before signing

Spend the few hundred dollars. Have someone who knows IP and insolvency read your license before you sign it. You will miss something. The review costs less than losing the asset.

One more move worth knowing: once a license proves out with one operator, you've validated something other businesses in that industry will pay for. That's the path from internal tool to paid product, a single proven license can become a product line.

If a Consultant Is Building Your Software, Settle This First

If someone is building the system that runs your business, decide ownership before line one of code gets written. Not after. Not when the relationship cools. Before.

The fair structure, in my experience, is usually a license. You get full use of the software, no caveats, no surprises. The builder keeps the IP and stays on retainer to keep improving it. And the payment ties to whether the system actually grows your business, not to a flat invoice that gets sent whether it works or not.

That's exactly how I work with the operators I build for. They keep running their company. I own and keep sharpening the software. They pay to use it, and they pay me to make it better. Everyone knows what they own. Everyone's incentives point the same direction.

It's a cleaner deal than the half-formed startup I almost signed. And it took a lawyer and a hard look at the math to get there.

If you've got a consultant building something for your business and the ownership question is still fuzzy, that's worth sorting out now, before it drifts. Come talk through how we'd structure it for your situation.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together