02 - Launching a Side Project: Pre-Mortem Checklist

The cost of discovering the risks after launch

Launching a side project without having looked for the ways it can fail means discovering them one at a time, with customers watching and your energy already spent. A pre-mortem reverses the order: before launch you place yourself in the future where the project went badly, write why, and turn that story into a few actions with a date. It takes a few hours, you can do it alone and it genuinely changes decisions, because it moves attention from "how it goes well" to "where it gives way".

The technique has a precise source: Gary Klein describes it in the article "Performing a Project Premortem", published in Harvard Business Review in September 2007. In the magazine's summary, the team members assume that the project they are planning has just failed, as so many projects do, and then generate plausible reasons for the failure. It is not pessimism: it is a way of giving others and yourself permission to say what you would otherwise keep quiet so as not to look like the one holding things back.

How it works, step by step

The sequence matters, because each step depends on the previous one: if you skip writing the story, the risks you list are the ones you already had in your head. That is why the steps must be done in order.

1. Set the date of the failure. "It is June, the product has been online for six months and has no paying customers".
2. Write the story in the first person, in two or three paragraphs, with specific causes and not "nobody was interested".
3. Extract the risks from that story, one per line, without judging them.
4. Give each risk a probability and an impact, then sort by the product of the two.
5. For the top three write an action and a date. The others stay under observation.

The step most people skip is the second: writing the story forces you to choose a cause, and when you choose you notice what you really know. The fourth step avoids the endless list: with a scale from 1 to 5 and a product, you get an order, and an order is already a decision. The last step is the one that decides whether the pre-mortem is useful: a risk without an action and a date is an opinion.

An example story, declared invented

To see the difference between a vague cause and a specific one, here is an example built on purpose, with no sources and no real people. Vague version: "The product did not work because the market was not ready". Specific version: "I spent four months building a tool for accountants, I talked to three of them and all said it was useful, but none had a budget and the price of 29 euros a month had been chosen at random; at the end of the beta nobody entered a card". The second story names three things you can check beforehand: the number of interviews, the question about budget and the proof of payment. The first names nothing.

Six scenarios that deserve a line in the register

There is no universal list of causes of failure, and the percentages that circulate online without a source should not be repeated. What follows are six scenarios common in small projects, chosen because each has a check you can do in one evening.

Nobody pays

The strongest market signal is a payment, even a small, upfront one. A compliment costs the person giving it less than a euro and says nothing about price. A practical threshold is to ask five beta people for a payment; it is a working rule, not a standard, and if none of them pays you have valuable information before spending more months.

The service stops without your knowing

An external check that calls the site every minute and alerts you on your phone takes a few minutes to set up and removes a whole category of surprises. Without it, you discover the outage from an email from an angry customer, usually the next morning.

You lose data

A backup you have never restored is a hope. Put a restore test on the action list, and keep it as the first item of the technical list: the article on low-cost hosting explains it.

You get tax or VAT wrong

It is the risk whose damage is hardest to see in advance: a mistake on tax rules is discovered months later. The action is to talk to an accountant (commercialista) before selling, bringing written questions. In the article on the regime forfettario you will find the rules and the official sources.

Support wears you down

Every customer writes, and a twenty-minute reply repeated fifty times is almost seventeen hours. Five template replies written before launch cut the time a lot; the article on solo support shows how to organize them.

You lose interest

The most human risk: after a few months without results you stop working on it. The effective action is a public deadline, or one shared with a person who will ask you to account for it, and a project size so small that you can make visible progress every week.

The risk register, in a program

The fourth step (probability times impact, then sorting) is mechanical and is best left to a program, so you rerun it when a number changes. The listing below is a declared example: the five risks and the scores are invented to show the mechanism, replace them with your own. The function punteggio multiplies probability and impact, sorted sorts in descending order and, being stable, on equal scores keeps the order in which you wrote the risks. Only the top three get a deadline, because more than three open actions do not get done.

# Risk register of a pre-mortem: probability and impact from 1 to 5,
# chosen by you AFTER writing the failure story.
# The risks below are a declared example, not market data.
rischi = [
    # (risk, probability, impact, concrete action, deadline)
    ("nobody pays after the beta", 4, 5, "ask 5 beta testers for an upfront payment", "2027-02-15"),
    ("the server goes down at night and I do not know", 3, 3, "set up an external check with a phone alert", "2027-01-31"),
    ("I get the VAT wrong on a customer from another country", 3, 4, "ask the accountant how to treat EU sales", "2027-01-20"),
    ("support emails eat my evenings", 3, 3, "write 5 template replies before launch", "2027-02-01"),
    ("I lose the database without a recent backup", 2, 5, "nightly backup off the server and a tested restore", "2027-01-25"),
]

def punteggio(r):
    return r[1] * r[2]

# sorted is stable: on equal scores the order in which you wrote them is kept
ordinati = sorted(rischi, key=punteggio, reverse=True)
for posizione, r in enumerate(ordinati, start=1):
    marcatore = "ACTION BY %s" % r[4] if posizione <= 3 else "monitor"
    print(f"{posizione}. [{punteggio(r):>2}] {r[0]} -> {marcatore}: {r[3]}")

# Output:
# 1. [20] nobody pays after the beta -> ACTION BY 2027-02-15: ask 5 beta testers for an upfront payment
# 2. [12] I get the VAT wrong on a customer from another country -> ACTION BY 2027-01-20: ask the accountant how to treat EU sales
# 3. [10] I lose the database without a recent backup -> ACTION BY 2027-01-25: nightly backup off the server and a tested restore
# 4. [ 9] the server goes down at night and I do not know -> monitor: set up an external check with a phone alert
# 5. [ 9] support emails eat my evenings -> monitor: write 5 template replies before launch

Look at the output: the "nobody pays" risk scores 20 out of 25 and is at the top, while the server outage, which seems the most "technical", scores 9 and ranks fourth. That is exactly why the exercise is done: the next evening you would tend to fix the server, because it is more fun, and the score tells you that the urgent thing is to ask for a payment. The listing does not depend on date, chance or set ordering, and the result is identical on every run. The limit is that the numbers remain subjective: the program sorts your estimates, it does not correct them.

Pre-launch checks with a rule behind them

Some items on the checklist are not opinions, and it pays to recognize them because forgetting them has consequences. You find three of them in the official texts I consulted on 2026-11-13, and I report them with the exact reference, without turning them into legal advice.

• Privacy notice. Article 13 of Regulation (EU) 2016/679 (the GDPR) provides that the controller supplies the data subject, at the time when personal data are obtained, with, among other things, the identity and the contact details of the controller, the purposes of the processing and its legal basis.
• Personal data breach. Article 33 of the same regulation provides for notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk.
• Consumer withdrawal. The Italian Consumer Code (Codice del consumo, legislative decree 206/2005) in article 52 gives consumers fourteen days to withdraw from distance contracts, and article 59, letter o), provides an exception for digital content not supplied on a tangible medium under precise conditions, including the consumer's express consent to the start of performance and the acknowledgement that the right of withdrawal is lost.

These are three different obligations with the same practical consequence: they must be built into the product before launch, not added after the first report. The notice is a page, the notification a written procedure whose location you need to know, and withdrawal requires a box to tick in the payment. For the other cases you need a professional: this article tells you where to look, not what to do in your case. For the details on checkout go to the article on payments with Stripe.

Three mistakes that ruin the pre-mortem

The most common mistake is defending the project while pretending to attack it: if you catch yourself writing "but my product is different", change perspective and imagine having to explain the failure to a friend who gave you money. The second is listing generic risks: "marketing does not work" leads to no action, while "after three articles nobody searches for the word I chose" does. The third is writing actions with no date and no measure of completion: "do marketing" is never completed, "publish three articles by 20 March and check the impressions" is.

In reading order, after the pre-mortem it makes sense to move on to the regime forfettario and then to how to read success stories without being led by survivorship bias. The starting stack is in the first article of the series.

Frequently asked questions

Does a pre-mortem work if I work alone?

Yes, it loses the advantage of the group but keeps that of writing. After writing the story, have one or two people you trust read it and ask them for a risk you left out: a reading from outside finds what you took for granted.

How long does it take?

A reasonable estimate, not measured, is a couple of hours for the first session between story, list of risks and scoring. The time depends on the project: a tool with payments and personal data takes more than a static page.

What if the pre-mortem tells me not to launch?

You have gained months. A very likely and very serious risk without a credible action is a valid reason to shrink the project, change audience or stop. The failure already written on paper costs one evening, the real one costs your time.

What you can do now

You can run a pre-mortem in five steps, write a failure story with specific causes, turn it into a register sorted by probability and impact, and tell apart the checks that have a rule behind them (privacy, breach notification, withdrawal) from those that are your own choices.