Redundancy & Security
You will get hacked if someone wants it badly enough. Anonymous took down the NYSE three times in one day. The question is not whether something goes wrong — it is how fast you recover and how much you lose when it does.
The Only Question That Matters
Most solo builders think about security as "how do I prevent bad things from happening." That is the wrong frame. Determined attackers get in. Infrastructure fails. Companies get bought and shut down. The right question is: when something goes wrong, how much do you lose and how fast are you back up?
Build for recovery speed, not just prevention. If you can redeploy everything from scratch in 20 minutes, a breach is painful but survivable. If your only copy of the codebase is on your laptop, you are one hard drive failure away from losing everything.
GitHub Is Non-Negotiable
This is not optional. This is the first thing you do before you write a single line of code.
The VitalForge lesson
A whole build — weeks of work — lost because the only copy was local. No GitHub. No backup. Drive failure, accidental deletion, it does not matter what the cause was. The result was starting over from zero.
This is a loss you only have to experience once to never make again. The problem is that experiencing it once is very expensive. Learn from it without paying the tuition.
Push after every session
You do not need a perfect commit message. You do not need a clean commit history. You need the code to exist somewhere other than your local machine. Push after every meaningful session, no exceptions. A bad commit message is infinitely better than no commit.
git add .
git commit -m "wip"
git pushThis is 10 seconds. There is no excuse not to do it.
Private repos are free
GitHub private repositories are free for individuals. There is no cost reason to keep code only local. Every project, no matter how small, no matter how early, gets a GitHub repo on day one.
Do Not Build Your Business Inside a Single Vendor
Use the vendor's intelligence. Do not store your operations inside them.
The Cautionary Tale
A company with 60+ accounts had their entire operation inside one AI vendor's ecosystem. Their workflows, their automations, their customer data pipelines — all of it living inside that one platform. When the vendor's automated system flagged them and revoked access, everything went dark. Not some of it. Everything.
The appeal process was a Google Form. No phone number. No escalation path. Just a form submission and a wait.
The lesson: use Anthropic's intelligence. Use OpenAI's intelligence. Use any vendor's intelligence. But do not store your business inside it. Your business logic, your data, your customer relationships — those live in infrastructure you control. AI sits on top as the intelligence layer. If a vendor bans you or shuts down, you swap the intelligence layer and keep running.
Your code lives in GitHub
Not in a vendor's platform. Not in a browser-based builder that stores your project on their servers. GitHub is infrastructure you control. If Vercel disappears tomorrow, your code is still in GitHub. You can deploy it somewhere else in minutes.
Your data lives in Firebase (or Postgres, or your own DB)
Not exported to a vendor's proprietary format. Firebase is Google infrastructure, and you can export your Firestore data at any time. If you use a relational database, you can take a dump and move it anywhere. Your data should be yours to take with you.
Your AI layer is swappable
The Anthropic API call in your code is one config change away from being an OpenAI call, a Gemini call, or any other provider. This is how you build: the AI is intelligence that you plug in, not the foundation everything rests on. Swap providers in minutes, not weeks.
// Environment variable — change one line to switch providers
AI_PROVIDER=anthropic // or openai, gemini, etc.
AI_MODEL=claude-sonnet-4-6Blast Radius Thinking
Before you make an architectural decision, ask: if this piece fails, what else goes down with it?
Isolate your dependencies
Your hosting going down should not take your database with it. Your AI provider going down should not make your app throw errors for every user. Each layer of your stack should fail independently. Firebase going down affects your data layer but not your static site. Vercel going down affects your hosting but not your data.
Single points of failure
Identify every place in your system where one failure takes everything offline. An API key with no rate limit fallback. A database with no read replica. A payment processor with no retry logic. Every single point of failure is a future incident waiting to happen. Some are acceptable. Know which ones they are.
Test your recovery
Do not assume your backup works. Pull a fresh machine, clone your repo, follow your own deployment docs, and see how long it takes to get back online. If you have never done this, you do not actually know if you can recover. The time to find out is not during an incident.
Billy's Personal Redundancy Stack
Every project Stacked Alchemist ships is built on this structure. Blast radius is contained. Recovery is fast.
Code: GitHub
Everything. Always. No exceptions. Every project has a private GitHub repo from day one. If the laptop dies, the code lives. If VS Code gets corrupted, the code lives. Push after every session.
Data: Firebase
Firestore for application data, Firebase Storage for files. Not on the local machine. Not dependent on a single vendor's proprietary lock-in. Firebase is Google infrastructure with a real export path. Data can move if it ever needs to.
Deployment: Vercel
Auto-deploys from GitHub on every push to main. If Vercel goes down, the last known-good deploy is cached on Cloudflare's edge. If Vercel closes, the code is in GitHub and can be deployed to Firebase Hosting, Netlify, or a VPS in under 20 minutes.
DNS and CDN: Cloudflare
DDoS protection, SSL, and caching handled at the edge. If the origin goes down, Cloudflare serves cached content to users while the problem is being fixed. Changing where the domain points is a five-minute DNS update — not a redeployment.
AI Layer: Anthropic API (swappable)
The Anthropic API is the intelligence layer. It sits on top of the infrastructure, not inside it. If Anthropic changes its pricing, updates its models in a way that breaks behavior, or bans an account, the application keeps running. One environment variable change swaps the provider. The business logic is not tied to the AI vendor.
If You Do Nothing Else, Do These Three Things
1. Use GitHub for everything
Private repos are free. Push after every session. This is the single highest-value thing you can do for the survivability of your work. Everything else on this page is secondary to this.
2. Never store secrets in code
API keys, database passwords, OAuth secrets — these go in environment variables, never in the code. A .env file never gets committed to GitHub. Add .env to your .gitignore before you write a single line of application code. One leaked API key can cost thousands of dollars before you notice.
3. Build on infrastructure, not inside vendors
Your code owns GitHub. Your data owns Firebase. Your AI vendor is a plug you can swap. The moment you build in a way that makes it painful to leave a vendor, you have given that vendor leverage over your business. Build portable from day one.
Build It Right From the Start
The CLAUDE.md template includes sections for third-party services and deployment setup. Document your stack before you build it. Claude Code follows that documentation exactly.