The Scheduling App Their Company Didn't Actually Own

The situation

Vivian worked as an early childhood educator, and in her spare hours she ran a small side business with two friends, Emily and Tom, who put in evenings and weekends around Tom's day job as a factory technician. The three had incorporated a company about six years earlier to sell a booking and attendance tool used by community recreation programs — swimming lessons, day camps, after-school sports leagues — to manage registrations and track who showed up. It was not a large operation. Revenue sat somewhere in the high six figures, enough to pay a small support contractor and keep the lights on, but nothing that had ever needed serious legal structuring.

The software itself had been built years earlier by an independent web developer the three had found through word of mouth. He wrote the original booking engine, the parent-facing app, and the administrative dashboard over about eight months, invoiced in stages, and was paid in full. There was no written contract beyond a short email describing the scope of work and the price. Nobody thought to ask who would own the code once it was finished.

That gap sat untouched for years, because it never mattered — the developer moved on to other clients, the company kept using the software, and everyone assumed it belonged to the business that had paid for it. Vivian, Emily and Tom had, at various points, hired a second contractor to fix bugs and add features, and had made small changes themselves, layering new work on top of a foundation none of them had ever formally owned. It surfaced only when a larger recreation-software company approached the three shareholders about buying the business outright, at a price that would have let all three step back from the company for good.

What the buyer's lawyers found

Due diligence is the process a buyer's lawyers and accountants go through before closing a purchase, checking that everything the seller claims to own is actually owned free and clear. Early in that process, the buyer's counsel asked for the assignment agreement confirming the company held full copyright in its own software. There wasn't one.

Under Canadian copyright law, the default rule surprises a lot of business owners: when a company hires an employee, the company generally owns what that employee creates in the course of their job. But when a company hires an independent contractor — someone invoiced as a business, not paid through payroll — copyright in the work stays with the contractor unless a written agreement assigns it to the client. Paying the invoice does not transfer ownership. It only pays for the contractor's labour. Without a signed assignment, the developer who built the booking engine still legally owned the code, years after he had cashed the last cheque and stopped returning calls.

The buyer's lawyers flagged it as a material risk. A company being sold for its software cannot close a sale on software it does not actually own, and the buyer would not proceed without a clean chain of title — clear, documented proof of who held the rights at every step. The deal, worth a meaningful multiple of the company's annual revenue, stalled while Vivian, Emily and Tom scrambled to find the original developer and figure out what he would want in exchange for signing away rights he did not know he still had.

What we did

1. Traced the actual ownership first. Before approaching the developer, we reviewed every invoice, email and version of the software to confirm exactly what he had built versus what later contractors and in-house tinkering had added since. Ownership questions get expensive when they are vague, so we mapped precisely which components were originally his.
2. Located and approached the developer directly. He was still working locally and had no idea the company was being sold. We contacted him plainly: the company wanted to formalize what everyone had always assumed, and was prepared to pay for a proper written assignment of copyright in the original code.
3. Anticipated his leverage, because he had real leverage. Once the developer understood a sale was in progress, he understood he held something the deal could not close without. He asked for a payment tied to the value of the transaction rather than a flat fee, and for the right to keep using a version of the code for his own future clients. Both requests fell within his rights as the copyright holder.
4. Negotiated a structure both sides could accept. Rather than a full, unconditional assignment, we negotiated an agreement where the developer transferred ownership of the specific code used in the company's product, in exchange for a payment in the low tens of thousands of dollars, while retaining a personal licence to reuse the general booking-engine architecture — but not the company's branding, client data structures, or specific business logic — in unrelated future projects.
5. Documented the assignment to survive scrutiny. The final agreement included a clear description of exactly what was assigned, what the developer retained, and warranties that he had not already licensed the code elsewhere in a way that would create competing claims. That documentation was what the buyer's lawyers actually needed to close.

The outcome

The sale closed about ten weeks after the ownership gap surfaced, roughly six weeks later than originally planned. The three shareholders paid the developer just under $30,000 for the assignment, a cost that came directly out of the eventual sale proceeds and was negotiated as a closing adjustment with the buyer. It was not the outcome anyone wanted going in — a clean, retroactive assignment at no cost, with no strings attached, was never realistically on the table once the developer understood what was at stake.

What both sides got instead was workable. The company secured full, exclusive ownership of everything the buyer was actually purchasing: the booking engine, the parent-facing app, the administrative dashboard, and all client data structures built on top of them. The developer walked away compensated for something he had genuinely held for years without knowing its value, plus a narrow personal licence to reuse general architecture concepts — not the company's specific product — in work that would never compete directly with the business he'd helped build. The buyer got the clean chain of title its lawyers required, and the deal closed on revised terms rather than collapsing.

Vivian, Emily and Tom kept the bulk of the sale value, adjusted downward by the assignment cost and the delay. Nobody involved considered it a full win, but nobody walked away feeling cheated either — which, in a negotiation that started with one side realizing it never owned what it thought it did, was close to the best realistic result.

The six-week delay carried its own cost beyond the direct payment. The buyer's financing had been arranged around an original closing date, and pushing the transaction back meant renegotiating that timeline too, which added its own layer of pressure to an already tense set of talks. None of it sank the deal, but it was a reminder that an ownership gap discovered during due diligence rarely stays contained to a single line item — it tends to ripple into financing, timelines, and the goodwill between buyer and seller that a smooth closing depends on.

What you can learn from this