Back to Blog
business-modelip-ownershipconsultingpricing

Software Licensing vs Equity: Why I Kept My IP (Simply Explained)

A plain-language guide to software licensing vs equity. No jargon, no tech speak, just what it means for your business.

By Mike Hodgen

Want the full technical deep dive? Read the detailed version

The Deal That Was Quietly Turning Into a Startup

It started like most of my projects. A client running several window-treatment companies wanted one piece of software to run their whole operation. Quoting, scheduling, inventory, customer follow-up. The stuff they'd been holding together with spreadsheets and a handful of monthly subscriptions.

I said yes. I started building. And over the next few weeks, the project quietly stopped being a job and started becoming a company.

The words changed. "Our software." "When we launch this to other companies." "The three of us." Suddenly I was being treated as a co-founder who'd own a small slice of a software company I was building entirely by myself.

Here's the part that should have stopped me sooner. One of these would-be partners had never put in a dollar. Never built anything. Never carried any risk. And the deal forming on the table would have handed them and the other operator the majority of software that only I touched.

I almost signed it.

Not because I'm careless. Because we liked each other. The energy felt real. And when the energy feels real, you stop looking closely at the structure underneath it.

That's the trap. The better the relationship, the easier it is to agree to a deal you'd laugh out of the room if a stranger offered it.

The Math That Changed My Mind

Equity sounds friendly. We're partners, we share the upside, we're in this together. That works great when several people are actually building the thing together.

It falls apart when one person builds all of it.

Think of it like owning a restaurant. If three of us pool our money, do the cooking, and split the long nights, splitting ownership makes sense. But if I'm the only one in the kitchen, paying for the ingredients, and the other two just show up to count the register, why would I give them the majority of the restaurant?

That's what equity does to a solo builder. I'd be handing away ownership of something I build, fix, and improve every single week, in exchange for a slice of a result I'm fully responsible for creating.

And software is never finished. It needs updates, new features, fixes when something breaks. Every one of those hours, under an equity deal, makes the people who own it richer while I keep doing all the work.

So I went with a license instead.

A license is simple. I keep full ownership of the software. The client pays to use it. If it makes them money, they keep paying because it's worth more than it costs. If it stops working for them, they stop. Their payment is tied to the value they actually get, not a one-time giveaway of something I'll be maintaining for years.

Same software. Completely different incentives.

The Ownership Question Most Business Owners Get Wrong

Here's something most clients have backwards, and it's worth knowing whether you're hiring a builder or being one.

If there's no signed agreement saying otherwise, the person who writes the software owns it. Paying someone to build software does not automatically make it yours. That transfer has to be in writing, signed.

In my window-treatment project, nothing like that was ever signed. Which meant, by default, the software was mine. Not because I planned it that way. Because ownership defaults to the creator, and nobody had written down anything different.

I'm not telling you this so builders can trap clients. The opposite. The lesson is that ownership has to be decided on purpose. When you let it drift, you end up exactly where I was: a half-built company where everyone quietly assumed something different about who owned what.

A clean license fixes that for everyone. It tells the client exactly what they're getting: the right to use the software, not to own it. No surprises if the relationship ends. No fights over something nobody clearly defined.

How I Restructured the Deal

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

The pricing had three parts.

One: a one-time setup fee. This covers the real cost of building the system and getting it running inside their specific business. Day-one work, paid on day one.

Two: a usage fee that only kicks in after I've grown their revenue past a set point. This is the piece I'm proudest of. I don't charge usage from dollar one. The fee activates only once the software has already pushed their revenue above an agreed number. Below that line, they pay nothing extra. Above it, I share in the growth my system created.

The logic is simple. I get paid more only when they're genuinely better off. If my system doesn't move their numbers, that fee never turns on. My upside is tied directly to their results.

Three: an optional monthly retainer. This gives me steady income and gives them a system that keeps getting sharper, because the person whose job is to improve it stays attached to it.

Put together, everyone's pulling the same direction. They get a system that runs their business, they only pay growth fees once they're actually growing, and they get someone on the hook to keep making it better. I keep my software, get paid for the build, share in real results, and have steady income that doesn't depend on landing the next deal.

The Risk I Almost Missed

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

When you license software to someone running several companies, there's a danger most solo builders never think about until it's too late. If one of those companies hits financial trouble, a poorly written license can let creditors treat my software, the thing I supposedly owned, as an asset of their failing business.

In plain terms: if their company goes under, my work could get dragged into the wreckage and fought over by people I've never met.

The license had to be written specifically to keep my software separate from the client's troubles. Clear ownership language. A clean line between "you can use it" and "you own it."

I'll be honest. I would not have thought of this on my own. I'm good at building systems and structuring deals. I am not a bankruptcy lawyer, and it showed. A few hundred dollars of legal review protected an asset I'd spent weeks building. Cheapest insurance I've ever bought.

That's the lesson builders skip. You can design a brilliant deal and still lose everything because you didn't protect it legally. Two separate jobs. Capture the value with a smart structure. Protect it with a short legal review.

If Someone Is Building Software for Your Business

Settle ownership before the first line 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 surprises. The builder keeps ownership and stays on to keep improving it. And payment ties to whether the system actually grows your business, not a flat invoice that gets sent whether it works or not.

That's exactly how I work with the people I build for. They run 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 wants the same outcome.

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

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

Get AI insights for business leaders

Practical AI strategy from someone who built the systems — not just studied them. No spam, no fluff.

Ready to automate your growth?

Book a free 30-minute strategy call with Hodgen.AI.

Book a Strategy Call