How a SaaS founder decides which features to skip

Executive overview

Most SaaS founders default to building whatever customers ask for, but that approach leads to bloated products that attract the wrong users. Derrick Reimer of SavvyCal walks through his actual decision framework: weigh visceral demand, implementation complexity, and whether a feature draws in the ideal customer. Two contrasting examples — one shipped, one deliberately skipped — reveal how the same analytical lens produces opposite conclusions.

Saying no is a product skill, and it compounds: the clearer your filter, the better the fit of every customer you attract.

Feature decisions: the criteria that matter

• Visceral demand signals real pain; casual "nice to have" requests rarely justify the cost.
• Philosophical alignment with the product's direction matters as much as request volume.
• Features should attract the right users — ones in the product's sweet spot — not just more users.
• Complexity that lives under the surface (invisible to users) is more acceptable than UI clutter.
• Ask whether a feature expands into a new market you actually want, or one that dilutes focus.

What Derrick built: booking approval toggle

• SavvyCal added an opt-in setting requiring approval before a booking lands on your calendar.
• Pain point: power users with public multi-use links were getting unwanted bookings with no control.
• The same feature was a fan favourite in a now-defunct competitor (X.AI), so migrating users arrived already asking for it.
• The toggle is simple in the UI; complexity is hidden underneath — a deliberate design constraint.
• It reinforces SavvyCal's positioning as a scheduling power tool for people who guard their time.
• Ticked all three boxes: strong demand, product-philosophy fit, attracts the ideal user profile.

What Derrick skipped: SMS notifications

• SMS reminders are standard in consumer scheduling tools (haircuts, dentists), but SavvyCal targets B2B professionals.
• Derrick's customers are typically near their calendars all day and get reminders through Google Calendar or Outlook already.
• Conversations with former colleagues who added SMS at Drip revealed the hidden cost: spam regulations, carrier rules, ongoing compliance burden — far beyond a Twilio API wrapper.
• Classic iceberg feature: tiny toggle in the UI, enormous maintenance underneath.
• Zapier integrations already cover the use case for the small subset who genuinely need it — push the complexity to the ecosystem.
• Building it risks attracting users (realtors, high-volume appointment setters) who are a poor fit for everything else SavvyCal does.

The internal scheduling trap

• A small segment uses SavvyCal for internal team scheduling — theoretically powerful, but Google Calendar and Outlook already solve this natively.
• One customer's request to make events editable by all invitees unravelled into a bespoke internal workflow use case that conflicted with the standard booking path.
• The right diagnostic question: Is this a new market worth entering, or a distraction that breaks the happy path for everyone else?

Building a feature backlog (counter to conventional wisdom)

• Classic 37signals advice — never log requests, trust important ones to resurface — does not scale as volume grows.
• Log everything: a spreadsheet or backlog tool is enough. Track frequency, recency, and trend.
• Periodic review lets patterns surface that memory alone would miss.
• Strategies and product vision shift over time; a logged request that was wrong last year can be right next year.

The founder filter

• Building purely to customer demand risks duplicating competitors and losing product coherence.
• Less technical users often want simpler competitors' features; power users push toward over-engineered complexity — both pulls are dangerous without a filter.
• The founder filter is the vision-aligned lens that keeps the product going in a purposeful direction rather than becoming a patchwork of requests.
• Tim Cook: "There will always be more great ideas than we can implement."
• Saying no is hardest in the early days when traction feels urgent; it gets easier once you know who your market actually is.
• Guarding product quality is analogous to guarding code quality — both degrade silently through accumulation.