What a buyer opens first

I built the product at two companies that were later bought. OwnAmerica, a rental investment marketplace, was acquired by Renters Warehouse in 2019. 64 Analytics, a college baseball and softball analytics platform, was acquired by Rule42 in October 2026.

So when I build an early product, I build it for a reader most founders forget about: the person who shows up later to decide whether it is worth buying.

Who that person is

When a company wants to buy yours, or invest in it, they do something called due diligence. That is a formal look under the hood before any money moves. Part of it is financial. Part of it is technical, and that part is done by an engineer whose whole job that week is to find out what is really there.

That engineer is not impressed by your demo. They have seen a lot of demos. They want to open things.

You don't have to take my word for what they open. Buyers publish their own lists. saas.group, a company that buys software businesses, wrote up the questions it asks founders who built with AI. Acquire.com, a marketplace for selling them, keeps a list of diligence red flags. Read both. They rhyme.

The questions underneath every list

Strip the checklists down and the same handful of questions is left.

• Do you actually own this? The code, the accounts it runs on, the domain, the rights to all of it.
• Can someone other than the founder run it? Or does the whole thing live in one person's head and one person's laptop?
• Has a person checked the security? Not "the AI said it was fine." A person.
• Do the tests mean anything? Or are they decoration?
• Does the money add up? If it charges customers, can you show that what was billed matches what was collected?

An app that was prompted into existence over a few weekends can do well on a demo and badly on every one of these. Nothing about that is obvious from the outside. It becomes obvious the day somebody asks.

The folder I build as I go

I call it a diligence pack. It is the folder a buyer asks for first, and I put it together while the product is being built, not in a panic afterwards. Here is what is in it.

1. Ownership. The code repository, the cloud account and the domain are in your name, not mine. The contract says the work is yours.
2. Architecture notes. One page and a diagram that explain how the thing fits together. Plus a file of instructions for AI agents, so the next owner's tools can work on the code without making a mess.
3. A security check a person did. Logins, who can see which data, where the passwords and keys live, and the outside code the app depends on. Read by me, with what I found written down.
4. Tests that matter. Automatic checks on the parts that hurt if they break: signing up, paying, and who is allowed to see what. And no test that an AI quietly edited until it passed.
5. A runbook. How to put a new version live, how to undo it, how to change the keys, and who to call.
6. AI provenance. What the agents wrote, who reviewed it, and what got rewritten. A buyer is going to ask how much of this was AI. "Most of it, and here is the review trail" is a good answer. A shrug is not.
7. Bus factor. That is the grim nickname for how many people could get hit by a bus before nobody can run the product. The pack names at least two people who can deploy, and lists who has access to what.
8. The billing path. How a charge travels from the customer to your bank account, and proof that the two ends agree.

Why do this on day one

Because it is cheap on day one and miserable on day four hundred.

Writing down a decision the week you make it takes ten minutes. Working out, a year later, why the app was built a certain way takes days, and sometimes the honest answer is that nobody knows. A buyer's engineer can tell the difference between notes written along the way and notes written last weekend.

There is a second reason. Building for that reader makes the product better right now. If a stranger can deploy it from the runbook, so can you at two in the morning. If the tests cover payments, you find out about a payment bug before your customers do.

If you never plan to sell

Build the folder anyway. The buyer is only the strictest version of a reader you are definitely going to meet.

The next engineer you hire will ask the same questions. So will an investor, a big customer's security team, and the person who takes over when you want a vacation. The pack answers all of them.

I can't promise anybody a buyer. Nobody can. What I can do is make sure that when someone opens the hood, what they find is boring. In this business, boring is the compliment.

If you want to know how your product would hold up to that look today, that is what a second opinion is for. Or book the free half hour and we will start there.