Every acquisition listing carries an asset schedule. We read 630+ of them, then cross-cut the answers against revenue, price and multiple to find out which assets actually move the number.
Every acquisition listing carries a field almost nobody reads: the asset schedule, the list of things the seller says are included in the sale. It sits below the revenue figure and above the growth pitch, and it is the closest thing the market has to a written answer to the question founders ask right before they sign. What am I actually handing over?
We read that field on 630+ live listings. Only 61.3% name the codebase and only 77.6% name the customers. Roughly two in five businesses being sold appear to transfer no software at all. That is the starting point, not the finding. The finding is what happened when we cross-cut that field against trailing revenue, asking price, multiple and business type. One of those two gaps survived. The other dissolved. For the price side of the same dataset see the state of SaaS acquisitions, and for the timeline see how long it takes to grow a SaaS.
Ask a founder what they are selling and they will say the MRR. Ask a buyer what they are buying and they will say the MRR too. The document that closes the deal is not about MRR at all. It is a schedule of assets, and the marketplace collects a structured version of that schedule from every seller at listing time.
That field is unused in every one of our 240+ published analyses. Our existing acquisition work slices this dataset by category multiple, by valuation, by age and by multiple band. None of it has ever read the contents of the box.
The source is our sell-side dataset, 656 live listings scraped from acquire.com, which reports $500M+ in closed deal volume, 2,000+ startups sold and 500k+ registered entrepreneurs, and which closes deals through a third-party escrow service. How our sell-side dataset compares to the source marketplaces is covered in this comparison of listing venues. Of those, 638 carry a populated asset schedule, giving 4,717 individual asset selections at an average of about seven per listing.
Every figure below is a share of the 638 listings with a populated schedule, unless a section states otherwise. Cross-cuts use trailing twelve month revenue, trailing profit, asking price, profit multiple, revenue multiple and business type from the same rows. All queries were re-run on September 11, 2026.
| Source | Evidence type | Volume used | Limitation |
|---|---|---|---|
| Sell-side asset schedule | Structured seller declaration at listing time | 638 listings, 4,717 selections | Constrained picklist: only option-vs-option comparison is valid |
| Asking price | Seller-set list price | 651 populated | An ask, never a closing price. No transaction data exists here |
| TTM revenue and profit | Seller-disclosed financials | 656 revenue, margin derived | Self-reported and not audited at listing time |
| Profit and revenue multiple | Derived from ask over earnings | 633 with a profit multiple | Inherits the ask problem: an asked multiple, not a paid one |
| Business type | Seller-selected category | 656, all populated | Self-declared, so a services business may sit under a software label |
| Listing descriptions | Seller long-form copy | 638, median about 900 characters | Marketing copy written to sell, so silence is not proof of absence |
| Capterra complaint corpus | Structured pain points from software reviews | 39,000+ pain points, 190+ naming migration | Coverage stops mid-alphabet, so per-category counts are unsafe |
| Capterra feature gaps | Requested-but-missing capability records | 40,000+ gaps, 520+ naming migration or export | Demand signal from reviewers, not from buyers of businesses |
| G2 insight corpus | Aggregated review sentiment by category | 9,400+ insights, 260+ naming migration or transfer | Category-level summaries, so individual attribution is coarse |
| Upwork demand corpus | Paid freelance job pain points | 1,200+ pain points, 20 naming migration | Small absolute count; budget columns are unpopulated and never cited |
| Stripe Index | AI-scored public company directory | 30,000+ companies with risk signals | Risk signals are model-generated, so treat as a flag not a fact |
| Reddit founder threads | First-person accounts of completed transfers | 4 threads, live-fetched with permalinks | Anecdote. Used for mechanism and language, never for a rate |
| paying_customers | Excluded entirely | 0 used | Mis-parsed churn band, not a customer count. Never cite it |
| monthly_churn and ARPU | Excluded entirely | 0 used | 100% null across every row |
| Reason for selling | Excluded by design | 0 used | Already analysed in state of SaaS acquisitions; not rebuilt here |
The asset schedule is a constrained picklist. Sixteen standard options account for 91.3% of all 4,717 selections. That single fact governs every comparison in this article, and it rules out the most tempting analysis.
It would be easy to write that this market values tangible assets over intellectual property by some large ratio, and meaningless. The menu offers roughly five tangible-flavoured options against roughly five IP-flavoured ones, so any category-level ratio is driven by how the menu was drawn. We hit this exact trap once before, on the growth-lever field, and published the correction in growth levers founders never pulled.
So the rule here is absolute: compare option to option, never category to category. Codebase against customers is a fair comparison. Trademarks against patents is fair. Software assets against legal assets is not, and we do not make it.
The other 8.7% of selections are free text. There are 396 distinct values in total, meaning roughly 380 are one-off strings typed by a single seller. 156 listings, about a quarter of the populated set, carry at least one.
The tail is also split on commas, so a seller who typed Strategic partnerships (AWS, Storyblok) produced two separate entries, one of which is the bare string Storyblok). That parsing artifact inflates the asset count on exactly the listings with the longest free-text answers, which matters for one section below. Read straight, though, the tail is the most interesting part of the field. It contains cloud credits, a government accreditation, marketplace vendor status, a 250-member developer community, a contractor pool, seven laptops and, repeatedly, “30 days of post-sale support”. Almost none of that is assignable property.
State it before the numbers, not after. Every listing in this dataset had revenue worth listing for sale. Nothing here tells you what the median founder hands over, because the median founder never gets to the point of handing anything over. For the denominator see startup failure statistics and why startups fail.
There is a second, subtler bias. This is a listing dataset, so it records what sellers offered, not what buyers received. A tick in the Customers box is a claim made at the top of a negotiation by the party with an incentive to make it. What survives that incentive is the relative ordering between options, because the incentive pushes every option up more or less equally.
The full standard menu, as a share of the 638 populated listings. Each row is how often sellers tick the box, nothing more.
| Asset option | Share of listings | What it actually takes to move |
|---|---|---|
| Website | 79.3% | Hosting account access plus a DNS change |
| Customers | 77.6% | Billing migration, the hardest item on the list |
| Domain | 75.9% | Registrar transfer, with a 60-day lock trap |
| Brand | 72.6% | Nothing formal unless it is also a registered mark |
| Codebase | 61.3% | A repository invite, genuinely the easy part |
| Social media accounts | 60.7% | Credential handover plus a recovery-email change |
| Marketing materials | 57.5% | File transfer, plus ad accounts and pixels |
| Intellectual property | 50.2% | Undefined umbrella term; needs a schedule of its own |
| Copyright | 29.3% | Recorded transfer with the US Copyright Office |
| Mobile application | 27.0% | Platform-mediated app transfer between developer accounts |
| Trade names | 26.8% | Entity-level filings in each jurisdiction |
| Trademarks | 23.5% | Recorded assignment at the trademark office |
| Other | 10.3% | Opens the free-text field |
| Inventory | 8.6% | Physical goods and a warehouse relationship |
| Codebase and IP | 8.6% | Same as codebase, different label. See below |
| Patents | 6.1% | Recorded assignment, jurisdiction by jurisdiction |
The top of the list is the shell of the business rather than the business. Website 79.3%, domain 75.9%, brand 72.6%. These are the three things that are unambiguously transferable and unambiguously worth something, and they are also the three with the least ambiguity about who owns them. If you are picking a name with an exit in mind, our note on choosing a domain name is the upstream version of this problem.
The gap between website at 79.3% and codebase at 61.3% is eighteen points. Something is being sold that has a site and no software. Hold that thought.
Taken at face value, 391 of 638 listings name the codebase and 247 do not. Two in five businesses on a marketplace dominated by software appear to include no software. That reads like a scandal, and it is the number that sent us into the cross-cut. It is also wrong in two separate ways, and both corrections are instructive.
The first correction is embarrassingly mundane. The menu contains a second code option. Alongside Codebase there is Codebase and IP, selected on 8.6% of listings, and only 10 listings tick both.
Count either label and 68.3% of all listings name code, not 61.3%. The effect is much larger where it matters. Among listings that appear to have no codebase but do describe themselves as SaaS startups, 36.1% ticked Codebase and IP instead. Once both labels are counted, 84.4% of SaaS startups name code. The seven-point corpus-wide error is a pure menu artifact, and it is the reason the picklist rule exists. If we had reported 61.3% and stopped, the article would have been built on a labelling quirk.
The second correction took longer. At corpus level, listings that name no code are bigger, not smaller. Their median trailing revenue is about $158,500 against about $105,000 for listings that name code. Their median trailing profit is essentially identical, about $58,000 against $55,000. They simply earn the same profit on half again as much revenue, which is a thinner margin: 54.7% against 65.3%.
And they are priced lower. Median ask about $168,500 against $199,500, a 2.90x profit multiple against 3.60x, and a 1.40x revenue multiple against 2.20x. On the revenue multiple that is a 57% premium for listings that name code. It is a clean, dramatic, quotable result. It is also not about code.
The profile of a code-less listing, higher revenue and thinner margin and a lower multiple, is the profile of a services or retail business, not a penalised software business. And that is exactly what the dataset contains. The listings that never name code are concentrated in content at 11.8%, ecommerce at 19.6% and agencies at 36.2%, and those categories carry lower multiples for reasons that have nothing to do with repositories. We measured the same effect from the other direction in profit multiples by SaaS category.
So we restricted to the 295 listings that describe themselves as SaaS startups and ran it again. The result kills the headline.
| Group | Listings | Median TTM revenue | Median ask | Profit multiple | Revenue multiple |
|---|---|---|---|---|---|
| All listings, code named | 436 | $105,000 | $199,500 | 3.60x | 2.20x |
| All listings, no code named | 202 | $158,500 | $168,500 | 2.90x | 1.40x |
| SaaS startups, code named | 249 | $104,000 | $195,000 | 3.60x | 2.30x |
| SaaS startups, no code named | 46 | $85,000 | $211,100 | 3.90x | 2.40x |
Inside the SaaS category the relationship inverts. Listings with no named code show a slightly higher median profit multiple (3.90x against 3.60x), a slightly higher revenue multiple (2.40x against 2.30x) and a slightly higher ask, on less revenue. The differences are small and the code-less group is only 46 listings, so the honest reading is not that code hurts. It is that naming the codebase has no detectable relationship with price once you compare like with like.
This is the finding. The codebase is not what the buyer pays for; it is the entry ticket that lets a listing be a software listing at all. Within software it is close to universal, so it carries no information. Outside software it is absent because there is no software. The 61.3% figure measures how mixed this marketplace is. Founders who have completed a sale say the same thing in plainer language, like this one on r/microsaas: “The source code was probably the easiest part to transfer.”
Another seller describing the whole handoff on r/microsaas: “I pushed the code into a new GitHub repo owned by the dev working for the buyer. That’s it. Simple and clean.” In the same post the difficult item is infrastructure: “AWS (S3 Buckets and CloudFront): This was the trickiest part.” If you are on the other side of that handoff, our note on inheriting somebody else’s code and on what breaks in fast-built products is the practical follow-up.
One more test, because a flat result deserves a second look. If code were priced, its frequency would rise with the ask. It does not. Across four price bands the share of listings naming code under either label runs 68.3%, 70.4%, 65.7%, 73.7%, with no trend. Intellectual property over the same bands runs 41.3%, 38.0%, 50.9%, 68.0%. That is a 27-point climb.
| Asking-price band | Listings | Customers | Code (either label) | Intellectual property | Trademarks | Patents |
|---|---|---|---|---|---|---|
| Under $50K | 104 | 73.1% | 68.3% | 41.3% | 21.2% | 3.8% |
| $50K to $150K | 179 | 72.6% | 70.4% | 38.0% | 21.2% | 6.7% |
| $150K to $500K | 175 | 80.0% | 65.7% | 50.9% | 21.1% | 3.4% |
| $500K and above | 175 | 82.3% | 73.7% | 68.0% | 30.3% | 9.7% |
Now the other half of the hook. 495 of 638 listings name the customers and 143 do not. Unlike the code figure there is no second label hiding the rest, and the free-text tail contains only a scatter of one-off entries such as “Loyal customer base” and “Historic Clientele List”, nowhere near enough to close a 22-point gap.
Corpus-wide, listings that name customers show a median trailing revenue of about $130,000 against about $79,000, a median ask of about $211,350 against about $140,000, and a 3.50x profit multiple against 3.00x. They are also far more likely to name code: 74.5% against 46.9%, and the underlying question of what a transferred subscriber is worth is the same one covered in customer lifetime value. That last number is the first hint that the two options travel together.
Run the same business-type control that dissolved the code finding, and the customer finding holds. Inside SaaS startups, listings that name customers show a median ask of about $200,000 against about $157,500, and a revenue multiple of 2.40x against 2.10x, on similar revenue ($104,000 against $90,000). And the co-occurrence is stark: 90.1% of customer-naming SaaS listings also name code, against 58.5% of the rest.
Read together, the two results say something specific. The buyer is not paying for the software. The buyer is paying for a revenue relationship that the software happens to service. That is consistent with what the same dataset says about how SaaS businesses get valued and with the retention literature in why SaaS customers churn.
There is a mechanical reason customers are worth naming: they are the only item that can fail to arrive. A repository either copies or it does not. A subscription base can be legally transferred and still evaporate. A commenter on the r/microsaas sale thread put the diligence question right: “curious what their due diligence actually looked at, did they audit the 50 users or just the code?”
The same seller describes what moving those users cost: “Most of those four months went into compliance checks, documents, transferring the Shopify listing and explaining how to operate the product.” And on platform-mediated products the software cannot move on its own at all: “A Shopify app cannot simply be moved by handing someone a repository. Shopify has to transfer the listing between developer accounts, while the domain, DNS, credentials and monitoring move separately.”
The billing relationship is the sharp edge. A founder who sold a product and then built a tool for the problem wrote on r/microsaas: “Stripe does not offer a way to fully transfer a project (customers, products, prices, coupons, and active subscriptions) from one Stripe account to another. You can copy customers and payment methods, but active subscriptions cannot be moved.” The consequence, in the same post: “The result is usually that subscriptions have to be canceled and recreated manually, often resetting billing cycles or forcing customers to re-enter payment details. That’s a direct hit to MRR and trust.”
Stripe’s own data migrations documentation treats an account-to-account move as a formal migration rather than a setting: transferring sensitive card data between Stripe accounts is an assisted, PCI-gated process, and the migrations team can only assist when a request includes both the customer records and the associated payment data. The asset the picklist calls Customers is in practice two assets that have to arrive together. For the revenue-side view see MRR, ARR and TTM revenue explained and how to calculate churn rate.
If code is flat and customers matter, the third pattern in the price-band table is the one nobody expects. Intellectual property climbs from 41.3% of listings under $50K to 68.0% above $500K. Patents go from 3.8% to 9.7%. Trademarks sit flat at about 21% for three bands and then jump to 30.3% in the top band.
Registered IP is the asset that sorts by price, and the most likely explanation is boring: registration costs money and takes years, so it is a marker of a business old enough and funded enough to have bothered. It is a proxy for maturity, not a driver of value. Anyone reading it as a shortcut should read what actually defends a SaaS first.
Only 23.5% of listings name a trademark and 6.1% name a patent, which means for three quarters of these deals there is no registered mark to move. Where there is one, it does not travel with the business by default. The USPTO treats a change of owner as a separate recorded event: an updated registration certificate issues only where a request is filed and evidence exists of a change in ownership by assignment or merger, and dividing a registration where ownership changed for only some goods requires recording an assignment with the Assignment Recordation Branch plus a $100 divisional fee per new registration.
A buyer who ticks the trademark box and never records the assignment owns a business whose registered mark still shows the seller as owner. That is a real defect, and it is the kind of thing the due diligence checklist exists to catch. A commenter on the handoff thread asked precisely this and got no answer: “Have you registered any copyrights or trademarks for your projects? How did you transfer them?”
29.3% of listings name copyright, more than name a trademark. Copyright in the code arises automatically, but the transfer of it is a documented act. The US Copyright Office accepts transfers of copyright ownership for recordation under section 205 of Title 17, and its published queue makes the timing real: paper submissions are currently being processed from March 2025 for basic filings, with the effective date of recordation set to the day the Office receives a complete submission in acceptable form.
None of that is exotic. It simply means two of the twelve standard options on this menu resolve to government filings rather than credentials, and the listing gives you no signal about whether the seller has done them.
The domain is named on 75.9% of listings and is the item most people assume is trivial. It has the sharpest timing trap in the whole schedule. Under the ICANN Transfer Policy, a registrar must impose a 60-day inter-registrar transfer lock following a change of registrant unless the prior registrant was allowed to opt out beforehand. The policy explicitly tells registrars to warn a seller that if the goal is to move the name to a different registrar, the registrar transfer should be requested before the change of registrant.
Do it in the wrong order and the buyer owns a domain they cannot move for two months. The same policy also blocks transfers within 60 days of initial registration, which matters for anyone selling a product launched in a hurry. The general lesson is in how to sell your SaaS: sequencing is part of the asset.
The mobile application is named on 27.0% of listings overall, which looks low until you notice that most listings are not mobile businesses. Inside the Mobile startup category it is named on 94.2%. It is also the one asset that a platform, not the parties, actually moves. One seller in our dataset writes it into the listing directly: “The sale includes the full codebase and an App Store Connect app transfer, enabling immediate continuity for a new owner.”
If you are building in this category, the complaint side of it is mapped in the state of mobile app pain points and the App Store database.
Social accounts at 60.7% and marketing materials at 57.5% sit in the middle of the menu and behave like the website: widely included, rarely contested, individually low-value. The free-text tail is where these get specific, with entries naming a Meta pixel, a Meta ad account, a TikTok following, a 55K-follower Facebook page and an ad-creative library. Inventory appears on 8.6% overall but 30.4% of ecommerce listings, which is the cleanest single confirmation that the menu is being used sensibly rather than at random.
Business type explains more of this field than price does. Here is the full breakdown for every category with at least 17 listings.
| Business type | Listings | Customers | Code | Domain | Brand | IP | Mobile app | Inventory |
|---|---|---|---|---|---|---|---|---|
| SaaS startup | 295 | 82.0% | 86.8% | 83.4% | 77.3% | 57.6% | 19.7% | 6.4% |
| Mobile startup | 86 | 54.7% | 72.1% | 50.0% | 44.2% | 33.7% | 94.2% | 3.5% |
| Agency startup | 69 | 87.0% | 36.2% | 75.4% | 79.7% | 44.9% | 7.2% | 4.3% |
| Ecommerce startup | 56 | 67.9% | 19.6% | 87.5% | 83.9% | 35.7% | 3.6% | 30.4% |
| Shopify App startup | 29 | 86.2% | 96.6% | 55.2% | 48.3% | 44.8% | 13.8% | 6.9% |
| AI startup | 28 | 82.1% | 89.3% | 75.0% | 85.7% | 71.4% | 25.0% | 7.1% |
| Marketplace startup | 18 | 88.9% | 94.4% | 83.3% | 83.3% | 44.4% | 33.3% | 16.7% |
| Digital startup | 18 | 72.2% | 50.0% | 83.3% | 77.8% | 61.1% | 11.1% | 11.1% |
| Other startup | 18 | 83.3% | 44.4% | 72.2% | 66.7% | 38.9% | 27.8% | 16.7% |
| Content startup | 17 | 70.6% | 11.8% | 70.6% | 70.6% | 47.1% | 11.8% | 5.9% |
The largest category, 295 listings, and the most complete schedules: 86.8% code, 83.4% domain, 82.0% customers, 77.3% brand, 57.6% IP. Median margin 68.6%. This is the reference shape, and it is worth comparing against SaaS metrics benchmarks and revenue benchmarks by category before you decide your own listing looks normal.
Agencies invert the software shape completely: 87.0% name customers, the highest of any large category, and only 36.2% name code. Median margin 49.5%. There is no ambiguity about what is being sold. One agency listing in the dataset spells out what the customer asset actually consists of: “Smooth handover; leadership available for ongoing full-time or fractional support.” Another puts it as “Seamless Transition: We will introduce you to everyone we work with.” The asset is introductions, which is the defining property of every service business model.
Ecommerce lists the domain most often of any category at 87.5%, code least often but for inventory at 19.6%, and carries the thinnest margin at 24.8%. Content is the extreme case: 11.8% code, 80.4% median margin, and one listing in the tail describing its asset as530+ published articles. Content businesses are the clearest demonstration that a high margin and a low multiple can live in the same row, which is the same pattern we found by age in the growth-timeline analysis.
Shopify app startups name code on 96.6% of listings, the highest figure in the dataset, and post the highest median margin at 85.4%. They also name the domain least of the software categories at 55.2%, because the storefront listing is the distribution. AI startups are the IP outlier at 71.4%, well above SaaS at 57.6%, which fits a category where the differentiator is claimed to be a model or a pipeline rather than a feature set. For who is actually shipping in that category, see the state of AI tools and the AI SaaS revenue reality check.
The most distinctive row in the table. Mobile startups name the mobile application on 94.2% of listings but the domain on only 50.0%, the brand on 44.2% and the customers on 54.7%, the lowest customer figure of any category by 13 points.
That is not sellers being careless. It is an accurate description of a business model where the app store owns the billing relationship, the discovery surface and the user identity. The seller never held the customer, so there is no customer to transfer. What transfers is a listing and a review history. Anyone weighing a mobile build should price that in alongside the category opportunity map.
Split by team size and a consistent gap appears. Sellers who describe the team as Just me (191 listings) name code on 63.9%, customers on 70.2% and IP on 43.5%, averaging 7.0 assets. Teams of 2 to 20 (437 listings) name code on 70.3%, customers on 80.3% and IP on 53.1%, averaging 7.5 assets.
The gap is roughly six to ten points on every option, which is more consistent with solo sellers having fewer formalised assets than with them being less thorough. A solo founder often has no registered mark, no separate marketing library and no entity to assign. That is the same constraint that shows up in solo developer revenue examples and in the untapped growth levers data.
Up to a point, and then it stops. Median ask rises from about $109,000 for listings naming one to three assets, to $167,000 at four to six, $195,000 at seven to nine, and $340,500 at ten to twelve. Then it falls to $254,500 for lists of thirteen or more, where the revenue multiple also drops to its lowest value of 1.50x.
Treat that last band with suspicion. Thirteen-plus is exactly where the comma-splitting artifact concentrates, so some of those listings are not richer, just more verbose. The safe reading is the first four bands: a fuller schedule tracks a bigger business, and there is no evidence that padding the list helps.
The menu has no option for the thing every buyer needs. Listing descriptions run to about 900 characters at the median, and 575 of the 656 run past 500 characters, so there is room to say it. 28 of 638 mention a handover at all. 22 mention documentation. 11 mention transition support. 7 mention full source code. 33 mention training or a walkthrough. 42 use the word turnkey.
Against that, 97 descriptions reference a no-code or hosted platform such as WordPress, Shopify, Bubble, Webflow, Airtable or Zapier, and 33 describe the product as white label. On those products the transferable asset is an account, not a repository, which is its own risk class. We wrote about the dependency version of that problem in micro SaaS without an API dependency, and the Stripe Index flags the same thing at scale: of 30,000+ scored companies, 1,100+ carry a platform-dependency risk signal and 1,500+ carry a key-person or founder-dependency signal.
The sharpest line in this research came from a commenter on the r/microsaas sale thread: “the handover is the part nobody prices. buyer paid for working software but what they really needed was everything in your head, the env vars, the deploy steps, the ‘if x stops working check y’ list, and you basically donated that.”
Another commenter costed it: “The March to July gap is basically four months of free consulting, so next time I’d set a firm handover fee or a deadline clause before even signing anything.” The seller’s own list of what he would prepare next time is the asset schedule this picklist does not have: “A complete asset list, a basic architecture map, a list of accounts that can be transferred, a plan for rotating production secrets, deployment and rollback instructions, transfer requirements for every platform involved, written boundaries for handover support.”
A few sellers do write it into the listing. One describes “detailed handover documentation and video walkthroughs of all core systems”. Another offers “a real handover, platform walkthroughs, customer intros where it makes sense, vendor and infrastructure context, and ongoing availability”. Those are the exceptions. The common phrasing is compressed: “Lean operations, no employees; easy handover”, “Bootstrapped, low overhead, easy handover”, “US-based; easy handover and seller support”, “lean team; low overhead and smooth handover”, “clean exit with seller support for a smooth handover”. Easy is doing a great deal of work there.
A second corpus speaks to this: people on the receiving end of a product changing hands. Across 39,000+ structured Capterra pain points, 190+ name migration; across 40,000+ feature gaps, 520+ name migration, import or export; across 9,400+ G2 category insights, 260+ do. Those are software migrations rather than business sales, but the failure modes are identical because the operation is.
The texture: “Migration not reliable. Prices are wrong, missing photos, URLs. We had a very long and problematic migration attempt.” (Capterra review.) “Did not migrate assets like images, CSS, fonts, custom code, etc.” (Capterra review.) “Data missing mysteriously.” (Capterra review.) “Reminders cannot easily be migrated between users.” (Capterra review.) “Interoperability between workspaces could be improved.” (Capterra review.)
The licensing edge cases are worse. “License is restrictive, loses features after expiry and locks you to one domain without transfer option.” (Capterra review.) “Once you purchase this software you receive a few months of support, and if you have to reinstall on a new computer or have any issues you are on your own unless you want to pay.” (Capterra review.) “Be very careful! Our transfer paperwork concealed a 1-year auto-renewal.” (Capterra review.) “Migrating from an entirely manual process into a fully operational online platform was never going to be an easy task.” (Capterra review.)
The G2 summaries say the same at category level: “Users frequently face challenges with migration failures, slow performance, confusing interfaces, and lack of real-time support.” (G2 insight.) “Poor data export features.” (G2 insight.) “Limitations in desk booking flexibility, data export options, reporting functionality.” (G2 insight.) “Analytics, reporting and data export that fall short.” (G2 insight.) If you want to mine that corpus yourself, start with mining Capterra reviews and turning G2 reviews into ideas.
The final leg of evidence: across 1,200+ Upwork job pain points, 20 are migration work, and they price the operation the listing describes as easy. “Businesses frequently face difficulties when migrating emails between platforms, which can lead to data loss, downtime, and user frustration.” (Upwork pain point.) “Companies frequently encounter difficulties when migrating financial data between different accounting platforms or integrating various financial systems.” (Upwork pain point.)
“Many businesses face challenges when migrating databases, which can lead to data integrity issues and downtime. Manual migration is often time-consuming and error-prone, requiring specialized knowledge.” (Upwork pain point.) “Many businesses struggle with creating and maintaining accurate process maps and documentation, which can be time-consuming and prone to errors when done manually.” (Upwork pain point.) The Upwork budget columns are unpopulated, so we cite frequency and never a dollar figure. The broader read on that corpus is in validating demand with Upwork jobs and the state of freelance demand.
The practical conclusion is unglamorous. The picklist is a marketing field with sixteen boxes; the document that closes a deal is longer. Write it before a buyer appears: every account that changes hands, every credential that rotates, the deploy and rollback path, each platform’s transfer requirement, and a written boundary on post-sale help.
A cautionary case for why account control is not the same as ownership, from a co-founder dispute on r/indiehackers: “The domain was under his name. He already had the GitHub code. He had access to all my Supabase projects, where the backend was hosted. The payment gateway was also already under his control.” The equity version of that problem is covered in the cofounder equity and vesting guide.
Sequencing matters as much as content. A seller on r/microsaas describes the safe order: “The money was in an Escrow.com account while I transferred the domain. Once the checks are done, the money will be released.” A commenter on the other handoff thread asked the question every first-time seller should ask: “Did you create a contract of sale and receive funds before you handed over the keys?”
Read the asset schedule as claims to verify, not things you will receive. Four questions follow from the data above. Which code label did they tick, and is there a repository behind it or a hosted account. Are the customers on a processor that supports an account-to-account migration, or will every subscription be cancelled and rebuilt. Has the change of registrant been sequenced so the domain is not locked for 60 days. And if the listing names trademarks or copyright, has anything been recorded, or is the seller still the owner of record.
Then price the handover explicitly, because the evidence says nobody else will. Our due diligence checklist, target-finding guide and buy-versus-build analysis cover the rest of the process, and the due diligence workflow shows how to run it against the live data, and the SaaS sellers report tracks what is newly listed.
Read the asset schedules yourself. BigIdeasDB indexes live acquisition listings alongside revenue benchmarks, the Stripe Index of 30,000+ companies and a 1M+ complaint corpus, so you can filter by category, compare what sellers include and check whether a market is worth entering at all.
Open the sell-side database →Who you sell to shapes what you end up owning. See who micro SaaS actually sells to for the segment data, and how small your MVP should actually be for the scope decision that precedes both.
Three caveats, stated rather than buried. First, this is one marketplace, weighted toward smaller bootstrapped deals; nothing here describes how a venture-backed company is acquired. Second, the schedule is optional in practice: 18 of 656 listings have none and are excluded throughout, and their absence is not random.
Third, the supporting corpora have their own coverage holes. Our Capterra company coverage stops mid-alphabet, so a thin per-category migration count is ambiguous between few complaints and few companies scraped. We therefore cite only corpus-level migration counts, never a per-category rate; the per-category workflow is documented in the Capterra analysis guide. The Upwork migration count of 20 is small in absolute terms and is used as texture, not as a market size.
The asking price is an ask. No closing prices exist here, so every price and multiple is what a seller wanted and the ask-to-close gap is invisible. Financials are self-reported and unaudited at listing time. Business type is self-declared, so a services business can sit under a software label and distort a category row.
Three columns were excluded outright and the exclusions are published above. paying_customers is not a customer count at all, it is the leading integer of a churn band string, and citing it as a count is a mistake we have made before and now guard against. monthly_churn and ARPU are 100% null. The reason for selling field is deliberately untouched here because it is already analysed in the state of SaaS acquisitions.
Finally, the design. Every comparison is option against option, because category-level ratios would measure the menu. Correlation is not causation: listings that name customers ask more, but the plausible explanation is that businesses with transferable customers are better businesses, not that ticking a box raises a price. And it is survivorship throughout. For how we approach this class of question generally, see how founders research markets.
On 630+ live listings: website 79.3%, customers 77.6%, domain 75.9%, brand 72.6%, codebase 61.3%, social accounts 60.7%, marketing materials 57.5%, intellectual property 50.2%, copyright 29.3%, mobile application 27.0%, trade names 26.8%, trademarks 23.5%. These are picklist options, so each figure is how often a seller ticks the box.
No. 61.3% tick Codebase, and a second option called Codebase and IP adds 8.6%. Counting either, 68.3% of listings name code, rising to 84.4% among SaaS startups. The rest is mostly non-software businesses in the same dataset.
At corpus level they look cheaper per dollar of revenue, 1.40x against 2.20x. Hold business type constant and that reverses: inside SaaS startups the profit multiple is 3.90x without code and 3.60x with. The corpus gap was composition.
Partly because not every listed business has a transferable customer relationship. Mobile startups name customers least often at 54.7%, which fits a model where the app store holds the billing relationship rather than the seller.
It correlates with a higher ask and, unlike the codebase, survives a business-type control. Inside SaaS startups the median ask is about $200,000 with customers named against about $157,500 without. Asks, not closes.
Active subscriptions. Payment processors treat a change of owner as a data migration, and sensitive card data moves through an assisted, compliance-gated process. Sellers describe the source code as the easy part.
No. ICANN transfer policy imposes a 60-day inter-registrar transfer lock after a change of registrant unless the prior registrant opted out first, so the wrong order freezes the name for two months.
Not by default. A trademark change of ownership is recorded as an assignment with the USPTO, and transfers of copyright ownership are recorded separately with the US Copyright Office under section 205. Only 23.5% of listings name trademarks and 29.3% name copyright.
Up to a point. Median ask climbs from about $109,000 at one to three assets to about $340,500 at ten to twelve, then falls back for the longest lists, which are also the most contaminated by free text.
Content at 11.8% and ecommerce at 19.6%, with agencies at 36.2%. At the other end, Shopify app startups reach 96.6% and AI startups 89.3%.
Because most listings are not mobile businesses. Inside the Mobile startup category it is 94.2%, while the domain is 50.0% and customers 54.7%.
The free-text tail includes cloud credits, partner statuses, marketplace vendor accreditation, a developer community, a contractor pool and post-sale support windows. Those are promises and relationships, not assignable property.
Operational knowledge. 28 of 638 descriptions mention a handover, 22 mention documentation and 11 mention transition support, in text that runs about 900 characters at the median.
No. Every listing had revenue worth listing, so it is survivors only. It also records what sellers offered rather than what buyers received, and skews toward smaller bootstrapped deals on one marketplace.
No, and we did not. The field is a constrained picklist, so a category-level ratio measures how many options the menu offers in each category. Every comparison here is option against option.
Write it before a buyer appears: every account that changes hands, every credential that rotates, the deploy and rollback path, each platform’s transfer requirement, and a written boundary on post-sale support. Sellers who have done it say the checklist is the asset. See how to sell your SaaS for the wider process.
BigIdeasDB indexes live acquisition listings alongside revenue benchmarks, the Stripe Index and the complaint corpus. Start at the sell-side database or discover. Further reading: the state of SaaS acquisitions, SaaS valuation multiples, the state of SaaS valuations, how long it takes to grow a SaaS, how fast SaaS startups grow, what micro SaaS actually charges, how small an MVP should be, micro SaaS examples, the best micro SaaS ideas, the micro SaaS competition map, SaaS market saturation, industries still running on spreadsheets, the state of indie SaaS revenue, the first $1k MRR, SaaS pricing strategies, how to price a micro SaaS, getting your first 100 users, customer discovery questions, how to validate a startup idea, how to find startup ideas, bootstrapping in 2026, getting started with the sell-side database, using sell-side data as validation, finding execution gaps in listings, reading the AI buyer thesis, how to value a SaaS business, finding acquisition opportunities, the sell-side MCP tools, getting started with TrustMRR, and the pain point database.
BigIdeasDB Research. (2026). What Transfers When You Sell a SaaS (630+ Listings). BigIdeasDB. Retrieved from https://bigideasdb.com/what-transfers-when-you-sell-a-saas