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

1. Read your last log entry. If there isn't one, write down what you remember.
2. Run it. Often the first obstacle is that it no longer builds. Fix that first.
3. Shrink the goal to something finishable in two sessions.
4. Schedule the sessions. Put them on the calendar.
5. 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?