Seven small habits that made my side projects actually finish

Like most people who build things, I have abandoned projects. These are habits that help me finish.

They're my experience, not a universal law, but each one has a concrete reason behind it. Let's go through all seven, with something you can try this week for each.

1. Write a one-line goal

If I can't say what the project does in one sentence, I'm not ready to code it. A good one-liner names who it's for and what changes for them.

For example, a goal for CardBridge could read: "Let someone buy a discounted item using a card they don't own, without either party having to trust the other with money." One sentence, a real problem, a clear promise.

Try it: Write your goal on a sticky note and stick it where you code.

2. Ship an ugly version first

Polish later, if ever. An ugly working version teaches you more than a beautiful half-working one, because it shows you the real problems earlier.

I try to get a project end to end, with the most basic UI, before touching spacing, animations or colours.

Try it: Set a rule that you can't style anything until the main flow works.

3. Keep a "not now" list

Great ideas will arrive halfway through. If each one goes straight into the code, the project never finishes. A "not now" list lets you honour the idea without acting on it.

That's how scope stays under control: the idea is kept, just not acted on yet.

Try it: Create a file called NOT_NOW.md at the start of every project.

4. Deploy early

A live URL changes how seriously I take a project. A project on localhost is easy to abandon; a project someone can click is not.

Deploying early also surfaces problems you can't see locally. (See Day 3: my deploy broke for two weeks because of a difference between my laptop and the host. Finding that on day one would have been far cheaper.)

Try it: Deploy the skeleton on day one, before it does anything useful.

5. Write the README as I go

Future me forgets everything. The reasoning behind a decision is the first thing to evaporate.

For my projects, the habit became writing case studies with a fixed structure: the problem, the approach, key decisions, what broke and how I fixed it, and limits. Writing "limits" is the part that keeps me honest.

Try it: After each work session, add three lines: what I did, what's next, what's stuck.

6. Stop at a natural pause

Quit mid-function and leave a TODO comment, so tomorrow starts easy. Starting is the hardest part of any session.

If you stop at a clean finish, tomorrow begins with a blank page. If you stop mid-thought with a note, tomorrow begins with momentum.

// TODO: next, handle the case where the dispute window has already closed.
// Test idea: transition DISPUTED -> RELEASED must fail for a non-admin.

Try it: End your session by writing the first line of tomorrow's work.

7. Make it for someone

Even one real user beats a hypothetical thousand. A real person gives you real questions. A hypothetical crowd gives you endless imaginary requirements.

This is also a defence against over-engineering: when you know the one person who'll use it, you know which features don't matter.

Try it: Name a specific person who'd use your project and show them the ugly version.

The one I'd start with

If you could only adopt one: number 4. Seeing a project online, even rough, raises the stakes. A localhost project is easy to abandon.

A quick self-audit

Rate yourself honestly, 0 to 2, on each habit:

Anything scored 0 is your next experiment. Don't try to fix all seven at once. One habit, two weeks, then add another.

What these don't fix

Habits won't rescue a project nobody needs, and they won't replace skill. They only reduce the chance that a good idea dies from friction.

Your mileage will vary, and some of these may not suit how you work.

A project kickoff template

Copy this into a PROJECT.md at the start of any project. It bakes in several of the habits above.

# Project name

## One-line goal
(Who is it for, and what changes for them?)

## Smallest useful version
(What can I ship in a weekend?)

## Not now
- idea 1
- idea 2

## Deploy plan
(Where will the skeleton live on day one?)

## Done means
- [ ] live URL
- [ ] README with setup steps
- [ ] one real person has tried it

## Log
- YYYY-MM-DD: what I did / what's next / what's stuck

Common failure patterns and fixes

How to restart a project you abandoned

• Read your last log entry. If there isn't one, write down what you remember.
• Run it. Often the first obstacle is that it no longer builds. Fix that first.
• Shrink the goal to something finishable in two sessions.
• Schedule the sessions. Put them on the calendar.
• Decide what "done" means, then do only that.

A note on finishing versus shipping

Shipping means it's available to someone. Finishing means you're happy with it. The two are different and easy to confuse.

My template is an example: built and verified, but not yet shipped, because a last step is outstanding. I'd rather ship something imperfect than finish something nobody sees.

Measuring progress without fooling yourself

Instead of "hours worked", track things that exist: a deployed URL, a passing test, a written paragraph, a merged branch. They're harder to fake and make a better record over time.

Which of these do you already do? What would you add as number eight?