DTH

Purpose

First real attempt at building something beyond bootcamp exercises — a blog-style web app with a backend. The code was rough, but the lessons about security, deployment, and project initialization are ones every developer learns the hard way exactly once.

Stack

What I Learned

• Never store API keys in your repository. Not in a comment, not in a config file, not even in a "private" repo. Git history is permanent — even if you delete the key in a later commit, it lives in the history forever. Bots scrape GitHub constantly looking for exposed credentials. If you accidentally commit a key, rotate it immediately. Do not just delete the commit.
• Environment variables are the solution. They store sensitive values (API keys, database URLs, secrets) outside your codebase in the runtime environment. In development, you use a .env file (which is gitignored). In production, you use your hosting platform's environment variable settings. The code reads process.env.API_KEY — the value changes per environment, the code stays the same.
• Different deployment platforms handle secrets differently. Vercel and Netlify have environment variable dashboards. AWS has Secrets Manager and Parameter Store. Docker uses build args and runtime env vars. Kubernetes has Secrets objects. GitHub Actions has repository secrets. The principle is always the same: secrets live in the platform, not in the code.
• The .gitignore file is your first line of defense. Before writing a single line of code, your .gitignore should exclude .env files, node_modules, build artifacts, and any credentials. This is not optional configuration — it is project hygiene.
• Getting started with a project is simpler than it feels: pick a problem, pick a stack you want to learn, initialize the repo (git init), set up .gitignore, create the entry point, and start building. Overthinking the architecture before writing code is procrastination disguised as planning. Build first, refactor when the shape of the problem becomes clear.

Key Insights

• Security is not a feature you add later — it is a habit you establish from the first commit. The developers who never leak keys are not more careful people. They are people who set up .env and .gitignore before they write any code. Systems beat discipline every time.
• The "how do I get started?" question paralyzes more aspiring developers than any technical challenge. The answer is boring and universal: create a folder, run git init, add a .gitignore, create an index file, and start solving the smallest possible version of your problem. Everything else — architecture, databases, deployment — comes when you need it, not before.
• First projects are supposed to be messy. DTH was not production-quality code. It was a learning artifact — proof that the jump from tutorials to real projects had been made. The value of a first project is not the project itself. It is the developer you become by finishing it.
• Key management scales with your application. Solo project: .env file. Team project: shared secrets manager. Enterprise: centralized vault with rotation policies, audit logs, and least-privilege access. Understanding the spectrum early prevents security debt later.