Ship Your First Side Project
Ship one small, complete, genuinely usable project that other people can find and use.
This is a starting point — make it yours
Use this goal to build your own roadmap — tailored to you and starting fresh.
Scope it small enough to finish
The scoping is the project. Almost every abandoned side project was too big on day one, and no amount of discipline later recovers from that.
Write the one-sentence version~1h
"X lets Y do Z." If it needs two sentences or an 'and', it is two projects. Write it down where you'll see it — it is the thing you check every proposed feature against.
Done when: one sentence exists that someone else could repeat back accurately.
Write the not-in-v1 list~1h
Accounts, teams, billing, dark mode, mobile app, an API, settings. List everything you can imagine wanting and explicitly exclude it. This list is what you point at in week five when you want to build something interesting instead of finishing.
Done when: at least eight excluded features are written down.
Find three people who would use it~2h
Real people, named, who you can actually message. Describe it and listen to what they ask — often they want something adjacent and simpler. Building for nobody in particular is how projects become unfinishable.
Done when: three names are written down and at least one has responded.
Choose boring technology on purpose~1h
The stack you already know, hosting you have used, a database you can debug at midnight. A side project has no budget for learning three new tools at once — the project is the interesting part.
Done when: the stack is written down and you have used every part of it before.
The ugly end-to-end slice
One path through the whole system, working, before anything is good. This is deliberately not the foundations-first approach, and it is the single highest-value structural decision here.
Get 'hello world' deployed to production on day one~4h
Before any features. An empty page on a real URL. Deployment is where the unpleasant surprises live, and finding them in week eight with a finished app is far worse than finding them now.
Done when: a real URL serves your page and you can redeploy with one command.
Build the single core action, badly~10h
The one thing the project exists to do, end to end. No styling, no validation, no edge cases — just the main path working from input to stored result to visible output.
Done when: you can perform the core action on the deployed site.
Use it yourself for a week~3h
Actually use it for its purpose, daily. You will find out in a week what a month of planning wouldn't have told you — usually that one assumed step is wrong or unnecessary.
Done when: seven days of real use have happened and you have a written list of what annoyed you.
Cut one planned feature based on that week~1h
Something on the v1 list will have turned out not to matter. Removing it now is the cheapest it will ever be, and finishing early beats every feature you could add.
Done when: one feature has moved from v1 to the not-in-v1 list.
Make it good enough for strangers
Not perfect. Good enough that someone who doesn't know you and doesn't care about your project can use it without help.
Handle the three ways a stranger will break it~5h
Empty input, enormous input, and refreshing halfway through. You do not need comprehensive validation; you need it not to show a stack trace to the first person who tries it.
Done when: all three produce a sensible message rather than an error page.
Make it look deliberate rather than designed~8h
Consistent spacing, one font, one accent colour, readable line lengths, works on a phone. Restraint beats ambition here — a plain interface that is consistent reads as competent.
Done when: it looks intentional on both a laptop and a phone.
Watch one person use it without helping them~2h
Sit them down, give them the URL and one sentence of context, then say nothing. Every instinct will be to explain. Don't — where they hesitate is your actual bug list.
Done when: one session has happened and you have three specific things to fix.
Fix what that session found, and nothing else~6h
Only the confusions you observed. Not the refactor you have been wanting to do, not the feature you thought of while watching.
Done when: the three things are fixed and deployed.
Ship it properly
A project nobody has seen isn't finished. This phase has hours attached because it is real work, not an afterthought.
Write a README that explains it in thirty seconds~3h
What it does, who it is for, a screenshot, how to run it locally. The screenshot matters more than the prose — most people decide from it alone.
Done when: someone who has never seen the project can say what it does after thirty seconds on the page.
Put it in front of people~2h
Post it where your three users hang out — a subreddit, a Discord, a course group chat, your own social feed. Say what it does and what you would like feedback on. Expect a modest response; that is normal and is not a verdict on the work.
Done when: it has been posted in at least two places.
Handle the first real user's confusion~4h
Someone will misunderstand something you thought was obvious. Fix it the same week — the gap between shipping and responding is what makes a project look alive.
Done when: one piece of external feedback has been acted on and deployed.
Write down what you'd do differently~2h
A short honest post-mortem: what took longer than expected, what you cut and whether you were right to, what you would keep from this process. This is the part that makes the second project faster, and it is the part everybody skips.
Done when: the note exists and names at least one decision you got wrong.