The first 100 days owning the software you acquired.

You own a business that depends on software you did not build, and there is nobody on the payroll you can hand it to.

This is written for search funds, holdcos, and independent sponsors who closed on a durable small company and inherited its software along with the staff and the customer list. In Stanford Graduate School of Business's 2026 search fund study, covering 862 funds in the United States and Canada, the aggregate return on investment was 4.75x. The model works. What it does not tell you is who keeps the software running on the first Monday after close.

If you ran technical diligence, most of this confirms what it told you. Our guide to what tech due diligence finds in a business you are buying ends where this page begins, at closing. For the wider context, read building software without a tech team.

The order matters more than the speed. Custody first, because access gets harder to collect as the weeks pass. Continuity second, because the risk you cannot see is the one that resigns. The rebuild question last, once you understand the business.

What should happen in the first 100 days?

Four things, in sequence. Take custody of every account and repository in the first week. Map the single points of failure in the first month. Make a deliberate salvage-or-rebuild call inside the first quarter. Name who runs the software by day 100. Everything else, including the features people will start asking you for, waits.

None of it requires you to read code. It requires you to hold the accounts, ask a short list of questions, and refuse to make the expensive decision early.

What do you take control of in the first week?

Every account the software touches, moved into the company's name and off the seller's personal logins. That means the repository, the cloud and hosting accounts, the domain and DNS, app store listings, third-party services and API keys, the database and its backups, and the payment processor. Collect first and change nothing.

Do this while the seller is still helping. Goodwill sits at its highest in the days right after close, and a request that took one message in week one becomes three unanswered emails a month later. Access does not get easier with time.

In the company's name means something specific. The account sits on a company email address you control, billed to a company card, with recovery routed to a company mailbox. A login the seller shared with you is not custody. Ask for a transfer rather than a seat.

Who really keeps this system running?

Usually one person, and usually not on your payroll. Find out who, and what happens if they stop answering. In an NAIC survey cited by the Insurance Information Institute, 71% of small firms said they depend heavily on one or two key people. In software, that is the whole system living in one head.

That dependency has a name. Key-person risk is the first thing a buyer's engineer looks for, and closing does not clear it. If diligence flagged it, the flag is yours now.

Ask these in person and write down the answers. You are not auditing anyone. You are finding out what the company does on the day an answer is no.

• Who can change this system safely, who else has ever done it, and what notice would they give?
• What is written down, and could a competent stranger follow it without a phone call?
• Which accounts, servers, or licenses sit on a personal address instead of a company one?
• When was a backup last restored, rather than last taken? An untested backup is a hope.
• What breaks at month end, quarter close, or peak season, and who fixes it now?

Two answers matter most: the person and the restore. A contractor with no obligation to you, and a backup nobody has tested, are the first two items on your plan.

Should you keep the inherited software or rebuild it?

Decide it from a read of the system, and decide it inside the first quarter. An audit covers the code, the infrastructure, and what the system costs to run, then ends in a salvage-or-rebuild call with a number attached. Sound systems need an owner and some stabilization. Fragile ones cost less to replace than to untangle.

Schedule the decision, because the alternative is drift. Nobody announces a rebuild. It arrives as a run of small refusals, until eighteen months later the company is paying for a replacement it never chose.

Our comparison of rebuild vs rescue walks the trade-off. In short: keep the system when it does the job and a new engineer can read it. Replace it when making it safe to change costs close to building it again, or when its platform carries vendor lock-in that makes any real change a rewrite. An audit runs about one to two weeks and directionally $5,000 to $15,000, credited in full toward whatever follows.

What should you not change in the first 100 days?

A working system, while you are still learning the business it serves. The expensive mistake in this window is a rebuild decided before anyone understands why the software does the strange things it does. Nearly every strange thing is a customer, a regulation, or a hard-won lesson wearing a disguise.

• The workflow the staff trusts, until you have watched them use it for a month.
• Feature requests queued before the deal, for a company you did not own yet.
• The technology choices, unless the audit says they carry real risk.
• Hosting and third-party costs, until you know what each one holds up.
• Anything the busiest week of the year depends on, until you have seen that week.

Two exceptions are worth making immediately. Fix anything that exposes customer data, and get backups running and tested. Those are not improvements. They are the floor.

Do you keep the developer who built it?

Often yes, for a defined period, and rarely forever. The person who built the system holds knowledge no document captured, and a few months of it costs less than rediscovering it. Retain them on a written handover with an end date, so the arrangement moves knowledge across instead of extending the dependency you inherited.

Be fair-minded here. The incumbent is rarely the villain. They built something that carried a real business for years, often alone and on a small budget. Treat the retention period as buying what they know, priced properly.

Retain them when

• They are willing to write things down and train whoever comes next.
• A season, a cycle, or an annual filing is coming that nobody else has run.
• The salvage-or-rebuild call is open and continuity buys time to make it well.

Replace them when

• They treat account access as leverage rather than a transfer to complete.
• They decline to explain how the system works, or the explanations do not hold up.
• The audit finds work that is unsafe to extend and they disagree there is a problem.

How to run the retention period

• Write down hours, response times, a start date, and an end date. Treat an extension as a new decision.
• Define the deliverable as a system someone else can run, rather than availability by phone.
• Put the receiving team in the room from week one, and capture the handover as you go.

Run this way, it ends with a documented system and a clean parting. Run loosely, it ends where it started, with one person holding the only copy.

What does it cost to run inherited software?

Three arrangements are worth pricing: an in-house hire, a fractional CTO, or an ongoing engineering partner. Ego Eimi's embedded team runs about $14,000 to $48,000 a month depending on scope, and the ranges are published. What decides it is how much software work the business generates and how much of it you want to manage.

Hiring in-house is the right answer more often than a studio likes to admit. If the company generates a full-time stream of software work and someone can manage an engineer, a permanent hire compounds in a way an outside arrangement cannot. Our comparison of in-house developers vs an agency puts both cases side by side.

A fractional CTO buys senior judgment a few days a month. It does not put software into production, so companies needing both pair it with a team that builds.

The third is an ongoing engineering partner, which is what Engine, our embedded engineering team, is for. One senior owns the account, work ships continuously, and the repository, infrastructure, and documentation stay in your name from day one. It runs about $14,000 to $48,000 a month, with ranges on our pricing page. If you buy again, the same arrangement carries to the next company.

There is a fourth option, and it gets chosen by default: nobody owns it. That holds until the first thing breaks at month end.