The Last Ten Per Cent: A Done Checklist for Side Projects

There is an old joke among builders that the first ninety per cent of a job takes ninety per cent of the time, and the last ten per cent takes the other ninety per cent. It is not quite arithmetic, but every maker knows the feeling. The main idea works. The demo is lovely. And then weeks go by in small, fiddly tasks that nobody will thank you for.

That last stretch is where a demo becomes something you can share. This guide gives you a done checklist: a list of conditions that must be true before you call a side project finished. Writing it down turns an open-ended polishing urge into a finite job.

What "done" means

In project work, a definition of done is a shared list of criteria that a piece of work must meet before it counts as complete. It exists to prevent vague finishing, where one person thinks something is done and another finds it half-built.

For a solo maker, the same idea applies to yourself. It protects you from two opposite problems.

• Never finishing, because there is always one more thing.
• Declaring victory too early, and shipping something that embarrasses you.

A written list sits between them. It says: when these are true, you may stop.

Scale the list to the project

Not every project needs every item. A toy for friends needs less than a tool that strangers rely on. Decide your level.

Level one: a toy. Works for the main case, has a short description and does no harm.

Level two: a shared tool. Level one plus reasonable errors, basic docs, a contact route and sensible limits.

Level three: something people depend on. Levels one and two plus tests, backups, privacy care, accessibility and a plan for problems.

Write the level at the top of your list, and choose the items to match.

The checklist, section by section

The first run

The first ten minutes decide most opinions.

• A stranger can find the project and understand what it is within seconds.
• The main path works from a clean start, on a clean machine or browser, with no hidden steps.
• It works on a phone, if it is a web project.
• The first screen has one clear next step.
• Sample data or an example is available to try.
• Nothing requires an account unless it must.

Test this by following your own instructions with fresh eyes, or better, by watching a friend.

The main job

• The core task works reliably, in several cases, not just your favourite.
• Typical inputs produce correct outputs.
• Unusual but plausible inputs do not break it: empty fields, very long text, special characters, large files.
• Results are checked against something you trust.

Software testing, the process of evaluating a program to find defects, is as much about trying to break things as confirming they work. Spend part of your time on the breaking.

Errors and edge cases

• Errors are caught and explained in plain words.
• The product never loses a user's work silently.
• Messages say what happened and what to do.
• Nothing crashes on bad input.
• Time-outs and slow responses are handled.
• If something external fails, such as a service you depend on, the project says so instead of hanging.

Documentation

• A short README or help page: what it is, how to start, what it does not do.
• The licence is stated.
• Known limits are listed.
• A way to report a problem is given.
• A changelog or version note exists, even if it has one entry.

Safety and cost

• If the project calls a paid service, a usage cap or alert is set.
• Rate limits stop one visitor from overloading it.
• Secrets such as keys and passwords are not in the code or the repository.
• Dependencies are not wildly out of date.
• Backups exist for anything that matters.
• You know how to switch it off.

Privacy and data

The Information Commissioner's Office publishes guidance for small organisations on handling personal data. A few basics apply to any project.

• Collect only what you need.
• Say what you store, and for how long.
• Do not log sensitive information by accident.
• Provide a way to delete data on request, or say plainly if you keep nothing.
• If you use analytics or cookies, be open about it and follow the rules where you are.

Accessibility

• Text is readable, with enough contrast.
• Everything works with a keyboard.
• Images have text descriptions.
• Forms have clear labels.
• The page works at a larger text size.

The Web Content Accessibility Guidelines offer a framework. For a small project, meeting the basics is a good and achievable goal, and helps everyone.

Speed

• The page or tool loads quickly on an ordinary connection.
• Images are compressed.
• Nothing jumps around as it loads.

Web performance measures such as Core Web Vitals describe loading, responsiveness and visual stability, and they are a useful guide for what matters to real users.

Contact and support

• A way to reach you.
• A stated reply expectation.
• A place for bug reports.

Naming and presentation

• The name is consistent everywhere.
• The description is plain and true.
• A screenshot or clip shows the project at its best, with realistic data.
• Typos are fixed.
• Links work.

The finish

• You have a place to share it: a page, a listing, a post.
• You have a short plan for the first week.
• You have written what you will not do.
• You have a date.

How to use the list

1. Write it before the last stretch, not during. Ideally, at the start of the project, so you know the destination.
2. Pick the level and delete items that do not apply.
3. Tick items honestly. Test, do not assume.
4. Time-box each item. If one expands, ask whether it belongs.
5. Ship when it is complete. Not when it feels perfect.
6. Move new ideas to the later list.

If an item is hard, break it into pieces. If it is optional, say why you are leaving it out and note it for next time.

Handling the urge to polish

There is a point at which polishing stops serving users and starts serving anxiety. Signs:

• You are changing colours for the fifth time.
• You are rewriting working code for elegance.
• You keep adding small features.
• You avoid the launch.

When you notice this, look at the checklist. If all items are ticked, you are done. Put the polish on the later list and share it.

Get a second pair of eyes

You cannot see your own blind spots.

• Ask one person to follow your README from scratch and tell you where they tripped.
• Ask another to try to break it.
• Ask a third to read your description and say what they think it does.

Thank them, fix what matters and ship.

After you tick the last box

Take a moment. Make a cup of tea. Write a line in your logbook. Then do the thing you have been postponing: tell people. A project not shared is a project not finished.

A worked example

A maker builds a tool that converts a list of tasks into a printable weekly planner. The main idea worked in a day. Over the next week she works through her level-two checklist.

First run: she tests on a phone and finds the button hidden below the fold; she moves it. Main job: she tries lists with accented characters and finds a bug; she fixes it. Errors: an empty list shows a blank page; she adds a message. Docs: she writes five lines and a licence. Safety: nothing paid is called, so none needed; she adds a size limit. Privacy: nothing is stored, and she says so. Accessibility: she increases contrast and adds labels. Contact: an email address. Finish: a page, a listing and a date.

The list took three evenings, far longer than the planner did. It also turned a clever demo into something she was proud to share.

Common mistakes

• Writing the list after the fact.
• Ticking without testing.
• Never finishing.
• Declaring victory too soon.
• Skipping safety and privacy because it is small.
• Polishing instead of sharing.
• Going alone with no outside eyes.

On this site

The submit page lets you list a finished project, the launches page shows what other makers have shipped, the categories page helps you find a shelf and the contact page gets you through to support. The blog has more guides for makers.

Make the checklist reusable

Once you have a list that works, keep it. Store it as a plain file called something like done-checklist, and copy it into each new project at the start. Adjust the level and strike out what does not apply. After three projects you will have a version tuned to the way you work, with the items you tend to forget in bold. It becomes a quiet piece of equipment, like a favourite spirit level, that lives on the bench and saves you from the same mistakes.

Share the finish

When you tick the last box, share the list too, if you like. A short note saying what you checked can reassure users and teach other makers. "Tested on a phone, errors explained, no data stored, licence stated" is a pleasing sentence to read on a project page, and it signals care without a single adjective.

The short version

The last ten per cent is made of small, unglamorous tasks. Write a done checklist covering the first run, the main job, errors, documentation, safety and cost, privacy, accessibility, speed, contact and presentation. Scale it to the project, tick honestly, get a second pair of eyes, put polish on the later list and ship when the list is complete. Done is a decision you can defend.