Buying a custom software development shop in Canada

Buying a custom software shop means buying people and promises: a team that can keep delivering, clients who will keep commissioning work, and contracts that say what each side owns. The difficulty is that the valuable parts are the ones that can leave. This guide is for someone judging an opportunity before making an offer.

A good shop and a weak one can show the same revenue

The test for any shop is what survives the seller’s departure. Signs of a shop that can be relied on include work contracted beyond the current engagement, clients who have returned for successive projects, and delivery spread across senior and junior developers so that no single person carries the architecture. Signs of weakness include revenue concentrated with one or two clients, a lead who estimates, designs and manages everything, and a long tail of projects won once and never repeated. Ask for revenue by client over several years and see who left and why. Ask to meet the people who would do the work. The answers can show things the profit and loss does not, and they are the substance behind key person risk and customer concentration.

What a seller may not volunteer

Put the following to the seller early, because the answers shape whether the rest of your work is worth doing.

• Who actually writes the code. A shop that looks like a large bench of developers may be a few employees and many subcontractors. That matters for ownership, because the Copyright Act’s employer default covers an author employed under a contract of service (section 13(3)); everyone else needs a written assignment. For payroll purposes the CRA separately distinguishes an employee under a contract of service from a self-employed worker under a contract for services, who is not under the payer’s direction or control.
• Which projects are fixed-price, and where hours already spent exceed the estimate.
• Whether any client has complained about a deliverable, withheld payment, or threatened to leave.
• Which clients deal with the seller personally, and whether any would stay on the strength of an introduction alone.
• What has been promised informally, such as discounts or free changes, since a new owner inherits the relationship without the history behind those promises.
• The shop’s record of security incidents. A seller who has kept one can produce it quickly.

Asset deal, share deal or acquihire

The shape of the deal follows what you actually want. If you want the client book, the contracts have to come with the shop, and whether they can depends on how each one treats assignment and change of control. If you want the team more than the clients, an acquihire centres on employment offers and retention rather than contracts, and the seller may wind down or keep the remaining client work. In a share purchase the company comes with its history; in an asset purchase you negotiate what you take and what you leave. Each choice can also change the tax outcome for both sides, a question for your accountant before you draft an offer, and it can change what a lender will finance, covered in financing a custom software development shop acquisition.

Employees add a layer that varies by province. Ontario’s guide to the Employment Standards Act says that where an employee of the seller is hired by the purchaser of a business, the employee does not start as a new employee for the purposes of certain ESA entitlements but gets credit for past employment, unless the employee is hired more than 13 weeks after their last day of employment with the seller or the day of the sale, whichever is earlier. British Columbia’s Act deems the employment of an employee of a business that is disposed of, in whole or in part, to be continuous and uninterrupted by the disposition, for the purposes of that Act. Other provinces have their own employment standards statutes, so ask where the developers actually work and have counsel check that province’s statute.

What you take on personally

Beyond the legal checks, the demands on a buyer are practical. You need a lender willing to finance a business whose assets are mostly people. You need technical credibility with the team, since developers who respect the seller may not respect an owner who cannot read their work. And you take on the legal responsibilities of whoever controls the data. Under PIPEDA, the organization in control of personal information is the one that must keep breach records and report breaches that pose a real risk of significant harm, so whichever structure you choose, find out what the shop has actually been doing. In Quebec, the Commission d’accès à l’information says that any person who operates a business is responsible for protecting the personal information it holds, that the person with the highest authority exercises the function of person in charge of the protection of personal information but may delegate it in writing, in whole or in part, and that the business must publish that person’s title and contact details on the business’s website, or by other appropriate means if it has none.

Why your own profile as a buyer matters

A buyer who wants delivery capacity and client relationships weighs a shop differently from one who wants mainly the team, and an individual buyer weighs it differently again. Knowing which you are shapes your offer. A buyer with a shop of its own could absorb the loss of a client or two; a buyer who wants mainly the team may care most about retention and pay little for the backlog; an individual buyer carries all the concentration risk personally and may need the handover period most. None of these is more legitimate than another. They weigh risk differently. Whatever your profile, who owns the code comes before price; see who owns the code when you buy a small software company.