What Buyers Actually Read in Your README (and What They Skip)

A buyer gets your Acquire.com listing link at 10pm. They read the financials, like what they see, and click through to your GitHub repo. You have about three minutes.

Not three minutes to impress them with clever code. Three minutes before they decide whether to book a call or close the tab.

Most vibe coders have never thought about their app readme for acquirers. They wrote it once, during the build, following some open-source tutorial: project description, installation steps, contributing guide, license badge at the top. That is a developer README. Buyers read it differently, in a different order, with a completely different set of questions.

Here is what actually happens during that first repo visit.

The Buyer's First 3 Minutes: A Step-by-Step Scan

Operators and micro-SaaS buyers on Acquire.com and Flippa describe the same repository review pattern.

First, they land on the README and scan, not read. Three questions: what does this do, what is the tech stack, how much does it cost to run. If any of those are buried below the fold, attention is gone.

Before they finish the README, they click the file tree. They are looking for an ARCHITECTURE.md, an env.example, a prompts/ folder. A repo with a handful of clear files and a prompts folder looks completely different from one with 47 nested directories and nothing labeled.

Then they click one or two specific files: usually env.example and either ARCHITECTURE.md or the main entry point. What they find in those two files shapes everything that follows.

The README Sections That Actually Get Read

The first 10 lines

The opening of your README does more work than anything else in the repository. Buyers want three things immediately:

1. ·One sentence describing what the app does and who it is for
2. ·A link to the live app (or a screenshot if it is not public)
3. ·The current MRR or ARR, or at minimum a link to the listing

You do not need polished writing here. You need to answer "what is this and is it making money" before the buyer has to scroll. If they have to hunt for that, they are already forming doubts.

The tech stack block

A short, formatted list of your stack is the second thing buyers look for. Three lines is ideal:

Stack: Next.js + Supabase + Stripe + Vercel
AI: built with Cursor, uses OpenAI API for [core feature]
Cost: ~$85/month at current scale

Buyers love a three-line stack. It tells them the app is simple enough for one person to operate. If your stack requires 12 lines to explain, that is not reassuring, it is a warning sign.

Setup and deployment

Buyers skip lengthy tutorials but read setup blocks carefully. A tutorial explains how something works. A setup block tells them what they need to run it themselves. Give them the second one: numbered steps to get the app running locally, every environment variable called out, and the deployment target ("deployed to Vercel via GitHub Actions" is one line and plenty). A wall of npm install commands with no context, or a single line pointing to separate docs, is not a setup block. It is avoidance.

Known issues and limitations

This section surprises most sellers. Buyers actually trust you more when you list known issues. A short "Known Issues" block with two or three honest items reads as organized and self-aware. A missing section reads as either "the seller does not know their own app" or "they are hiding something."

Keep it honest and short:

• ·"Mobile layout has layout shift on Safari iOS, low priority fix"
• ·"Support emails currently route to Gmail, will need migration on handoff"
• ·"Supabase free tier used for dev environment, production is on Pro"

Three bullets. Done. You have just saved two days of tense back-and-forth during diligence.

If you want to see how documentation fits into the broader handoff process, our guide on transferring an app you built with AI covers the full scope of what buyers need from you after they say yes.

The Files Buyers Click Immediately After the README

env.example

This single file does more due diligence work than any other file in your repo. Buyers count your environment variables. They read each variable name. They are asking:

• ·How many external services does this app depend on?
• ·Are there any APIs I do not recognize?
• ·Is anything hardcoded that should not be?

Eight to 12 variables, each with a short comment explaining its purpose, tells the buyer they are looking at something maintainable. Forty unnamed variables tells them the app is held together with tape.

If you built with Cursor or Bolt and never created an env.example, make one now. It takes 20 minutes and it will come up in every serious buyer conversation.

ARCHITECTURE.md

Not every buyer reads this file, but the serious ones do. A short ARCHITECTURE.md shows that you built something intentional, not something you are still figuring out.

You do not need diagrams. You need four short paragraphs.

A simple format:

## What this app does
[One paragraph summary of the core product]

## How data flows
[The main user action and what happens to the data]

## Key integrations
[External services and what they handle]

## What you need to run this
[Any specific setup beyond the env.example]

One page. That is enough. If you built your app with Cursor and used Claude to generate the code, you can use Claude to write this file too. Paste your codebase in and ask it to explain the architecture in plain English, then clean it up. The result is usually solid.

The prompts folder

If your app uses AI, your prompt logic is part of the product. Buyers know this. If you have a prompts/ or lib/prompts/ folder, they will open it.

If your prompts are the core value driver (a content generation tool, an email writer, a lead enrichment bot), this folder is essentially the IP they are buying. Keep it organized. Name files clearly: summarize-feedback.txt, generate-cold-email.txt. Buyers understand that prompt engineering is real work with real value. Treat it that way.

For a full picture of what goes into a documentation package buyers want to see, the guide on what to write down before you sell walks through the complete set.

What Gets Skipped in the First Pass

The pattern: anything written for a developer or open-source contributor gets skipped in the first pass. Buyers are not trying to contribute to your project. They are trying to decide if they can run the business.

The Developer README vs. the Acquisition README

Here is the most common README mistake in listed repos on Acquire.com. The seller has written a developer README: detailed local installation steps, a contributing guide, a code of conduct, a link to the Discord server.

That README is a liability during a sale. It tells the buyer you were building for a team, not for transfer. You optimized for developer onboarding rather than operator confidence. They now have to rewire their mental model before they can even evaluate what they are buying.

An acquisition README leads with revenue and stack, not setup. It describes the business first, then the technology. It answers "can I run this" before it answers "how was this built."

If your README reads like a developer onboarding guide, spend two hours rewriting the top section. Move business context up. Move installation steps down. Add the env.example and known issues. That two-hour rewrite can shorten due diligence by a week.

Where Most Vibe Coders Get This Wrong

The most common mistake is not what you put in the README. It is what you leave out.

We see sellers invest hours in a polished Acquire.com listing: clean revenue charts, professional screenshots, compelling copy. Then the buyer clicks the GitHub link and finds a README with a single line: "This is a [product name] built with Next.js."

That gap destroys trust faster than almost anything else. The buyer thinks: if they did not document this app for a buyer, what else did they not do?

The README is not supplemental to your listing. It is part of your listing. Buyers treat it as the first test of how organized and transfer-ready you are. A clean repo with a clear README can justify a 10 to 20 percent premium at negotiation, because it cuts the buyer's perceived risk. Bus factor risk, how dependent the app is on one person, is one of the top valuation discounts buyers apply, often 15 to 30 percent off a fair asking price. A well-documented repo is the clearest evidence that the app does not collapse when you walk away.

Spend two hours on your README before you spend two hours on your listing copy. It will matter more.

A Pre-Listing README Checklist for Acquirers

Before you submit your app for review on Acquire.com or Flippa, run through this list:

1. ·First 10 lines include: what the app does, a live link, and current MRR
2. ·Tech stack is a formatted block (backend, database, payments, hosting, AI)
3. ·Monthly infrastructure cost is stated
4. ·Setup is a numbered list, not a paragraph
5. ·env.example exists, variables are named, each has a comment
6. ·ARCHITECTURE.md exists and describes the data flow in plain English
7. ·Known issues: 2 to 3 honest bullets
8. ·A note on what is not in the repo: credentials, manual steps, external accounts

Eight items. If you can check all eight, you are better prepared than most sellers currently on the platform.

For the full timeline of tasks leading up to your listing, the 30-day pre-listing checklist breaks everything into weekly sprints. And if you want to see what happens after a buyer reviews your repo and moves into formal diligence, our due diligence guide for vibe-coded apps covers every stage of what gets checked.