Technical checks before you buy a small software company

A searcher or independent sponsor who finds a small software company usually has a lot riding on one deal: investor money, a personal guarantee or reputation, often a lender, and years of their own working life. The target is typically run by its founder. The financials have been reviewed, the customers look loyal, the margins look good. The technology is the part nobody on the buying side can read.

That gap is easy to put off. Before the letter of intent there is no access, and during exclusivity the quality of earnings work, legal review and financing all compete for the same weeks. Yet the price usually assumes one thing the numbers cannot show: that the product will keep running, and keep being changed, after the founder steps back.

This article is for that buyer. It covers what can be checked before the LOI with public information and a management call, which answers should worry you, what to ask for in the first week of exclusivity, how to size a technical review to a small deal, and how lenders and investors read what the review finds.

Three stages, three levels of evidence

What you can know about the technology depends on where you are in the process. Before the LOI you see what the company shows the world and what the founder tells you. In exclusivity you can see the systems themselves. Treat the first as signals and the second as evidence, and do not confuse the two.

Before the LOI: the outside and one call

What the product shows from outside

A surprising amount is public. None of it needs access, and none of it should involve probing the company's systems. Read only what any visitor or customer would see.

• Use the product. Sign up for a trial if there is one. Reset a password, change a plan, try to delete an account. Note error messages, slow pages and anything that looks unfinished. Small products show their age in these corners.
• Read the app store listings. The date of the last update, the minimum operating system it supports, reviews that mention crashes. Check who the listed developer is: a person's name instead of the company's is an ownership question for later.
• Look at what the browser receives. Page source and response headers often name the framework, the content system or the hosting provider. An old version string is a signal, not a finding.
• Check public DNS and email records. They show who hosts mail and whether basic email authentication is set up. Public certificate logs can list subdomains such as staging or admin. Note them; do not visit or test them.
• Read the privacy policy and the subprocessor list. Compare them with what the product does. A policy that names vendors the product no longer uses, or misses ones it clearly does, says something about how carefully data is handled.
• Follow the release history. Changelogs, release notes and a status page show how often the product changes and how often it fails. Long silences matter as much as frequent incidents.
• Read the job posts and the website footer. Old job posts reveal the stack. A "built by" credit points to an agency, which raises questions about who owns the code and who holds the accounts.

An outside-in read tells you about the stack, the age of the product and the security posture it shows the world. It cannot tell you who owns the code, how the team works or what the cloud bill really is. Those need access.

The management call

The founder knows the system better than anyone, and most founders answer honestly. The problem is that "yes, that is handled" sounds the same whether it is true or merely hoped. Ask questions whose answers are concrete facts, then listen for the answers that should slow you down.

• Who can put a change into production today, and when did that last happen? Worrying: one name, or "I would have to ask our developer."
• Whose name and whose card are on the cloud account, the domain and the app store account? Worrying: "mine, personally" is fixable with a plan; "the agency takes care of that" needs a closer look.
• Who has written code for the product, and did each of them sign an IP assignment? Worrying: "an agency built it, we have the invoices." Paying for work does not by itself transfer ownership of it.
• What happens when the product breaks at night or on a weekend? Worrying: "I fix it" or "it never really breaks."
• When did you last restore a backup to check it works? Worrying: "the host does backups."
• What do you still do by hand every week that customers depend on? Worrying: a script the founder runs, an export they clean, invoices they correct. Each is a job someone has to take over.
• Has there ever been a security incident, data loss or customer complaint about data? Worrying: "we would know if there had been," with no logging or monitoring to support it.

Write the answers down. In exclusivity they become the first things to verify, and a gap between what was said and what the systems show is a finding in its own right.

The first week of exclusivity

Exclusivity in a small deal tends to be short, and the technical work competes with everything else. Ask for access and a short request list in the first days, not after the quality of earnings work has started. A short list gets answered. A long one turns into a seller's project and a lost week.

1. Read-only access to the code repositories and the cloud console, including the billing view, through named accounts the company creates.
2. A list of every account the product needs: cloud, domain, DNS, app stores, payment processor, email delivery, other services. For each one, the holder and the payer.
3. A list of everyone who has written code, employees, contractors and agencies, with their agreements or a plain statement that none exist.
4. Agency contracts for the product, in full.
5. Twelve months of hosting, software and service invoices.
6. Any security assessment, penetration test, SOC 2 report or customer security questionnaire the company has answered, and any incident history.
7. An hour with the person who knows the system best, and a screen-shared walk through one deployment from code to production.

One practical point. The key developer, often a long-time contractor, may not know the company is for sale. When and how they are brought in is the seller's decision, but it should be agreed early, because the most important technical interview of the deal depends on it. All of this runs under the access protocol: read-only, time-limited, closed at the end.

Sizing the review to a small deal

A small company does not need a review built for a large one. It does need one that reads the right places. The useful sequence is risk first, depth second.

A red-flag memo reads all six layers but follows risk: who controls the code and the accounts, how personal data is handled, what the product is built on, who knows how it works. It samples where a full review would read everything, and it says so. It opens with one of three views: go, go with conditions, or stop and look closer. It usually takes 5 to 10 business days once access works, which in a short exclusivity is already a meaningful share of the window.

From there the memo points the way:

• Go. Findings belong in the post-closing plan. For many small deals the memo is enough.
• Go with conditions. Specific items to fix before closing, price or cover in the agreement. A targeted look at one or two of them may be worth more than a full review.
• Stop and look closer. Do not commit more money until the issue is understood. Often a document or a focused check settles it. Sometimes it calls for full technical due diligence.

As a rough rule, the more the value of the company is the software itself, the more the full review earns its cost. A SaaS product with no other assets is a different purchase from a services business with a booking tool attached. The work done for a memo counts toward the full review, so starting small does not mean paying twice. Our guide to technical due diligence for buyers covers the full read in more detail.

Owner-operated software traps

Founder-run software companies tend to fail a review in the same few places. None of them is rare, and none is automatically fatal. Each needs to be seen, sized and planned for before the price is fixed.

One developer

Many small products are maintained by one person, often a part-time contractor who has been there for years. That person holds the knowledge, often the access, and sometimes, without a signed assignment, a claim to the code. A sale changes their position. The technical side of the answer is to write down how the system is deployed and run, move access into company accounts, and plan for a second engineer to work alongside them before the founder leaves. Any arrangement to keep them through the transition is for the buyer and counsel to decide.

Agency-built code

When an agency built the product, three questions come first: does the contract assign the code to the company, does the agency keep a reusable framework it only licenses, and does the agency still hold the repository or the hosting. The relationship may also end with the sale. Our article on ownership gaps that stop a software deal covers how these are checked and moved.

No automated tests

Common in small products, and not a deal breaker on its own. It matters where money moves, such as billing and payments, and where you plan to make changes after closing. Without tests, every change is slower and riskier, so the first months of your plan need time to add them around the parts that matter most.

Hosting on the owner's card

The cloud bill paid on a personal card is a transfer task, and also a cost question. The figure in the financials may not be the real one: credits that expire, a personal account shared with the owner's other projects, free tiers the product has outgrown. The real run cost after closing belongs in your cash flow model, next to the quality of earnings work.

Our engineering partner PERETZ covers the wider audit of a product before purchase, including search visibility, data quality and user experience, in How to Audit a Website or Digital Product Before You Buy It. Here the focus is narrower: what a technical finding means for a small acquisition and the people financing it.

How lenders and investors read a finding

Lenders, including those in SBA-financed acquisitions, may ask whether there is technical risk that could affect the business. Investors in a search fund will ask the same question in their own words. Neither wants a long report. They want to know three things.

• Does anything threaten the cash flow? A product that could stop working, lose customer data or lose customers when the founder leaves is a risk to the loan and to the thesis.
• Does anything need money soon after closing? A cost to fix that falls in the first months may need to be in the sources and uses or the working capital plan, not discovered in the first quarter.
• Is there a plan, and is it funded? A Critical finding with a fix agreed before closing reads very differently from an open one.

This is why every finding needs a severity, the evidence, the business impact and a cost range with its assumptions. A lender or investor who reads "High: the only person who can deploy is a contractor without a signed assignment; fix before closing; cost and time stated" can act on it. "Some key person risk" gives them nothing. If a lender or investor needs to rely on the report formally, say so before the work starts, so reliance can be agreed in writing.

A searcher's technical checklist

Before you sign the LOI:

• Use the product as a customer and note what feels old or broken.
• Check app store listings, the developer name, public DNS and the privacy policy.
• Ask the management call questions above and write down the answers.
• Make sure the LOI timeline leaves room for a technical review and an early start on access.

In exclusivity:

• Send the access request and the short list in the first days.
• Agree with the seller when the key developer will be brought in.
• Start with a red-flag memo and let it decide where to go deeper.
• Match every code author to a signed assignment or an agency contract that assigns the work.
• Confirm the real hosting and service costs against the financials.
• Share findings with your lender and investors in severity, impact and cost, and give counsel the points that belong in the agreement.

Between signing and closing:

• See each account move done, with the buyer's people as owners.
• Get the deployment and recovery steps written down and walked through by someone other than the founder.
• Rotate shared passwords and keys at closing, and remove access for anyone leaving.

What to do next

If you are still looking at a teaser, do the outside-in read and the management call first. They cost you little and often show where the hard questions are. If you are about to sign an LOI or have just entered exclusivity, start the technical work in the first week, not the last.

A red-flag memo gives you a view your lender and investors can read, and tells you whether a full technical due diligence is worth it. See how we work with search funds and independent sponsors, or what the report contains.

Questions