Your stack list won’t ship your product

The bookmark trap

A few days ago I answered a thread on X with the stack I actually run — my “2026 indie dev stack,” a dozen tools in one reply. The reply collected over a hundred bookmarks and sent more than a hundred clicks to this site.

The analytics were less flattering: most visitors scanned a page and left. A stack list reads like a finished plan; a copied list ships nothing. Every tool still has to be installed, wired to its neighbors, and tested — the seams between them are where the weeks go.

This is the post the bookmarks were looking for: not which tools I run, but which plumbing was already load-bearing — and what that let me ship in forty-eight hours.

Where projects actually die

Most indie projects do not die on their core feature. They die in week one, on infrastructure that has nothing to do with the idea. Motivation has a half-life of about forty-eight hours — every hour spent away from the product burns the scarcest resource a solo build has.

The shape of the week is remarkably consistent:

• Day one: monorepo layout, ESLint, tsconfig paths, database migrations.
• Day three: still in the payment provider’s docs, getting webhook idempotency right.
• Day five: a desktop or mobile companion — a new build pipeline, a new auth surface, auto-updates from scratch.

A 48-hour build, end to end

Last week I shipped SpinShare, a Windows-native desktop utility: drag a file in Explorer, tap Shift, and a radial menu opens under the cursor; release to run a local conversion or operation. No popups, nothing uploaded; the file never leaves the machine.

The timeline is the part worth examining: new repository, Rust core logic, an offline license flow on my existing billing rails, and a Microsoft Store submission — forty-eight hours of core development, pair-coding with an agent and almost no prompt-tuning. The agent did not derail for an unglamorous reason: the architecture boundaries where it hallucinates were already sealed inside supastack, my own kit.

What follows is the accounting: the plumbing that did not have to be built in those two days.

Setup and guardrails

pnpm setup collapses bootstrap into one command: preflight checks, environment-variable alignment, dependency installs, database migrations. There is no first evening spent assembling a working environment — the repository either passes its own checklist or names what is missing.

The .ai/ mirror docs, AGENTS.md, and .agents/skills/ are a contract written for the agent rather than the human — each package’s responsibility boundary, its test rules, its red lines (the desktop app is a single-webview shell that never forks product UI). The project structure guide shows the layout it reads; the agent workflow post covers the working rhythm.

Boundaries that are written down are boundaries an agent cannot wander across.

Billing and releases shipped ready-made

Eight billing adapters sit behind one contract — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop, and PayPal — and a webhook_event ledger makes every settlement signature-verified and idempotent before it becomes a license or an email. My work began downstream of it: Early-Bird tiers that switch by order count, and Ed25519-signed offline license keys — a desktop tool must activate without a network call. The billing module guide documents the flow I extended.

The release side was equally uninteresting, which is the point. The Tauri 2 pipeline — desktop-release.yml — builds signed bundles and generates latest.json via minisign for stable and beta channels across Windows (NSIS and msi), macOS (dmg), and Linux (AppImage). The only packaging work I did myself was an MSIX build for the Microsoft Store; the desktop quickstart covers the rest.

The ten percent users actually feel

Here is the arithmetic a stack list hides. Roughly ninety percent of what a product needs is plumbing the user never sees. Invisible plumbing is the work a foundation should carry — it is the part that can be carried. The rest is the product.

Because mine was already load-bearing, nearly all of my forty-eight hours went to the ten percent users can feel — work that never fits in a stack comment, and never happens while the week goes to webhooks and signing:

• Windows OLE drag hooks in Rust, so the menu arms only while a real file drag is held with Shift — never while typing.
• A multi-window tray flow, so the tool stays one keystroke away without a taskbar window.
• The radial-menu animation, tuned until the menu reads instant instead of animated.
• More than thirty local format converters, each with its own unit tests.

The practical part: pricing and transparency

The fair objection: “I have Cursor — why pay for a stack list?” It holds until your own time has a price. Two evenings of webhook idempotency cost you a feature you did not ship.

On transparency: the documentation is public in full — directory structure, dual web engines, cross-platform sync, all eight billing adapters, AI routing. I would rather a skeptic read it end to end and walk away than buy on a headline; starter kit or from scratch is the honest version of the decision.

Two practical notes: the displayed prices already include $100 in launch savings, and checkout supports Alipay. And a 50% builder cashback — ship a real product within sixty days, share the build story publicly (5,000 organic views or 50 organic likes on X, Reddit, YouTube, or similar), and email me the link: half comes back, and the license stays yours. The rules live at the launch-cashback terms.

Common questions about stack lists

The same objections surface whenever the kit does. They deserve straight answers.

• Can’t an agent scaffold all of this for me? — It can produce something plausible; it cannot verify the seams in one pass. An idempotent webhook is tested, not generated — scaffolding hands you the same list again.
• Doesn’t a boilerplate make products generic? — The plumbing is shared; the product is not. SpinShare’s drag hooks, tray behavior, and converters exist nowhere in the kit — the ten percent customers see stays yours.
• What if I only need a web app? — The kit is the purchase either way; mobile and desktop are surfaces to adopt or ignore, not requirements. SpinShare exists because the desktop surface was already built.
• Is a desktop utility really the buyer story? — It is the shortest honest example I have: two days from an empty repository to a store submission. The same plumbing serves a SaaS — the launch checklist is the longer version.
• Why not just publish the stack list? — Done: the tech stack guide names every choice and its reason. A list is a menu, not a plan — the argument here is for buying the plan already built.