How to sell an online tool or web app

A complete step-by-step guide to exiting your online tool, web app, or browser extension — from auditing product metrics and preparing your technical documentation to calculating your valuation, listing for free, and completing the codebase and infrastructure transfer. Ready to list? List your tool free on Buy Sites Direct — no broker fees, no commissions, keep 100% of your sale price.

1. 1

   Audit your product metrics and revenue

   Before listing, gather and verify every metric a serious buyer will request. For tools and web apps, the core data points are: (1) Monthly Recurring Revenue (MRR) — the subscription-based revenue from active monthly and annual subscribers. Break this down into monthly plan MRR and annual plan MRR separately; buyers want to know the annual plan rate (the percentage of subscribers paying annually vs monthly). A high annual plan rate (above 40%) signals lower near-term churn risk and commands a premium. (2) Lifetime deal (LTD) user count vs subscription user count — if you sold lifetime deals via AppSumo, StackSocial, or PitchGround, these users generate no recurring revenue and suppresses your ARPU. Buyers will want to know exactly how many LTD users exist, what support obligations they carry, and whether they are excluded from future pricing changes. (3) Monthly churn rate — for subscription tools, the percentage of paying users who cancel each month. Under 2% is strong; 2–4% is typical; above 5% is a red flag requiring explanation. (4) Monthly active users (MAU) and activation rate — what percentage of sign-ups successfully complete the core action the tool was built for? High activation relative to MAU indicates strong product-market fit. (5) Monthly traffic and acquisition channels — where do new users come from? Organic search, product-led virality, paid ads, marketplace listings (Shopify App Store, Chrome Web Store), or direct word of mouth. Channel diversification signals sustainability. Export 24 months of data from your payment processor (Stripe, Paddle, Lemon Squeezy) and your analytics platform before approaching buyers.

2. 2

   Calculate your SDE and realistic valuation

   Online tools and web apps are valued as a multiple of monthly Seller's Discretionary Earnings (SDE) — net profit plus the owner's salary, non-recurring expenses, and personal expenses run through the business. Use a trailing 12-month average to smooth seasonal variation. Key add-backs for tool businesses include: hosting and infrastructure costs that would transfer (if paid personally), one-time software or equipment purchases, any personal expenses charged to the business, and the owner's salary or draws. Tools with strong subscription MRR and low churn typically sell at 30–50x monthly SDE. Tools with significant lifetime deal revenue, one-time payment income, or above-average churn trade lower — typically 24–36x monthly SDE. The four most important multiple drivers for tools and apps: (1) MRR growth trend — rising MRR over the past 12 months commands a significant premium; flat or declining suppresses multiples sharply; (2) annual plan rate — a higher proportion of annual subscribers reduces churn risk and increases the buyer's confidence in near-term revenue stability; (3) LTD user percentage — tools with 30%+ of their user base on LTD plans trade at a discount because future monetisation of that cohort is blocked; (4) platform dependency — tools heavily dependent on a single API (OpenAI, Google, Stripe) or a third-party marketplace (Chrome Web Store, Shopify App Store) for distribution may trade at a discount due to platform risk. Set your asking price at the high end of the realistic range — buyers will negotiate down, and an evidence-backed ask protects your position.

3. 3

   Prepare your technical documentation package

   Technical documentation is the single most important difference between a tool sale and a content site sale. Buyers — including non-technical operators who plan to hire a developer — need to understand the codebase and infrastructure before making an offer. Prepare: (1) Tech stack overview — a plain-English summary of the languages, frameworks, databases, and hosting infrastructure the tool runs on. Include version numbers for any dependencies that could be end-of-life or unsupported; (2) Infrastructure diagram — a simple visual or written description of the hosting setup (VPS vs managed hosting, cloud provider, CDN, load balancers, databases). Note any services with per-unit pricing that scales with usage; (3) Third-party API and integration list — every external service the tool depends on (authentication, payment processing, email delivery, AI/ML, analytics), the cost of each, and the risk if that service changes pricing or terms; (4) Deployment and release process — how code goes from development to production. Is this manual or automated (CI/CD pipeline)? What does a deployment involve? (5) Known technical debt — any areas of the code that are fragile, poorly documented, or likely to require refactoring. Disclosing these upfront builds trust; buyers will find them during due diligence regardless; (6) Open-source licenses — if the codebase uses any GPL-licensed components, note this, as it may create obligations for the buyer. Prepare this documentation before listing and share it (under NDA) as part of the due diligence process. Clean technical documentation reduces time-to-close and attracts a broader pool of buyers including non-technical operators.

4. 4

   Reduce owner-operator dependency before listing

   For tools and apps, owner dependency typically manifests in two ways: technical dependency (you are the only person who can maintain, debug, or deploy the code) and customer relationship dependency (key accounts, enterprise clients, or power users have personal relationships with you that may not transfer to a new owner). Address both before listing. For technical dependency: document all SOPs for routine maintenance tasks (server updates, database backups, incident response), write a README with setup instructions assuming the new owner has no prior context, and consider spending 2–4 weeks making targeted improvements to the codebase documentation and code comments so a competent developer can understand the system without your guidance. If the tool runs on legacy or unusual technology, provide an architectural overview that makes it accessible. For customer relationship dependency: for any customers who have direct email relationships with you (especially enterprise accounts), gradually shift those communications to a support@yourdomain.com address rather than your personal email. For tools with active communities or user forums, begin reducing your visible role 2–3 months before listing. The more a buyer can verify that the tool operates independently of you, the higher the multiple they will justify.

5. 5

   List your tool for free on Buy Sites Direct

   Create a free account, go to your seller dashboard, and publish your listing under the Online Tools & Apps category. Buy Sites Direct charges no listing fee and takes no commission when the deal closes — the full sale price stays between you and the buyer. Write a listing that leads with the most important metrics: MRR (monthly), monthly churn rate, annual plan rate, LTD user count (if any), monthly active users, primary traffic/acquisition channels, and asking price with the multiple it represents. Include a clear description of the tech stack so buyers can self-qualify based on their technical background. Be accurate about the LTD situation — buyers will discover this in due diligence, and a listing that obscures LTD users loses credibility and wastes everyone's time. Attach screenshots of your payment processor dashboard (Stripe, Paddle), your analytics platform showing MAU and activation data, and your MRR trend over the past 12 months. A listing with verified revenue screenshots and a tech stack description attracts technical buyers and reduces time spent on initial screening calls.

6. 6

   Screen buyer inquiries for technical and operational fit

   Online tools attract two distinct buyer types: technical buyers (developers or technical operators who will manage the codebase themselves) and non-technical buyers (operators who plan to hire a developer). Both are legitimate, but require different due diligence support from you. For technical buyers, expect detailed code review requests, architecture questions, and infrastructure audits under NDA. For non-technical buyers, expect more questions about the operational workflow, support volume, and whether a part-time developer engagement can cover ongoing maintenance. Screen buyers by asking: (1) Have they acquired a SaaS or tool before? Prior experience significantly reduces friction; (2) What is their plan for the technical side — do they code, or do they have a developer relationship? (3) What specifically attracted them to this tool — understanding the niche and the product matters; (4) Do they have funds ready or are they still in the discovery phase? Beyond fit, assess whether the buyer is capable of maintaining the tool at the same quality level — a buyer who cannot handle technical operations risks damaging the product and leaving existing users unsupported. Request a signed NDA before sharing code, detailed infrastructure information, or user data.

7. 7

   Share due diligence materials

   Once a serious buyer is engaged and an NDA is signed, provide a structured due diligence data room containing: (1) 24 months of monthly P&L statements, clearly separating subscription MRR from one-time revenue, LTD revenue, and any other income streams; (2) Payment processor exports (Stripe, Paddle, or Lemon Squeezy) for the trailing 24 months, verifying every revenue line on the P&L; (3) Analytics exports showing MAU, activation rate, new sign-ups, and churn counts for the trailing 12+ months; (4) MRR breakdown by plan type (monthly vs annual) and LTD user count with support ticket volume from that cohort; (5) Tech stack documentation package (as prepared in step 3); (6) Codebase access — typically a private Git repository invite for code review, or a read-only clone. Serious buyers will want to review the code before making an offer; (7) Infrastructure access overview — a description of all hosting accounts, databases, and third-party API accounts, with an access inventory the buyer can use to plan the transfer; (8) Customer support volume — average monthly ticket count, common issue types, and current resolution time; and (9) Any existing customer contracts, SLAs, or enterprise agreements that would transfer with the sale. Anticipate detailed questions about the 10–15 largest-by-revenue accounts and whether those relationships are personal or product-driven.

8. 8

   Negotiate, close, and complete the technical transfer

   Once a buyer makes an offer, agree on the full asset list, transition period, and payment structure before drafting an Asset Purchase Agreement. Tool sales under $50,000 are typically all-cash with a 30–60 day escrow holdback (10–15% of purchase price), released after the buyer confirms the tool is operational and subscription revenue has held within agreed thresholds. Larger deals may involve seller financing: typically 70% at closing, 30% paid over 6–12 months. The transition period for tools is typically 30–60 days — shorter than communities but longer than most content sites — because the technical handover requires coordination between seller and buyer (or their developer). The practical transfer involves six tracks: (1) Codebase transfer — the seller transfers the Git repository and all relevant branches to a buyer-controlled account; (2) Hosting and infrastructure transfer — server access, cloud provider accounts (AWS, GCP, DigitalOcean), database credentials, and CDN configuration; (3) API keys and third-party service accounts — every integrated service needs account access transferred or new API keys generated with the old ones revoked; (4) Domain and DNS transfer — registrar account transfer and DNS record handover, with a plan for the propagation window; (5) Payment processor transfer — for Stripe, discuss whether to transfer the entire Stripe account (including subscription history) or migrate subscriptions to a new account. Stripe account transfers are the cleaner option for buyers but require careful coordination; (6) App store or marketplace accounts — for browser extensions (Chrome Web Store), WordPress plugin repository accounts, or Shopify App Store accounts, follow the respective platform's official developer account transfer process, which may require direct support escalation. Budget 2–4 weeks for the full technical handover and involve the buyer in each step rather than handing over all credentials at once.