Build Things That Survive Your Calendar: A Field Guide to Side Projects That Actually Teach You Something

Every developer has a graveyard. The to-do app number four. The half-finished React clone of a site nobody visits. The podcast platform that was going to be a startup until week three. These projects don't fail because you're lazy or untalented. They fail because they were sized for a version of your life that doesn't exist — one with unlimited evenings and no deadline pressure from the actual job that pays the mortgage.

The good news: some projects are structurally better teachers than others, and you can pick them on purpose.

Why the To-Do App Keeps Failing You

The to-do app isn't a bad project because it's cliché. It's a bad project because it's front-loaded with decisions you already know how to make and back-loaded with none you don't. CRUD is CRUD. By your third one, you're practicing the skills you already have while learning nothing about the hard parts of software: state that's genuinely concurrent, failure modes, real users with real opinions.

A good side project has two properties. First, it forces you into territory you haven't mapped. Second, it's small enough to reach a finished state — because the learning lives in the finishing: deployment, edge cases, the boring glue work that tutorials skip.

Seven Projects That Pay Rent in Skills

1. A CLI tool that solves one of your own annoyances. A script that renames files, formats timesheets, or queries your team's Jira. CLIs teach argument parsing, error handling, and distribution — and they're naturally scoped. Bonus: you'll actually use it, which means you'll maintain it, which means you'll learn maintenance.

2. A well-scoped REST or GraphQL API. Pick a domain you know — a workout tracker API, a recipe API — and build the backend only, with auth, pagination, validation, and tests. No UI. The discipline of designing an interface other people could consume teaches more about API design than six frontend apps ever will.

3. A scraper or data pipeline with a real destination. Pull data from a public source, transform it, load it somewhere queryable. This is a huge slice of professional work, and almost nobody practices it voluntarily. You'll hit rate limits, malformed data, and schema drift — the actual texture of engineering.

4. Contribute to an open source tool you already use. Not a drive-by typo fix — get one real feature or bug fix merged into a library in your stack. You'll read unfamiliar code, work within someone else's conventions, and navigate review. That's a direct rehearsal for senior-level work.

5. A Discord bot or Slack integration for a community you're in. Small surface area, real users, immediate feedback. You'll learn webhooks, async patterns, and the humbling experience of shipping to people who file bugs within the hour.

6. Rebuild a fundamental thing, badly, on purpose. Write a tiny HTTP server, a regex engine, a JSON parser, a database with one table. Not to replace anything — to demystify it. An afternoon building a toy database permanently upgrades how you think about indexes and queries.

7. A static site or dashboard for something you track. Personal site, habit dashboard, fantasy football stats. Forces you through the full ship cycle — deploy, domain, DNS, the works — with stakes low enough that you'll actually finish.

Three Projects That Just Teach You to Start Over

1. The startup-shaped app. Anything with user accounts, payments, and a marketing plan attached. The scope is a black hole, and the failure mode is demoralizing because it feels personal. Build the engine, not the company.

2. The framework-chasing rebuild. Rewriting last year's project in the framework of the month. You'll learn a new syntax and zero new fundamentals — and in six months you'll be tempted to do it again. Frameworks are commodities; the concepts underneath them are career equity.

3. The everything-at-once platform. "It'll have a mobile app, a web app, an ML recommendation engine, and real-time chat." No it won't. Projects with five subsystems never reach the finish line where the real learning lives.

The Sizing Test

Before you write a line of code, run your idea through three questions:

• Can I ship a useful v1 in under 20 hours of work? If not, cut scope until the answer is yes.
• Will I touch it again after shipping? Maintenance is where side projects turn into real engineering experience.
• Does it use a skill from my day job's adjacency? Projects that transfer — the scraper that makes you better at your backend work, the CLI that sharpens your scripting — compound. Projects in a totally unrelated silo mostly don't.

One last thing: finish ugly. A deployed, slightly janky tool you use every week beats an elegant repository that died at 60%. Ship it, write a short post about what you learned — communities like CHTree are good for exactly this — and let the next project be a little more ambitious.

That's how a portfolio actually gets built. Not in a heroic month, but in a series of small things that survived your calendar.