Side projects are like gyms - you always pay, but do you go?

By Edmund Adu Asamoah September 7 2025 • 4 min read

Empty gym and a lonely laptop - the side project struggle — Subscriptions are easy. Showing up is hard. The same story for gyms and side projects.

Side projects are like gyms - you always pay, but do you go? I have had seasons where I bought domains like they were protein bars. New stack, new logo, new repo - and then life said nope. What finally worked for me was treating side projects like training: small reps, boring consistency, and a simple program.

Here is a field guide you can copy. It is not about being the most clever person on GitHub. It is about building a tiny thing often enough that it becomes a habit. You can riff on this whether you are an engineer, designer, or just a curious builder.

Weekly slots

2 x 60m

Scope per sprint

One small win

Release cadence

Every 2 weeks

Rule of thumb

Ship over perfect

Tiny scope makes momentum. If a task cannot fit in a one hour session, break it into parts until it can.

A simple program you can actually follow

This is the routine that finally got me shipping. It is simple on purpose and it works with a busy life. Copy it as is or tweak it to your taste.

1) Pick a one page brief

Write a tiny brief: problem, user, one core feature, success metric. If the brief is longer than a page, your scope is probably hungry for a pivot.

Define a real user - even if that user is you.
One success metric - signups, installs, or one smiling teammate.

2) Book two weekly slots

Put two one hour sessions on your calendar. One is for progress, one is for polish. Protective scheduling beats inspiration. If life gets loud, drop to one session but do not cancel both.

Progress slot

Ship one visible change
Commit with a clear message
Leave a todo for next time

Polish slot

Write a short note or readme update
Pay one tiny tech debt
Share a screenshot or short clip

3) Make it observable

Create one place where progress is obvious. A public changelog, a pinned tweet, a Notion page, or a tiny dashboard. If you can see the streak, you will protect it.

What gets logged gets shipped.

4) Design for demo day

Every two weeks, cut a tiny release. Call it v0.0.something. Share a quick demo with one person. Feedback from one real human beats ten hours of guessing.

5) Use constraints as a feature

Pick limits that help you move - one weekend, one API, one table, one screen. Constraints turn perfection into progress.

Relatable truths from the garage lab

Idea lists grow faster than muscles. Delete freely.
A good readme beats a clever name.
Friends who try your app are better than stars you imagine.
Weekend heroics fade. Weeknight habits compound.

A tiny toolkit that helps

A template repo with linting, tests, and a release workflow.
A changelog file you update every session.
A screenshot folder - proof beats memory.
One page project brief - problem, user, feature, metric.

Copy any part of this. Swap tools to what you love. The point is not the stack. The point is the habit.

Four weeks to prove it

Pick one idea you can love for a month. Write a one page brief. Book two weekly slots. Ship a tiny release every two weeks. Share proof. That is the whole challenge. By week four you will either have a small thing you can show, or a clean lesson you can reuse.

Start today with a 60 minute progress slot - pick one visible change.
Open a changelog and update it every session - one line is enough.
On day 14, demo to one human - ship the next tiny thing based on feedback.

Tell me your idea Want coaching for 4 weeks?

0 likes

Rate this post:

Not rated