Scoping a Side Project So It Actually Ships

Every maker has a shelf of half-finished things. A box with one wall built. An app with a lovely login screen and nothing behind it. A drawing for a table that was going to be a bookcase and then a whole room. It is not laziness. It is arithmetic. The project was bigger than the hours.

Scoping is the bench skill that fixes this. It means deciding, before you cut anything, how big the thing will be and where it ends. This guide shows how to scope a side project so that it ships, with a method you can use on a Saturday morning.

Why side projects stall

A side project lives in leftover time: evenings, weekends, the odd free afternoon. That time is small and unpredictable. Against it you set a project that, in your head, is exciting and large.

The gap shows up as a pattern.

1. The start is wonderful. Ideas flow. You build the interesting parts.
2. The middle drags. The boring parts appear: sign-in, settings, error cases, documentation.
3. New ideas arrive and tempt you.
4. The finish line moves.
5. A busy week breaks the rhythm, and returning feels like starting over.
6. The project joins the shelf.

Project management writing has a name for the gradual growth of requirements beyond the original plan: scope creep. It is the quiet enemy of every side project, because nobody is there to say no except you.

The finish line first

Before you touch a tool, write down what "done" means. Not "finished perfectly" but "ready for a stranger to use".

A good finish line is:

• Concrete. "A page where someone can paste a list and get a tidy version back."
• Observable. You can tell when it is true.
• Small. It fits in the time you have.
• User-centred. It describes what someone can do, not what you built.

Write it on a card and put it where you work. When you are tempted to add something, look at the card.

Count your hours honestly

Open your calendar and count the hours you actually spent on the project last month. Not the hours you meant to. Multiply by the number of weeks you can sustain it. That is your budget.

Say you have six hours a week for six weeks. That is thirty-six hours. A realistic project fits in about two-thirds of that, because things always take longer. So plan for about twenty-four hours of work.

Timeboxing is the practice of fixing the time you will spend on something, and then fitting the work into it, instead of letting the work decide the time. It suits side projects well. Decide the box first, then ask what fits.

Make a list and then cut it

Write down everything the project might include. Do not filter. Then sort.

Must. Without this, the first user gets no value.

Should. Makes it better, but they could manage without.

Could. Pleasant extras.

Not now. Everything else.

The sorting method has a respectable ancestor: the MoSCoW approach divides requirements into must have, should have, could have and will not have this time. The last bucket is the one makers forget, and it is the most useful. Giving ideas a place to wait means you do not have to pretend you have abandoned them.

Now cut. Keep only the musts. If the musts alone do not fit your budget, cut the musts, too, until they do. The question to ask is: "What is the smallest thing a stranger could use and be glad of?"

This is the idea behind a minimum viable product: a version with just enough features to be usable by early customers, who can then give feedback. For a side project, it is a way of taking the finish line seriously.

Shrink by simplifying, not by hiding

There are several honest ways to make a project smaller.

Narrow the audience. Serve one kind of person first. A tool for "everyone" has a lot of cases. A tool for hobby beekeepers has fewer.

Narrow the platform. One browser, one device, one language, one country.

Narrow the features. Do one job.

Narrow the data. Support one file type, one format, one size.

Replace building with borrowing. Use an existing service for sign-in, payments, email or storage, instead of making your own.

Replace automation with doing it by hand. For the first ten users, you can do some jobs manually.

Delay polish. Make it work first, make it neat second.

Cut the settings. Every option is a decision, a test case and a piece of documentation.

Slice vertically

When you plan the work, slice it so that each slice does something end to end, however small.

Weak plan: Week one, the database. Week two, the logic. Week three, the interface. Nothing works until week three, and if you run out of time, you have nothing usable.

Better plan: Week one, a page where you paste text and see a result, even a crude one. Week two, make the result useful. Week three, add saving. At the end of each week, there is something that works.

If you run out of time, you still have a smaller thing that ships.

Set checkpoints

A long project needs rest stops.

• A midpoint check. Halfway through the time, ask: am I on track? If not, cut more.
• A demo to someone. Show it to a person, early. They will see what you cannot.
• A date. Pick a shipping date and tell someone. Public dates are more powerful than private ones.

If you miss a checkpoint, cut scope, not the date. The date is what keeps the project alive.

Guard against creep

New ideas will arrive. Welcome them and file them.

• A "later" list. Write every new idea there, with the date. Do not act on it.
• A cooling rule. Wait a week before adding anything to the plan.
• A trade rule. If you add something, remove something of the same size.
• A question. "Does the first user need this to get value?" If no, it waits.

You will find that most ideas lose their urgency after a week. A few survive, and those are the ones worth building next.

Know what you will not build

Say it out loud, or write it on the card: "This will not have accounts. This will not have a mobile app. This will not have an admin panel."

Naming exclusions turns a vague boundary into a firm one, and it helps when someone asks for a feature. You can say, kindly, that it is on the later list.

Ship something real

At the end, ship it. Real means:

• Someone other than you can reach it.
• It does the main job.
• You can describe it in a sentence.
• It does not break in the obvious ways.
• You have told at least a few people.

It does not mean perfect. Perfection is a way of never shipping.

Put it somewhere people can find it. A listing on a launch platform gives a small project a public page. The submit page here is one place to do that. Tell people honestly what it is and what is missing.

After shipping

The moment after shipping is when scoping pays off. You now have a real thing in the world and real feedback.

• Watch what people do. It is rarely what you predicted.
• Fix the worst problem first.
• Take the best idea from your later list, and only then.
• Decide your next small finish line.

A series of small shipped things beats one large unfinished thing every time.

A worked example

A maker wants to build a recipe-sharing site with accounts, comments, ratings, collections, a mobile app and a meal planner. She has about thirty hours.

She writes the finish line: "A page where I can paste a recipe and get a clean, printable card with a link I can share." She sorts: musts are paste, tidy and share link; shoulds are an image and a scaling tool; coulds are accounts and comments; not now are ratings, collections, the app and the planner.

She plans vertical slices: first a paste box that shows the text back; then a tidy layout; then a share link. She sets a shipping date three weekends away and tells a friend. At the midpoint she has a working paste-and-tidy page. She cuts the image feature. On the date she ships, with the print card and the link. Twelve strangers use it in the first week. Three ask for scaling. She adds that next.

The big dream is still on the later list. The small thing is real.

Common mistakes

• No finish line.
• Planning from enthusiasm, not hours.
• Building the foundations first.
• Letting the later list leak into the plan.
• Moving the date instead of cutting.
• Waiting for polish.
• Telling nobody.

On this site

The submit page lets you list a finished project so people can find and try it, the launches page shows what other makers have shipped, and the categories page helps you choose a shelf. The founders page introduces the people behind this place, and the blog has more guides for makers.

The short version

Write the finish line first, count your real hours, sort features into must, should, could and not now, cut to the musts, shrink by narrowing audience and features, slice vertically so something works each week, set checkpoints and a public date, file new ideas on a later list and ship something real. A small thing that exists beats a big thing that does not.