Most engineering teams have one or two systems where the underlying patterns could be a sellable product or an open-source library. The traditional path — months of careful manual extraction — is why it almost never happens. Here is how we extracted PayoutKit (a Stripe Connect commercial boilerplate) from PickNDeal (a working production marketplace) in one weekend, using the agentic delivery method as the surgical instrument.
The setup
PickNDeal had a hardened Stripe Connect surface: destination charges with on-top platform fees, KYC onboarding via Stripe Express, multi-supplier payouts, saved cards, faktura/CVR business invoicing for Danish buyers, idempotent webhook handlers. All running in production, fixed against real edge cases.
The category of marketplace builders who'd pay for a clean starting boilerplate that solves the same problems we'd already solved is well-defined. The work was already done; the question was whether we could package it without taking another month.
Phase 1 — diagnostic agent run (no writes)
The first agent run touched no files. Read the entire PickNDeal codebase, classify every file that touches Stripe Connect into one of three buckets:
- Extract verbatim — generic Stripe handlers, types, error mappers.
- Sanitise — files with Danish strings (CVR, faktura), business-specific naming (supplier, restaurant, group_order), or PickNDeal-specific role enums.
- Drop — marketplace-specific business logic (RFQ flow, group-order matching, multi-supplier offer mechanics) that doesn't belong in a generic Stripe Connect starter.
Output: a structured manifest of about 40 files with a one-line note per file. A diagnostic-only run is a methodology invariant — agents that read are infinitely safer than agents that write, and the manifest becomes the contract for the next phase. We reviewed it together, found two files misclassified (“sanitise” that should have been “drop”), corrected, ran phase 2.
Phase 2 — generate the clean repo
Second agent run took the manifest and produced the new repo. Generic Express/Custom account onboarding flows. Two-role demo (vendor + buyer) demonstrating the Stripe Connect mechanics without leaking the marketplace context. RoleSwitchPrompt component for the role-mismatch UX. Webhook handlers with the same idempotency patterns we'd hardened in production. All as a fresh git history with human-style commit messages — no automated “feat: …” conventional-commits noise, just clear English describing what each commit does.
Critical guardrail: the agent ran with no network access to the source PickNDeal repo during this phase. Everything was sourced from the manifest from phase 1. This prevents two failure modes: (a) accidentally pulling in adjacent files that weren't in the extraction set, and (b) leaking the original repo's commit history into the new one.
Phase 3 — production-shape verification, not toy-shape
Reproducing in production-shape rather than toy-shape is one of the methodology's invariants. For a Stripe Connect product, that means running the full flow against real Stripe APIs in test mode, not against mocked fixtures.
The plan generated by the methodology:
- Create an Express account via the new repo's onboarding flow
- Complete the Stripe-hosted onboarding redirect with test data
- Trigger a destination charge: $50 base + $5 platform fee = $55 buyer-pays, $50 to vendor, $5 retained
- Verify webhooks fire:
account.updated+payment_intent.succeeded - Verify order auto-flips to paid in the demo DB
- Verify saved cards CRUD (add / list / set default / detach)
Two issues surfaced. First: destination-charge metadata wasn't round-tripping correctly because the extraction had dropped a piece of code that re-attached metadata after webhook receipt. Fixed by re-adding the function with generic naming. Second: the webhook signing-secret env var name had been renamed in the extraction (good — generic name) but one usage site was missed. Caught by curl, fixed in two minutes.
Phase 4 — landing page + LICENSE in parallel
Concurrent with the technical extraction, the methodology generated the marketing surface and the commercial terms.
Marketing landing: hero, problem section, features, pricing, FAQ, plus a visual checkout-breakdown demo card. Generated from a brief and the technical capability spec. Reviewed in browser before publish. We rewrote the hero from technical-features-led to story-led after the first community feedback cycle on Reddit (within two hours of going live). The methodology supports tight iteration loops like this — landing v2 was redeployed within 90 minutes of the feedback.
Commercial LICENSE.md v1.0: Single-App / Multi-App tier terms, 30-day refund window, 12-month updates, Danish governing law. Generated against a brief, reviewed line-by-line against the actual sales model we wanted, committed.
Phase 5 — production checkout (no test-mode banners)
Polar (Software Inc) as the merchant of record — production checkout with VAT computation per buyer jurisdiction, GitHub-repo-benefit auto-granting Read access on purchase. Two product tiers configured.
The methodology has an explicit invariant here: verify production checkout before pointing any paid traffic at it. The check is concrete:
- Local currency renders correctly with the buyer-jurisdiction VAT applied
- Merchant-of-record legal text shows on the Pay button (Polar Software, Inc.)
- No “TEST MODE” or “Sandbox” banner on the checkout page
- Production checkout URL prefix differs from the sandbox prefix
We curl'd through the redirect chain (polar.sh/checkout/polar_c_*) and confirmed both tiers' URLs were production. Five minutes of work that prevents the embarrassment of paid traffic landing on a sandbox checkout.
Phase 6 — deploy + ship
GCP VM, nginx vhost, Let's Encrypt SSL on apex + www, PM2 fork mode (not cluster — the methodology has an invariant against cluster mode for Next.js because it crashes the SSR runtime under certain build artefacts). Build-then-swap deploy script: build to .next-new/, atomically swap with .next/, the running PM2 keeps serving the old build the entire time. Health-check the new build before commit; rollback automatically if it fails.
Live at payoutkit.dev within 12 working hours of starting.
What the method delivered
- A complete commercial product (codebase + landing + checkout + LICENSE + analytics) shipped in ~12 working hours
- Zero leaked Danish strings, zero PickNDeal references in the public repo
- End-to-end verification against real Stripe APIs, not mocked fixtures
- Audit trail of every agent decision, reviewable
- A second product in the portfolio with shared maintenance — any production fix in PickNDeal's Stripe Connect code is a candidate fix for PayoutKit
What this looks like applied to your codebase
Your team likely has one or two systems where the same shape applies. An internal SDK that could be extracted from a monolith. A workflow framework that has matured past its original use case. A production-tested integration that the rest of your industry would buy. The methodology is applicable wherever the source code is hardened and the extraction surface is well-defined.
The order — diagnostic, generate, verify, package, deploy — holds. The human-review gates on each phase hold. The production-shape verification invariant holds. What changes per project is the extraction manifest in phase 1; that's the engagement-specific work, and it's where the methodology earns its time-saving.
The full case study with architecture diagrams is at /case-studies/payoutkit. The methodology this came from: /method. Extraction projects are a fit for our agentic-build engagement track — /services.