Resources

The tools matter far less than the founder using them. Every stack in this chapter can build a great company or an abandoned one, the difference is judgment, focus, and the will to ship, none of which come in a subscription. Treat this as a reference to return to, not a shopping list to buy. Start with almost nothing; add only when a real constraint demands it.

The concept

This chapter consolidates the tools, services, and costs referenced across the whole handbook into one reference, and, just as importantly, a way to think about assembling them. Two principles govern a good stack:

Start free, add on constraint. Nearly every category below has a capable free tier. A complete pre-launch stack, build, deploy, landing page, email, analytics, AI, can cost under $50/month. Don't buy tools ahead of need. A tool you're not yet constrained by is a subscription and a distraction, not leverage.

Own the compounding layers; rent the rest. Own your domain, your email list, and your content (they compound and can't be taken from you, Chapters 35, 44, 46). Rent everything else (hosting, tools, services) and switch freely. The distinction between owned and rented assets matters more than any specific vendor.

 OWN (compounds, portable)    domain · email list · content · code · data
 RENT (swap freely)           hosting · tools · analytics · SaaS · AI

The trap: tool sprawl

More tools is not more progress. Every tool is setup, a subscription, a context-switch, and a thing to maintain. Founders under-shipping often have immaculate tool stacks, configuring tools is a comfort-trap form of avoiding the hard work (Chapter 53). The best stack is the smallest one that lets you ship.

📐 The best stack is the smallest one that lets you ship, the tools are never the constraint. A complete pre-launch stack costs under $50/month, so cost almost never blocks you; focus and shipping do. Own the compounding layers (domain, list, content, code, data), rent everything else, and don't mistake a beautiful stack for progress.

📐 Best practice

Start with free tiers; upgrade only when genuinely constrained.

Own the compounding layers, domain, list, content, code, data.

Rent everything else and stay ready to switch.

Minimise the stack, the fewest tools that let you ship.

Prefer tools you'll actually use over the most powerful option.

Avoid lock-in on anything you can't export.

Don't let tool-tweaking replace shipping (Chapter 53).

Reassess periodically, needs change; yesterday's free tier may now cost, or vice versa.

Track your recurring costs so the stack doesn't quietly bloat (Chapter 41).

Choose boring, proven tools for critical paths; experiment only where failure is cheap.

💀 Common mistakes

Tool sprawl, a beautiful stack and an unshipped product.

Buying ahead of need, paying for scale you don't have.

Lock-in, data or content trapped in a tool you can't leave.

Chasing the newest tool instead of using what works.

Configuring instead of shipping, comfort-trap avoidance (Chapter 53).

Not owning the compounding layers, building an audience on rented land.

Untracked subscriptions, costs quietly bloating (Chapter 41).

Over-engineering the stack for a stage you're not at.

Under-investing where it matters, skimping on the few things that are actually load-bearing.

Copying someone else's stack without their constraints.

The professional workflow

 1. START MINIMAL — the smallest free stack that lets you build and ship

 2. OWN THE COMPOUNDING LAYERS first — domain, list, content, code

 3. ADD A TOOL only when a real constraint demands it

 4. PREFER FREE TIERS; upgrade on constraint, not aspiration

 5. AVOID LOCK-IN — check you can export before you commit

 6. TRACK RECURRING COSTS so the stack doesn't bloat

 7. REASSESS periodically as needs and tiers change

 8. RESIST tool-tweaking as a substitute for shipping

Tools, websites & costs: the master reference

Consolidated from every chapter. Categories map to the handbook's Parts. Nearly all have free tiers; prices are indicative for an early-stage solo founder.

Idea, research & validation (Part I-II)

Design (Part III)

Building (Part IV)

Money (Part V)

Quality (Part VI)

Shipping (Part VII)

Company (Part VIII)

Go-to-market & growth (Part IX-X)

The founder (Part X)

What a realistic solo-founder stack costs

 PRE-LAUNCH (build + validate)     ~$0-50/month
   AI coding $0-20 · hosting $0 · backend $0 · domain ~$1/mo ·
   email $0 · analytics $0 · design $0

 LAUNCH (add the essentials)       ~$50-150/month + one-offs
   + app store $99/yr · + a paid tier or two as you outgrow free ·
   + privacy/legal $0-20/mo

 GROWING (scale what works)        scales with revenue
   + paid acquisition (only on proven economics, Chapter 48) ·
   + higher tiers · + first contractors/hires (Chapter 52)

The entire pre-launch stack fits in a rounding error. Cost is almost never the constraint before launch, focus and shipping are.

AI prompt patterns that recur across the handbook

Working with AI is a thread through the whole book (Chapters 15, 23, 24, 30, 52). The patterns that produce reliable results:

• Give context, a specific ask, and a defined output. "Here's the code/goal/constraint; do X; return it as Y." Vague in, vague out (Chapter 24).
• Ask for the reasoning, then the answer on hard problems, it surfaces flawed assumptions before they reach your code.
• Adversarial review: "Find the bugs, security holes, and edge cases in this. Try to break it." The single highest-value AI habit (Chapters 30, 52).
• Force alternatives: "Give three approaches with trade-offs" beats "do it my way", it widens the option space before you commit.
• Always verify. Review code, fact-check claims, test output. You own it (Chapter 52).

Alternatives & trade-offs

All-in-one vs best-of-breed. All-in-one (e.g. Supabase for DB+auth+storage) means fewer tools, less integration, and some lock-in; best-of-breed picks the strongest tool per job at the cost of integration work. Early, favour all-in-one, fewer moving parts lets you ship faster.

Free tier vs paid from the start. Free tiers stretch remarkably far and can hit limits at the worst moment (a launch spike); paying early buys headroom you may not need. Start free; know each tool's limits and upgrade just ahead of hitting them.

Popular vs niche tools. Popular tools have community, docs, AI familiarity, and longevity; niche tools may fit better and risk abandonment. For load-bearing infrastructure, prefer popular and proven; experiment with niche only where switching is cheap.

Build vs buy. Building gives control and costs time you don't have; buying is faster and adds dependency and cost. Buy almost everything early, your scarce time belongs on the product, not on rebuilding solved infrastructure.

Own vs rent. Owned layers (domain, list, content, code, data) compound and can't be taken from you; rented layers (tools, hosting) are swappable conveniences. Never build a compounding asset on rented land, own the domain and the list especially.

Checklist

• My stack is minimal, the fewest tools that let me ship
• I own the compounding layers (domain, list, content, code, data)
• I rent everything else and can export/switch
• I started on free tiers and upgrade only on constraint
• I track recurring costs so the stack doesn't bloat
• I avoid lock-in on anything I can't leave
• I use proven tools on critical paths
• I'm not tool-tweaking instead of shipping
• I use AI with clear prompts and always verify
• I reassess the stack as needs change

📓 Case Study: the actual SOLIS stack, and what it cost

Project: SOLIS. A concrete example of a real, complete, solo-plus-AI stack, useful precisely because it shows how little the tooling costs and how little that guarantees.

The actual stack, end to end:

• Build: AI-assisted development (Claude Code), Capacitor for the iOS app, a static-site approach for the web.
• Backend: Supabase, Postgres, anonymous auth, offline-first sync, Edge Functions for account deletion. On the free tier.
• Infrastructure: a domain (solisascent.com, ~$12/yr), email routing for a support address, transactional email with domain authentication (SPF/DKIM/DMARC) for the waitlist confirmations (Chapter 35).
• Content & art: AI-written lessons; an AI art pipeline with a themed dedup system (hundreds of images); a Remotion-based content engine (Chapters 46-47).
• Distribution surfaces built: a landing page with a waitlist, a support/FAQ page, store listing assets.

⭐ The whole stack cost almost nothing, proving the chapter's core claim. The recurring cost was essentially a domain (~$12/year) plus AI subscriptions (~$20-100/month); everything else ran on free tiers (Supabase, hosting, email routing, analytics-when-wired). The one-time Apple Developer fee ($99/yr) was the largest hard cost, and it was for a launch that didn't happen. A complete, full-stack, polished product was built for a rounding error in tooling cost. Cost was never remotely the constraint.

⭐ It owned the right compounding layers. SOLIS correctly owned its domain, its code, its content (90 lessons, the art), and its data model, the portable, compounding assets. That instinct was right.

⚠️ But the stack also demonstrates the chapter's warning: a perfect, cheap stack guarantees nothing. SOLIS had a clean, modern, well-chosen, inexpensive stack, and never launched (Chapter 45). The tooling was never the problem. Two specific gaps stand out:

• The email list, the one rented-land risk, was under-owned in practice. A waitlist existed, but the list was small, unvalidated, and its collection endpoint was insecure (Chapter 44). The compounding asset that most matters for launch was the least developed.
• Analytics, free and essential, were never wired (Chapters 38, 49), so the cheap, available measurement layer that costs nothing was simply absent.

🚩 The stack is validated as buildable, not as a business. SOLIS proves you can assemble a complete, modern, nearly-free stack solo. It proves nothing about whether that stack produces a successful product, because the product never launched. The tools were never the constraint, and that's the chapter's whole point.

What generalises:

1. A complete pre-launch stack costs almost nothing, SOLIS is direct evidence (~$12/yr + AI subscriptions).
2. Own the compounding layers, SOLIS owned domain, code, and content well, and under-owned the email list, which is exactly the asset that most matters at launch.
3. A perfect cheap stack guarantees nothing. The tools were never the constraint; shipping was. Don't mistake a clean stack for progress.
4. The free, essential layers are the ones to never skip, analytics especially. SOLIS had every expensive option covered and skipped the free, load-bearing one.

Lessons

1. Start with almost nothing. A complete pre-launch stack costs under $50/month, cost is rarely the constraint before launch.
2. Own the compounding layers, domain, email list, content, code, data. Rent everything else and switch freely.
3. The email list is the compounding asset that most matters at launch, don't under-own it.
4. Never skip the free, load-bearing layers, analytics especially. SOLIS covered the expensive options and skipped the free essential one.
5. Minimise the stack. The best stack is the smallest one that lets you ship; tool sprawl is avoidance wearing a subscription.
6. A perfect cheap stack guarantees nothing. The tools are never the constraint, focus, judgment, and shipping are.
7. Use proven tools on critical paths; experiment only where failure is cheap.
8. Use AI with clear prompts and always verify, you own the output.
9. The founder matters more than the stack. Every tool here can build a great company or an abandoned one.

This completes Part X, Growth and beyond, and the handbook.

Afterword: what the whole book was really about

Fifty-four chapters, one throughline. The handbook walked the full arc, idea, validation, design, building, money, quality, shipping, company, go-to-market, growth, and used one real project, SOLIS, as the case study running underneath all of it.

SOLIS is a strange and honest teacher: a genuinely excellent product that never launched. Built solo with AI, polished, complete, submittable, and sitting at zero users and zero revenue because the last, uncomfortable, decisive work never got done. It got the building right at almost every turn and got the shipping wrong at the only turn that ultimately counted.

That's why it's the case study for a handbook about building a business, not just a product. Its strengths teach the craft; its one great failure teaches the lesson that outranks all the craft:

Building is not shipping. A finished product is not a launched one. And everything that actually matters, users, revenue, retention, growth, learning, begins only after you flip the switch you're afraid to flip.

The chapters gave you the recommended practice first and the real deviation second, exactly so you can take the method without repeating the mistake. Use the tools. Own the compounding layers. Run the systems. And then, earlier and more uncomfortably than feels safe, ship.