Source confidence: medium

Buying Dead Apps — the one-person AI-native rollup

Insight class: Arbitrage Opportunity · Difficulty: Hard · Quality: 4/5 Connected entries: 11 · Tools: Anthropic, ChatGPT, Claude, Claude Code, Codex, DeepWiki, GitDiagram, GitMCP, Gitingest, PostHog, Reverse Engineer Anything, VS Code, cron

In short: Bending Spoons went from $40k to an $18B IPO by buying stagnant software, rebuilding only what customers use, and compounding the margin. Public SaaS multiples just got cut in half.

Key fact Detail
What it covers software development, agents, open source, prompt engineering
Tools Claude Code, Claude, Anthropic, ChatGPT, Codex
Posts covered 11 posts (1 S-tier, 5 A-tier) · top: GitHub URL swaps — gitdiagram, gitingest… · Reverse Engineer Anything — trending repo that… · Fable orchestrates, Opus executes — cutting…
Creators @angus.sewell, @ariacodez, @atlasberry008
Sources dated Apr 2026 – Oct 2026
Difficulty Hard
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

Thesis

Bending Spoons went from $40k to an $18B IPO by buying stagnant software, rebuilding only what customers use, and compounding the margin. Public SaaS multiples just got cut in half. Meanwhile the catalog holds the full toolchain for agent-driven rebuilds — repo comprehension, reverse engineering, orchestrator/executor loops with earned autonomy, and checklists for the legal and performance gaps vibe-coded apps leave. Scale the playbook down: small cash-flowing apps sell for a few times annual profit, and the rebuild cost is the variable AI just crushed.


Why it matters

Building new means a cold start on distribution. Buying old means you inherit customers and search rank, and the agent stack turns the costly part — understanding and modernizing someone else's code — into days instead of months.


The evidence — connected entries

Bending Spoons playbook — AI-native acquisitions of stagnant SaaS

Creator: @tom__shipley · Tier: B

The playbook — buy stagnant, rebuild the used core lean, margin is the strategy

Bending Spoons grew from $40k to an $18B IPO by buying stagnating platforms (Evernote, Vimeo, Meetup, WeTransfer) cheaply, rebuilding only the core features customers use with a lean elite engineering team, cutting cost base and compounding margin into the next deal. Argues AI-native acquirers, not vendors, are the new playbook PE/VC is funding.

View original post

Public SaaS is getting destroyed. Atlassian -63%. HubSpot -48%. Workday ...

Creator: @atlasberry008 · Tier: B Tools: Anthropic

SaaS multiples collapsing — sellers' prices are falling

Public SaaS is getting destroyed. Atlassian -63%. HubSpot -48%. Workday -47%. — @atlasberry008; uses Anthropic.

View original post

Claude — Stop selling software. Sell the finished work.

Creator: @tpadumke · Tier: A Tools: Claude

YC's AI-native service companies — sell finished outcomes on top of what you acquire

YC’s #2 request for startups: AI-Native Service Companies. — @Edited; uses Claude; demonstrates MCP.

View original post

GitHub URL swaps — gitdiagram, gitingest, deepwiki and gitmcp for any repo

Creator: @ariacodez · Tier: S Tools: DeepWiki, GitDiagram, GitMCP, Gitingest, VS Code

gitingest, deepwiki and gitmcp — read an unfamiliar codebase in an hour during diligence

Swap github.com in a repo URL for gitdiagram.com to get an architecture diagram, gitingest.com for an LLM-readable dump, deepwiki.com for generated docs, or gitmcp.io to let your agent query the repo live over MCP. Pressing the period key on a GitHub repo opens it in browser VS Code.

View original post

Creator: @theericmichaud · Tier: A Tools: Claude Code, Codex, Reverse Engineer Anything

Reverse Engineer Anything — recover how a feature works when the docs are gone

The week's top trending GitHub repo, about 70k stars: point Claude Code or Codex at an app and it explains how the feature is built so you can rebuild it. Users have revived old hardware, e.g. a Logitech keypad on Linux in 15 minutes, plus scanners and sound cards that lost drivers.

View original post

Fable orchestrates, Opus executes — cutting frontier-model token spend

Creator: @thomas.lentine · Tier: A Tools: Claude Code

Fable plans, Opus executes — top-model judgment on the rebuild without burning budget

Brain-dump your task list to Fable, have it write specs and spawn cheaper Opus subagents (in parallel worktrees) to execute, then Fable reviews and sends fixes back in a loop until it's good enough. You get top-model judgment without burning usage limits on implementation.

View original post

Agentic OS on Claude Fable 5 — cron loop with earned autonomy

Creator: @raycfu · Tier: A Tools: Claude Code, cron

Cron loop with earned autonomy and daily regression tests — keeps an acquired app alive unattended

Blueprint: a cron-run loop.sh where a cheap model triages changes, Fable 5 plans as manager, Sonnet executes and a fresh Fable reviews. Tasks earn autonomy after 20 passes at 95% and lose it below 90%, refusals come back as HTTP 200 so scripts must check stop_reason, and a goals directory reruns regression tests daily.

View original post

Creator: @murphmaxxing · Tier: B Tools: ChatGPT, Claude

Ten compliance gaps that get indie apps sued — the legal diligence checklist

Ten liability traps for indie apps with rough per-user fines: missing or incomplete privacy policy (data collection, AI use, third parties), undeleted uploads, public storage buckets, fake testimonials, hard-to-cancel subscriptions, silent trial auto-charges, and chatbots without self-harm handling.

View original post

Vibe-coded app performance — five fixes Claude usually skips

Creator: @haydenschmitty · Tier: A Tools: Claude, Claude Code

Five performance gaps in AI-written code — the post-rebuild hardening checklist

Five backend/frontend performance gaps in AI-written apps: uncompressed JSON responses, row-by-row database inserts, a single dependency bottleneck in round-trip latency, no optimistic UI updates, and server re-rendering HTML for every visitor instead of caching.

View original post

PostHog interest-segmented landing pages — personalize by visitor behavior

Creator: @angus.sewell · Tier: C Tools: PostHog

PostHog behavior clustering — find which features customers actually use before you cut

Sponsored PostHog post: install PostHog, let two weeks of visitor sessions accumulate, then prompt an AI to cluster visitors into interest groups (e.g. sales vs. support features) and generate a landing-page variant per group that returning visitors see. Also argues flashy animated landing templates convert poorly.

View original post

DIY fractional CFO — finance API sync plus AI analysis skills

Creator: @angus.sewell · Tier: C

Agent-run finance tables — verify the seller's unit economics yourself

Sync transactions from a finance API into your own tables, then run agent prompts that categorize income and expenses, flag waste and spot under-investment, refining each into a reusable skill. Pitched as a replacement for a $15k fractional CFO.

View original post


Action sketch — how to implement this

Scrape listings on micro-acquisition marketplaces (Acquire.com, Flippa) under $50k and have Claude score each on revenue stability, stack age, and how much of the code you could replace. For the top three, request repo access under NDA, run gitingest plus deepwiki, and have an orchestrator agent produce a rebuild spec, a cost estimate in hours and the compliance gap list. Buy one, ship PostHog first, then rebuild only the top-used flows with an orchestrator/executor loop and daily regression tests, and track churn monthly. falsifier: if the rebuild plus migration costs more than six months of the app's profit, or churn after migration goes above 10%, the AI discount isn't real at this size.


Prerequisites


Key tools and resources

Creators to follow



Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Produces an underwriting pipeline for buying one small cash-flowing app under 50K USD and rebuilding it with an agent stack: a scored listing table from Acquire.com and Flippa, verified financials, a repo-comprehension pack (Gitingest, DeepWiki, GitDiagram, GitMCP), a rebuild spec with an hour estimate, a compliance and performance gap list, and a 90-day post-close plan with churn tracking. Done means the buyer can say, with evidence, whether rebuild plus migration costs less than six months of verified profit. No money is wired until a paper underwriting of three deals and an independent verification of revenue both pass.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

Act as a micro-acquisition analyst and technical due-diligence lead. I want to buy one software app under 50K USD and rebuild it with coding agents, Bending Spoons style. Do not contact sellers or move money; produce analysis only. First, scrape current Acquire.com and Flippa listings under 50K USD (respect each site's terms; if scraping is disallowed, use exports or manual copy). For each, record asking price, claimed trailing-12-month revenue and profit, multiple, age, stack, traffic source, platform dependency and churn if stated, then score revenue stability, stack age and replaceable share of code. Shortlist three. For each, write the diligence request list: read-only Stripe or App Store Connect access, 24 months of bank statements, Search Console, repo access under NDA. Specify the repo-comprehension pass with Gitingest, DeepWiki, GitDiagram and GitMCP, plus scc, gitleaks, osv-scanner and scancode. Draft a rebuild spec covering only flows PostHog shows customers use, with an hour estimate and the compliance gap list: privacy policy disclosure of data, AI use and third parties, deletion of uploads, private storage buckets, easy cancellation, trial-end reminders. Compute payback: rebuild plus migration hours times my hourly cost against six months of verified profit. Flag any deal where that ratio exceeds 1 or where verified revenue differs from the listing by more than 10%.

2 · One-shot prompt

ROLE AND STANCE
You are a micro-acquisition analyst and technical diligence lead for a solo buyer who wants to apply the Bending Spoons playbook at small scale: buy a stagnant cash-flowing app, rebuild only the flows customers use with coding agents, expand margin. Treat the source posts as hypotheses. Claims to test: Bending Spoons grew from 40K USD to an 18B USD IPO this way; public SaaS multiples roughly halved; AI makes rebuilding cheap; a cron-driven orchestrator/executor loop with earned autonomy can run unattended; vibe-coded apps carry ten legal traps (one creator quotes 2,500 to 8,000 USD per user for privacy-policy gaps) and five performance gaps.

CONTEXT
- Deal sources: Acquire.com, Flippa. Structure: asset purchase agreement, escrow, IP assignment, transition support, non-compete.
- Repo comprehension: swap github.com in a URL for gitingest.com, deepwiki.com, gitdiagram.com, or gitmcp.io; press '.' on GitHub for browser VS Code. Reverse Engineer Anything for understanding behavior of code the buyer will own.
- Build loop: Claude Code, the expensive model plans and reviews, Opus subagents implement in parallel worktrees, review-fix loop until approved; autonomy per task type after 20 passes at 95%, revoked under 90%; check stop_reason on every call; daily regression tests.
- Analytics: PostHog installed first post-close to find used flows.
- Performance checklist: gzip or brotli on API responses, batched DB writes, profile round-trip latency to find the single slow step, optimistic UI, cached rendering.

HARD CONSTRAINTS
1. Analysis only. Do not contact sellers, sign anything, or move money. Purchase decisions return to the user.
2. Revenue counts only when reconciled to processor and bank data within 5%; screenshots are not evidence.
3. Paper underwriting first: fully underwrite three shortlisted deals as if buying, without buying, and record your predicted payback for later comparison.
4. Caps: purchase price at most 50K USD and at most 3x verified seller's discretionary earnings; rebuild budget at most 6 months of verified profit.
5. Legal and tax points are flagged for a lawyer or accountant; never presented as advice.
6. Reverse engineering applies only to code and systems the buyer owns or has written permission to analyze.

DELIVERABLES IN ORDER
1. listings.parquet with score columns and a ranked shortlist of three with reasons.
2. diligence_requests.md per shortlisted deal.
3. tech_dd.md per deal: scc size, churn hotspots, secrets found, vulnerable dependencies, license conflicts, architecture diagram link, hosting cost, single points of failure.
4. rebuild_spec.md: flows to keep, flows to drop, target stack, characterization tests, migration plan (strangler pattern), hour estimate with a range.
5. compliance_perf_gaps.md: each of the ten legal traps and five performance gaps marked present, absent or unknown with evidence.
6. underwriting.xlsx or .csv: price, verified profit, multiple, rebuild hours times hourly cost, payback months, downside case with 30% revenue loss, falsifier check.
7. post_close_plan.md: 90 days, PostHog first, monthly churn tracking against the pre-close cohort baseline.

BUILT-IN GAP ANALYSIS
End with GAPS: every number not reconciled to source data; listing claims you could not verify; repo areas the comprehension tools could not explain; legal items needing a professional. Fill what you can now, for example by recomputing multiples from verified numbers.

SELF-QUESTIONS
- Is this app's value in code, or in a search rank or store listing that could vanish?
- What share of revenue comes from the top five customers?
- Does the hour estimate include data migration, support load and app-store review delays?
- Would rebuild plus migration cost more than six months of verified profit?
- Which of the ten legal traps already applies to the seller's current app, making me liable on day one?

STOP CONDITIONS
Stop and report if no listing survives revenue verification, if every shortlisted deal fails the payback test, or if repo access is refused.

RETURN FORMAT
Ranked shortlist with one-line verdicts, the file list, the underwriting table, GAPS, and self-question answers.

3 · Step-by-step prompts

Step 1 — Ground truth: listings and verified financials

Goal: Build a scored deal table from primary listing data and define what counts as verified revenue.

Collect every current software listing under 50K USD on Acquire.com and Flippa. Check each site's terms first; if automated scraping is not allowed, use their export, saved searches, or manual copy into a sheet. For each listing record: URL, asking price, claimed trailing-12-month revenue and profit, implied multiple, business age, tech stack, monetization (subscription, one-time, ads), traffic sources, platform dependency (App Store, Shopify app store, Chrome Web Store), stated churn, and seller reason. Score 1 to 5 on revenue stability, stack age (older stack means more rebuild leverage and more risk), share of code plausibly replaceable, and platform risk. Write listings.parquet and a shortlist of three with reasons. For each shortlisted deal, write diligence_requests.md asking for read-only processor access, 24 months of bank statements, Search Console and analytics, support volume, hosting bills, and repo access under NDA.

Expect: listings.parquet with all fields, a top-three shortlist, and three request lists.

Audit before moving on: Recompute every multiple from price and profit. Fail if any listing lacks a source URL or if shortlist reasons rely on unverified seller claims without flagging them.

Step 2 — Repo comprehension and technical diligence

Goal: Understand each shortlisted codebase fast and find hidden liabilities.

For each shortlisted repo (only after access is granted under NDA), run: gitingest to produce a single text dump; DeepWiki for generated documentation if the repo is public or mirrored privately; GitDiagram for an architecture diagram; GitMCP so the agent can query the repo live. Then run scc for size and language mix, git log --numstat for churn hotspots over the last 12 months, gitleaks for committed secrets, osv-scanner on lockfiles for vulnerable dependencies, and scancode-toolkit for license conflicts. Identify single points of failure: one maintainer, one payment integration, unmaintained SDKs, hard-coded credentials. Write tech_dd.md per deal with findings, severity, and the estimated fix hours. Finally, list the three files or modules an executor agent would need to read first to change any core flow, and note where DeepWiki's generated docs disagreed with the code.

Expect: Three tech_dd.md files with tool output summaries, a diagram link or image, and a severity-ranked findings list.

Audit before moving on: Confirm each finding cites the tool output line. Fail if secrets are copied into the report; report only the file and rule ID. If a tool failed to run, mark that area unknown, not clean.

Step 3 — Rebuild spec scoped to used flows

Goal: Specify the smallest rebuild that keeps paying customers.

Using tech_dd.md, the seller's analytics, and support tickets, list every user-facing flow and mark it core, secondary, or dead. If usage data is weak, specify installing PostHog first post-close and deciding after two weeks of events. Write rebuild_spec.md: flows to keep, flows to drop, target stack, data model and migration plan using a strangler pattern (route one flow at a time to new code), characterization tests in Playwright for every core flow written against the old app before any rewrite, and an hour estimate per flow as low, expected and high. Include the five performance fixes as explicit tasks: response compression, batched writes, latency profiling, optimistic UI, cached rendering. Structure the work for an orchestrator that writes specs and reviews, and executor subagents in parallel worktrees, with autonomy granted per task type after 20 passes at 95%.

Expect: rebuild_spec.md with a flow table, test list, migration sequence and hour estimates with ranges.

Audit before moving on: Fail if any core flow lacks a characterization test or if the estimate omits data migration, support and app-store review delays. Sum hours and compare to a naive estimate from scc line counts; explain gaps over 2x.

Step 4 — Compliance and performance gap list

Goal: Find liabilities the buyer inherits on closing day.

For each shortlisted app, check the ten legal traps from the source post: no privacy policy; policy not disclosing data collection; policy not disclosing AI use; policy not naming third-party processors; uploads promised deleted but still stored; public storage buckets; fake testimonials; hard-to-cancel subscriptions; trial auto-charges without reminder; chatbots without self-harm handling. Inspect the live site, the policy text, storage configuration (bucket ACLs), subscription flow, and deletion code paths. The per-user fine figures in the post are claims; replace them with the actual governing rules (GDPR, CCPA/CPRA, state automatic-renewal laws, FTC guidance on reviews and negative-option billing) and mark each for lawyer review. Then measure the five performance gaps on the live app: response compression headers, write batching in code, request waterfall timing, UI update behavior, cache headers. Write compliance_perf_gaps.md with present, absent, unknown, evidence and fix hours.

Expect: A 15-row table per deal with evidence links or code references.

Audit before moving on: Fail if any row is marked absent without evidence. Do not test bucket access by downloading user data; check configuration only.

Step 5 — Paper underwriting of three deals

Goal: Decide on paper whether the AI rebuild discount is real at this size.

For each shortlisted deal, build underwriting.csv: asking price, verified trailing-12-month profit (or 'unverified' and excluded), multiple on verified profit, rebuild hours from rebuild_spec.md times the buyer's hourly cost, compliance and performance fix hours, migration cost, and payback months. Run a downside case with revenue down 30% and churn at twice the baseline. Apply the falsifier: rebuild plus migration cost above six months of verified profit, or expected post-migration churn above 10%, fails the deal. Apply caps: price at most 50K USD and at most 3x verified seller's discretionary earnings. Record predictions (hours, churn, payback) in predictions.json with a timestamp so a later actual can be scored against them. Compare to a control: what the same capital earns in a treasury bill over the payback period.

Expect: underwriting.csv, predictions.json, and a one-paragraph verdict per deal.

Audit before moving on: Fail if any input is unverified but used as verified. Recompute payback with a fresh script. Check the downside case is actually computed, not described.

Step 6 — Validate against oracles and write the gap report

Goal: State which deal, if any, passes, and what remains unproven.

Assemble final_report.md. For each deal: verified versus claimed revenue difference, tech findings by severity, compliance liabilities, payback base and downside, falsifier result, and a buy, pass or need-more-data verdict for the user to decide on. Write post_close_plan.md for the best deal: day 1 PostHog and credential rotation, weeks 1 to 2 characterization tests, weeks 3 to 10 strangler rebuild of core flows with daily regression tests in CI, monthly churn from the processor against the pre-close cohort. Then a GAPS section listing every source claim (18B USD IPO from 40K USD; public SaaS down roughly half; AI cheapens rebuilds; earned autonomy works unattended; the legal fine figures) as verified, unverified or false with evidence, and every deal number that is still seller-reported. Recommend which professional must review what before any money moves.

Expect: final_report.md, post_close_plan.md and a GAPS list.

Audit before moving on: Fail if a buy verdict rests on any unverified number or if the report omits the lawyer and escrow requirement. Cross-check three numbers against underwriting.csv.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are an independent reviewer of a micro-acquisition package. Open listings.parquet, tech_dd.md files, rebuild_spec.md, compliance_perf_gaps.md, underwriting.csv, predictions.json and final_report.md. List every number and claim that supports a buy or pass verdict. Mark each verified (cite processor export, bank statement, tool output or code line), unverified (name the document that would prove it), or false. Specifically check: revenue reconciled to processor and bank within 5%; multiple computed on verified profit; rebuild hours include migration, support and store review; every core flow has a characterization test; secrets were not pasted into reports; each legal row cites the governing rule rather than a social-media fine figure; the downside case was computed; the falsifier threshold of six months of profit was applied. List missing items such as unrequested documents, unscanned repos, or untested flows. Rank by how much each could change a buy verdict, fix the top three now by recomputing or requesting the missing document in the requests list, and report before and after. End with what cannot be fixed without the seller, a lawyer or an accountant, and confirm no money moves before those reviews.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Start with Acquire.com and Flippa listing data, then stop and hand the shortlist and request lists to the user, because data room access, NDAs and seller contact are the user's actions. Cache listings and every tool output under a deals/ folder per listing. Once repo access exists, spawn one sub-agent per shortlisted repo for step 2 tool runs in isolated worktrees, and review their findings by spot-checking three tool outputs each. Run steps 3 to 5 yourself, since they are judgment-heavy. Never paste secrets found by gitleaks into any report. Never run reverse-engineering tools on apps the user does not own or have written permission to analyze. Stop and ask when revenue cannot be verified, when a legal question decides the verdict, or before any communication with a seller. Return final_report.md as the entry point, with listings.parquet, tech_dd.md files, rebuild_spec.md, compliance_perf_gaps.md, underwriting.csv, predictions.json and post_close_plan.md beside it.

Prompt system updated 2026-10-22 · all prompt systems · JSON

Browse more deep dives at DejaViewed — 846 entries across the full catalog.


Generated 2026-10-22 · curated by @6ab3 for DejaViewed