/saas-playbook — Build a SaaS the boring, working way

Source of the method: How I'd Build a SaaS in 2026 — Shayan Taslim, UserJot

The default failure mode of a technical founder is building a well-engineered product nobody was already trying to pay for. This skill exists to keep the work pointed at demand, distribution, and revenue — and to keep the codebase small enough to change every week.

Usage

/saas-playbook <idea, market, or current situation>
/saas-playbook validate <idea>
/saas-playbook scope <idea>            # cut to a shippable MVP
/saas-playbook price <product>
/saas-playbook triage <feature requests>
/saas-playbook next                    # what to work on this week

If the user gives only a vague idea, run Phase 1 first. Never jump to architecture or stack selection before demand evidence exists.

The nine rules (never violate)

1. Boring market with existing demand. Enter a category where people already pay and already complain. Do not invent a category.
2. Talk to customers constantly. Every user is worth more than their MRR — they carry context, edge cases, and the next feature.
3. No big launch. Launch day is not a growth strategy. Ship-and-post beats weeks of prep for one artificial spike.
4. Drip instead. Introduce the product continuously: progress posts, DMs, build-in-public. That compounds into trust.
5. Keep the stack simple. Optimize for 10–50 users, not Netflix. No k8s, no bespoke CI, no microservices before product-market fit.
6. Say no more than yes. Every yes is permanent support surface. Protect the core.
7. Charge from day one. "Free while in beta" manufactures fake validation. Charge early and charge more than feels comfortable.
8. Public feedback board on day one. Post → vote → in progress → shipped. It shapes the roadmap and signals responsiveness to prospects.
9. Marketing > coding. Target split ≈ 50% marketing / 20% support / 30% building. A product nobody knows about has no quality.

Workflow

Phase 1 — Find demand (before any code)

Budget: about one week. Deliverable: a written demand brief.

1. Pick a vertical, not a technology. Support tooling, internal dashboards, CRMs, compliance, scheduling, billing ops, agency workflows.
2. List the top 5–10 incumbents in that vertical.
3. For each: landing page promise, pricing tiers, target segment, obvious gaps.
4. Mine complaints — G2/Capterra reviews, Reddit, X, churn threads, support forums, changelog comments, "alternative to X" searches.
5. Talk to 5+ real users. Ask what they love, hate, and work around. Do not pitch.
6. Cluster complaints into recurring pain points. Rank by frequency × severity × willingness to pay.

Output the brief:

Stop the idea if there is no incumbent, no one is paying today, or the complaints are only about price.

Detail: references/demand-research.md

Phase 2 — Cut scope to a wedge

Write the MVP as one sentence: "For who, it does one job, better than incumbent because specific gap."

Then cut:

• Kill every feature that is not required for that one job.
• Kill settings, admin panels, roles, and integrations that only one prospect asked for.
• Keep: signup, the core job, billing, and a feedback path.

The MVP will be messy and buggy. That is acceptable. Functionality, UX clarity, and iteration speed are not.

Detail: references/scope-and-stack.md

Phase 3 — Pick the boring stack

Rules of selection, in order:

1. Fastest for this specific builder beats objectively best.
2. Managed everything: hosting, database, auth, payments, email.
3. One deployable unit until scale forces otherwise (see the architecture skill for the split when it does).
4. Nothing that needs an ops on-call rotation.

Explicitly forbidden pre-PMF: Kubernetes, custom CI runners, microservices, event sourcing, self-hosted auth, multi-region, custom design systems, GraphQL federation, hand-rolled billing.

Detail: references/scope-and-stack.md

Phase 4 — Charge from day one

• Ship billing with the MVP, not after it.
• Lowest real plan should still be a real price. $5–$10/mo minimum for prosumer; far more for business tooling.
• Price against the incumbent's tier, not against your hosting bill.
• Offer discounts or founder pricing over free tiers — a discount still requires a card and still proves intent.
• If nobody pays, re-examine the problem, not the price.

Detail: references/pricing.md

Phase 5 — Stand up the feedback loop

On day one, not later:

• Public board: users post ideas, others vote.
• Roadmap: planned / in progress / shipped.
• Changelog: every ship, however small.
• In-app path: widget or one-click email reply.

Then work the loop: acknowledge fast, tag by pain point, link requests to the board, close it out publicly when shipped. Criticism ("the UX is confusing", "I didn't know that was clickable") outranks praise as signal.

Tools: UserJot, Canny, Featurebase, Nolt, or a plain public board — the tool is not the point; the visible loop is.

Detail: references/feedback-loop.md

Phase 6 — Drip distribution

Replace launch day with a continuous release of evidence:

• Ship something → post it.
• New feature → thread, short video, or changelog post.
• Milestone → share the number honestly, small as it is.
• Write for search: comparison pages, "alternative to X", specific how-tos in the vertical's language.

Try several channels for a fixed period, measure signups per channel, then double down on the one or two that actually convert. Expect variance — a post that lands and five that do not is a normal week.

Never: fabricated metrics, invented testimonials, spam DMs, engagement pods. Reputation is the only durable asset a small product has.

Detail: references/distribution.md

Phase 7 — Run the weekly loop

Every week:

1. Read all feedback; re-rank the board by votes × strategic fit.
2. Pick one improvement to the core job. Ship it.
3. Publish it (changelog + one channel post).
4. Talk to at least two customers.
5. Check the time split against 50/20/30 and correct the drift.

Feature-request triage

For each incoming request, ask in order:

Saying no protects speed and sanity. Saying yes to everything is the fastest route to hating your own product.

Reply template:

That's a fair ask, and I hear why it matters for your workflow. It's outside the core of what this tool is trying to be great at, so I'm not planning to build it right now. I've added it to the public board — if it picks up votes I'll revisit. Here's how I'd handle it today: <workaround>.

What to tell the user

Be concrete. Every output should contain:

• The current phase and what closes it
• The single next action
• What is deliberately being not built, and why
• Where marketing time is going this week

Do not produce a business plan. Produce the next week.

Anti-patterns

• Building for three months before a stranger sees it
• Choosing the market because the technology is interesting
• Free beta "to get feedback", then a paywall that empties the app
• Prepping a Product Hunt launch instead of shipping and posting weekly
• Infrastructure sized for a scale that does not exist
• Saying yes to a one-off integration to close one deal
• Treating feedback as a support queue instead of a roadmap input
• Rewriting the codebase before there are paying users
• Vanity metrics: waitlist size, impressions, stars
• Faking traction of any kind

References