A weekend gets you a working version, not a product

Yes, you can build a working application in a weekend. I have done it repeatedly and it is not a trick.

But I have also written about the period where I created eight repositories in eleven days and abandoned six of them, so I am obliged to put the qualifier before the method rather than after it: a weekend gets you a working version. It does not get you a finished product. Those are separated by several weeks of work that nobody writes articles about, and confusing the two is the most common mistake in this entire genre.

With that said, the working version is genuinely valuable, and getting to it reliably is a skill.

#Friday: decide the one thing

The constraint is never build speed. It is scope, and scope is decided before anything is built or it is not decided at all.

Write down, in one sentence, the single thing the product does. Not the category it is in — the specific action a person takes and the specific result. If the sentence contains "and", you have two weekends of work and will finish neither.

Then write the second list, which matters more: everything it will not do. Explicitly, in writing, so that at eleven o'clock on Saturday night when a feature seems obviously necessary, you have a note from a calmer person telling you it is not.

#Then research, even now

It feels absurd to spend an hour reading when you have two days. Spend the hour.

Whatever the unfamiliar part is — an API you have not used, a platform capability you are guessing at, a permission model you have assumed — read the actual documentation for it before you prompt. The failure this prevents is not a bug. It is building the whole thing on an assumption that turns out to be wrong on Sunday afternoon, at which point the weekend is gone and there is nothing to show.

In a normal project research runs to something like a tenth or a fifth of the time. Compressing it to a single hour is the compromise a weekend demands; removing it is not.

#Saturday: build, then review, then repeat

One long, specific opening prompt rather than a conversation that gradually reveals what you want. Context, the goal as an outcome, an example of the shape you expect, and the constraints — particularly what it must not do.

Then the loop, which is the same one I use on everything and does not get suspended because the clock is running:

1. Let it complete a pass.
2. Ask what it had to assume before accepting anything.
3. Read the changes. Every one. No auto-accept.
4. Run it yourself and find the next thing.

People assume the review step is what makes a weekend build impossible. It is what makes it possible. The alternative is discovering on Sunday that Saturday afternoon's work was built on a misunderstanding, and there is no time left to unpick it.

#What gets cut without discussion

• Accounts and sign-in, unless the product is meaningless without them. This alone is often the difference between one weekend and three.
• Settings. Pick sensible defaults. Every option is a branch you now have to test.
• Any admin interface. You are the admin. Use the database.
• The second platform. One. Whichever one you will actually use.
• Edge cases you have not encountered. Handle the ones you hit. The imagined ones are usually imaginary.
• Visual polish beyond coherent. It needs to not look broken. It does not need to be beautiful this weekend.

#What never gets cut, however short the time

This is the short list, and every item is on it for the same reason: it costs minutes now and days later.

#Sunday: use it as a stranger

The last few hours are not for building. Open the thing as though you had never seen it, on a device that is not your development machine, and try to accomplish the one sentence you wrote on Friday.

Write down everything wrong without fixing any of it, because fixing pulls you back into building and the list is more valuable than any individual fix. Then fix the ones that make it unusable, and only those.

#Monday's honest ledger

What you have: a working version of one thing, which you have used yourself, which does not leak anything obvious and does not lie about its own errors. That is a real artefact and it is far more than most ideas ever become.

What you do not have, and should say out loud so you do not fool yourself:

• It has been used by one person, who built it and therefore cannot see it clearly.
• It has been tested on the states you thought of.
• Its security model has been considered, not examined.
• It has no meaningful failure handling beyond the obvious paths.
• It works on the connection speed and device you happen to own.

Closing that list is the difference between a weekend project and a product, and it takes considerably longer than a weekend. Doing that work on one thing is worth more than another six weekends producing another six working versions — which is a lesson I did not learn quickly and paid for in abandoned repositories.