How to ship a product in a month without burning out

A month is not a marketing promise but a consequence of discipline: in four weeks you can do one thing well. The only question is which one, and it is answered before the work starts, not in the last week.

Week 1. One scenario

Pick the single path that must work flawlessly: arrive, understand, send an enquiry. Or: register, upload a file, get a result. Everything off that path is out of the first version — by decision, not "if there is time".

Weeks 2–3. Build with a demo every other day

• Short demos instead of long reports
• Decisions made at the demo and written down there
• Every change checked against the scenario: on the path or not

The most expensive sentence in a project is "while we're here, let's also". It costs exactly one week, every time.

Week 4. Testing and launch

The last week is not for new screens but for making the existing ones survive: phone, slow network, empty states, form errors, mail, analytics. Plus access, backups, and knowing who fixes it if it falls over on a Saturday.

What is almost always deferred

• User accounts, until there are repeat clients
• Fine-grained permissions, while the team is three people
• The second and third language, until the first is validated
• A beautiful admin panel where a table would do

Why the second iteration matters more

The first version answers whether the idea works at all. The answer is almost always "partly", and the value of the month is learning that in a month rather than in six. The money not spent on five deferred features goes into what turned out to matter.

So plan two iterations, not a launch: a month for the first version and two or three weeks for what life shows. That is more honest than a six-month plan that gets rewritten in week three.