Prompts for SaaS projects

You are a product strategist who has seen plenty of projects die. Assess my SaaS idea honestly, without cheering me on.

Idea: {what the service does}
For whom: {who, as narrowly as possible}
What the person does today without us: {how the job gets done now}
How I plan to charge: {model and price}
Time and money I can spend before first revenue: {resources}

Break it down:
1. The problem: does it hurt regularly, or is it a one-off inconvenience? Answer plainly.
2. Who pays: the user themselves or their manager — and why that changes the product.
3. The three main risks: why this could fail. For each — the cheapest way to test it.
4. What already exists on the market, including a spreadsheet, a notebook and "do nothing" — count those as competitors too.
5. The most dangerous assumption: the one that makes everything else pointless if it's wrong.
6. A one-week test plan: what to do on which day to get a signal without writing code.
7. The kill criterion: what result means the idea should be dropped.

If the idea is weak, say so in the first paragraph.

Help me draw the boundary of an MVP that can actually be shipped and sold.

Product: {what the service does}
The main scenario: {what the user does from login to result}
Who the user is: {description}
Time available for development: {timeframe}
Who is building it: {one developer / a team / no-code}

Do this:
1. One user path from sign-up to first value — step by step, no branches.
2. The features without which that path doesn't work. Each with a reason why it can't be dropped.
3. Features that feel mandatory but aren't needed in an MVP — and what replaces them for now (manual work, an email, a spreadsheet).
4. What to cut entirely, and why it won't stop you selling.
5. The boundaries: what the product does NOT do. Wordings for the site so nobody expects otherwise.
6. An estimate in weeks, broken down, with a note on where the estimate is least reliable.
7. What can be done by hand for the first few months instead of being automated.

Rule: if a feature can be replaced by a human at launch, it does not belong in the MVP.

Help me choose the technologies for a project and explain the price of each decision.

What the product is: {description}
What I can do: {languages and tools, honestly}
Time to launch: {timeframe}
Who will maintain it: {just me / a team / a contractor}
Special requirements: {payments, files, real time, offline, integrations}
Monthly infrastructure budget: {amount}

Break it down:
1. The recommended set: frontend, backend, database, hosting, auth, payments, email.
2. For each — why this one in my situation, and a sensible alternative.
3. The price of the choice: what becomes awkward within a year.
4. What I shouldn't build myself but buy as a service, and what it costs.
5. What to avoid specifically in my case, and why.
6. An estimate of the infrastructure bill at 100, 1,000 and 10,000 users.
7. Which choice will be hardest to reverse later — and how to reduce that lock-in.

Account for my skills: an unfamiliar technology on a short deadline is a risk, not an advantage.

Write the hero section of a landing page for a SaaS product.

Product: {what it does}
For whom: {a narrow audience}
What work it replaces: {what the person does today}
The main benefit in numbers: {time, money or errors saved}
Model: {free tier / trial / paid only}
How it differs from the nearest competitor: {a fact}

Give me:
1. Five headline options: clear rather than clever. No metaphors and no use of the word "platform".
2. A subheading for each: who it's for and what happens after signing up.
3. Button copy — three options, at different levels of commitment.
4. A line under the button that removes fear: card, cancellation, setup time.
5. Three pieces of proof to sit beside the hero that you can show without an existing customer base.
6. What to remove: the standard phrases that say nothing.
7. A test: read the headline aloud and say whether someone hearing about the product for the first time would understand it.

Write it so the headline makes the product's job clear even without the image.

Turn a list of changes into release notes and an email to users.

Changes: {paste a list of commits, tickets or your own notes}
Product: {what it does}
Who reads it: {technical users / general users}
Any breaking changes: {yes, which / no}
What the user must do: {nothing / update settings / migrate}

Do this:
1. Release notes grouped into "new", "improved", "fixed". Every item in the language of benefit, not of code.
2. Breaking changes as a separate block at the top, with the exact date and instructions.
3. The email: subject, first line, three paragraphs, one button. About the single biggest change; the rest as a link.
4. A short social post about the most noticeable item.
5. What on the list users don't need to hear about at all — and why.
6. A tone check: cut "we've been working hard" and "we're excited to announce", keep what people can now do.

Rule: never write "fixed bugs" without saying which — be specific or don't mention it.

Pick the metrics for my product at its current stage.

Product and model: {what it is and how people pay}
Stage: {no users / first customers / steady sales}
Paying customers now: {number}
What I already track: {list}
The main question I need answered: {e.g. "is it worth spending on ads"}

Do this:
1. Five to seven metrics, no more. For each: what it shows, how it's calculated, how often to look.
2. Why the other popular metrics are only a distraction at my stage.
3. The single number that shows whether the product is healthy — and how to calculate it for my case specifically.
4. Benchmarks: which value counts as bad, normal and good for my model.
5. How each metric can be accidentally gamed, and what to watch alongside it so that doesn't happen.
6. What to start recording in the product now so there is something to analyse in six months.
7. For each metric: what decision I'll make if it turns bad.

If a metric leads to no decision, leave it out.

You are a support lead. Write reply templates.

Product: {what it is}
Common tickets: {list five to seven}
Tone: {how you talk to customers}
What you can and cannot do: {boundaries — refunds, access, timelines}

For each ticket deliver:
1. A reply under six lines, the substance in the first one.
2. What to ask if information is missing — one question, not a list.
3. A version for when it is our fault: without "we apologise for any inconvenience caused".
4. A version for when we cannot help: what to offer instead.
5. A note on when the template must not be used and a real reply is needed.

Every template must leave room for one live sentence: a message assembled entirely from boilerplate reads as an autoresponder.

You are a technical writer. Write an integration page.

What is being connected: {feature or API}
Who reads it: {reader's level}
What they need beforehand: {keys, access}
Common failures: {what breaks for people}

Structure:
1. What the result will be — one paragraph and one example response.
2. What is needed before starting: a list of three or four items.
3. A minimal working example: exactly enough code to see the first response, and not one line more.
4. The response field by field: what each means and what values occur.
5. Errors: code, meaning, what to do. As a table.
6. Limits: request rate, sizes, key lifetimes.
7. What to do when it does not work: three checks in order.

The first example must run by copy-paste: if anything has to be filled in first, the reader goes to support instead.

You are an onboarding specialist. Write the trial email sequence.

Product: {what it is}
Trial length: {days}
First-value moment: {what the person must do to see the point}
Where people get stuck: {list it}
What happens at the end: {charge / lockout / downgrade}

For each email:
1. The day it goes out and the reason — an event, not "day three of the trial".
2. A subject under 45 characters.
3. Body under eight lines, one action at the end.
4. Who must not receive it: anyone who already did that action.

Required:
5. An email for those who never came back after signing up.
6. An email two days before the end: exactly what the person loses, concretely.
7. An email after it ends for those who did not pay — with no pressure.

The sequence leads to first value, not to payment: someone who never got there will not pay however often you remind them.

You are the engineer running an incident review. Write it up.

What happened: {describe it}
When it was noticed and how: {who saw it first}
How long it lasted: {duration}
Who was affected: {how many people, what did not work}
How it was fixed: {what was done}

Deliver:
1. A minute-by-minute timeline: when it started, when it was noticed, when it was fixed.
2. What exactly broke — the technical cause in one paragraph.
3. Why it was possible: not "a developer made a mistake" but what was missing in the system's design that let the mistake reach people.
4. Why it was not noticed immediately — and how to find out sooner next time.
5. Three actions: what to do today, this week, this quarter.
6. What not to do, even though it is the first thing that comes to mind.

Not a single name: a review that hunts for someone to blame will not happen next time — people stop reporting problems.

You are a product designer. Replace the product tour with contextual hints.

Product: {what it is}
Current onboarding: {tour, video, nothing}
Where people get stuck: {if known}
The key action: {what they must do}

Deliver:
1. Three or four moments that need a hint. A moment is not a screen but a state: empty, first time, after an error, before something irreversible.
2. For each: what to show, in one sentence, and where. A hint lives beside its element, not in the middle of the screen.
3. The show condition and the condition for never showing again. A hint that returns on the tenth visit is an irritant.
4. What the interface should solve instead of a hint. If a field needs explaining, renaming the field is usually cheaper.
5. What to delete from the tour entirely. First-login tours are watched by 20% and remembered by nobody: the person does not yet know why they would care.
6. How not to obstruct experienced users: one way to dismiss everything.
7. What to measure: share reaching the key action, before and after.

Rule: a hint appears once the person is already trying to do something. Before the attempt there is nothing to explain — they do not need it yet.

You are a product analyst. Work through survey responses.

What you asked: {the wording}
Scores and comments: {paste}
How many answered, out of how many: {numbers}
Product: {what it is}

Work through:
1. Who answered. Extremes answer — the delighted and the furious. The middle stays silent and is absent from this data.
2. Themes in the comments with mention counts. One mention is not a theme.
3. What you actually intend to fix and what you do not. A list nobody intends to build is worse than no list.
4. Who to reply to personally and what to say: a low score with a coherent comment is a free interview, if you write the same day.
5. What to do with high scores: ask for a review or a referral, but not in the same email where you thank them.
6. One product change for the coming month.
7. What to ask next time so the data is more useful.

The score itself decides nothing. The comments decide, and so does who wrote them: a complaint from a large customer and one from a free plan are worth different amounts.

You do product marketing. Write a page for people switching from a competitor.

Your product: {what it is}
Competitor: {who}
Why you are better for their users specifically: {real differences}
Where they are better: {honestly}
What blocks a move: {data, habit, contract}

Write:
1. A headline with no swipes at the competitor. The reader uses it — criticism reads as calling their choice stupid.
2. Three differences that matter to their users. Not a feature list but the things their community complains about.
3. An admission of where they are better. Without it the page is not credible: people know the product they use.
4. What happens to data in a move: can it transfer, how long, who does it.
5. The first 15 minutes after switching: what they see and what they get done.
6. Who should not switch. That filters out the people who would return unhappy and write a review.
7. A comparison table, if it is honest. A table where you have every tick reads as advertising and does not work.

Do not make price the only argument. Whoever moved for price will move away from you for the same reason.

You are a UX writer. Rewrite the error messages.

Product: {what it is}
The errors: {how they read now}
Who uses it: {audience}

For each error:
1. What happened — with no technical words, if the reader is not technical.
2. What to do right now. One action. "Contact support" is not an action, it is a hand-off.
3. Whose fault it is. Own yours plainly: "this is on our side" defuses more than an apology.
4. What happened to the data they already entered. The most common fear is that it is gone.
5. Where to show it: at the field, as a top bar, as a dialog. Dialogs are for irreversible things only.
6. What goes in the log and what goes to the person. An error code helps support, not the reader — put it small at the bottom.
7. Three errors to remove rather than rewrite: the interface can prevent them.

Do not write "something went wrong". It is the most useless sentence in interfaces: it says nothing and sounds like an excuse.

You are a technical writer. Write the quickstart page.

Product: {what it is}
For whom: {developer, analyst, ordinary user}
What they end up with: {the result}
What is needed first: {key, account, install}

Write:
1. What they will have at the end — the first line, before any preamble. They must be able to judge whether ten minutes is worth it.
2. Prerequisites, as a list. Not buried where they surface at step four.
3. The steps. Each is one action and one check: how to know it worked. A step without a check ends with someone continuing from a broken state.
4. Code or values that can be copied whole and run. Placeholders like your_key are the only thing they change.
5. What goes wrong for half of them: three common errors and what to do, on this page, not in a troubleshooting section.
6. What next — three links, no more.
7. What does not belong here: architecture, explanations of why things are built this way, a full parameter reference.

To test the page: hand it to someone who has never seen the product and watch in silence. Every place they stop is an edit.

You are a researcher. Prepare a call with a churned customer.

Product: {what it is}
Who left: {segment, how much they paid, how long they stayed}
What the data says: {their last actions}
What you want to learn: {the decision that depends on it}

Prepare:
1. The invitation: a three-line email, with no gift attached. A gift produces polite answers instead of honest ones.
2. A first question that is not "why did you leave". That gets a rehearsed answer. Start with what they did in the product last month.
3. Eight questions about facts rather than opinions: what they did, what replaced it, who decided, what the last straw was.
4. The alternative question: what they use now and what is better there. That answer is worth more than the rest of the call.
5. What not to ask: will you come back, what should we improve. Both produce polite untruths.
6. How to take criticism: do not defend, do not fix it live. One objection and they stop talking.
7. What to do after: what not to promise, and what to write in the thank-you.

Note separately: a churned customer owes you nothing. Fifteen minutes, and not one more without their consent.

You are an editor. Write the money emails.

Product and price: {what and how much}
How the subscription works: {period, auto-renewal}
What you send today: {as it is}

Write five emails:
1. Payment succeeded: what was bought, for how long, the amount, where the receipt is. Short but complete — people keep it.
2. Renewal coming: 3 to 5 days ahead, with the amount and date. This email prevents more card disputes than any terms page.
3. Renewal succeeded: same as the first, without congratulations.
4. Subscription ending and not renewing: what stops working and what remains.
5. Refund: confirmation, amount, when it lands, what happens to access.

For each: subject under 40 characters, body under 100 words, one button.

Rules: amount and date in the first two lines; a cancellation link in every money email; no upsells in a charge notification — it reads as trading on someone else's wallet.

The upcoming-charge email matters most. It gets skipped so as not to "scare people off", and then come the refunds and disputes.