What I Actually Write In A Weekend
How I scope a side project so it survives past the first deploy.
Every side project I have ever abandoned died the same way. Not because the idea was bad, and not because I ran out of time. It died because I tried to build the whole thing before letting anyone use one part of it.
The mistake I kept making
I would pick a scope, sit down on a Saturday, and try to finish it. Auth, database, API, dashboard, deployment. Five things that each look small and together look like a month of work. By Sunday evening I had a login form and a database schema and nothing anyone could actually see. The motivation drained out somewhere around hour eight, and I never went back.
What changed
The projects that survived all did the same thing. I picked one path through the feature list and made that path work end to end before touching anything else.
For a job board, that meant: a list of cards, read from a real database, served on a real URL. Not search, not applications, not messaging. Just the list.
// The whole first slice.
const jobs = await db.job.findMany({ orderBy: { createdAt: "desc" } });
return <JobList jobs={jobs} />;
Once that was live, every next feature had something to hang off. Search was an
input and a where clause. Applications were a row and a status. None of it felt
like starting over, because nothing had been thrown away.
The rules I use now
- One path, not one feature. "A user can sign up" is a feature. "A user can sign up and create a project and see it on a dashboard" is a path. Ship the path.
- Real data from day one. SQLite or Postgres, not an array in a module. The bugs that matter only appear once data has to survive a refresh.
- Deploy before it is ready. An ugly page on a real URL teaches you more in an hour than a beautiful page on localhost teaches you in a week.
- Write the README on day one. If you cannot explain what it is in three sentences, the scope is wrong. This is the check I skipped every time.
What I gave up
Responsive design. Dark mode. Tests. A landing page with actual copy. All of that came later, and it came easily, because by then something existed to be polished.
The counter-intuitive part is that cutting scope early made the final product better. I stopped adding features nobody asked for, because I could finally see which ones people actually used.
Where this leaves me
I still abandon things. The difference is that abandoned things now have a URL and a README, so they are not lost. Some of them I pick up a year later with a clearer head, and that is usually when they turn into something worth keeping.
Related Posts
The Best Advice I Got Was About Deleting Things
The most useful thing a mentor said to me was not a technique. It was a question.
3 min readCraftCareerHabitsReading Code Is The Actual Job
Most of programming is not writing code. It is working out what code you did not write.
3 min readCraftDebuggingReading