DEV Community

Rails Designer
Rails Designer

Posted on • Originally published at railsdesigner.com

Features your SaaS MVP Don't Need

This article was originally published on Build a SaaS with Rails from Rails Designer


Through my service of building a SaaS in a month, and generally people (developers) reaching out to me over the last decade (I built my first successful SaaS in 2016), I get to talk to quite a few people interested in starting their first SaaS or giving it another try after the first try (tries!) failed.

After the first advice of: “more marketing and start doing it yesterday!”, I often need to convince them not to include certain features. Now this list is not set in stone; your app might just need a feature listed here, but in general, most B2B SaaS apps don't need these. Just forget about them for now. Focus on the core features (the fewer, the better) now. Make sure these features work absolutely well. Only then, and likely only after you get requests from (paying!) customers, do you consider adding these features.

Talking about core features: build those first! Meaning: do not add any secondary features, like authentication, authorization or multitenancy. Even though Rails 8 has an authentication generator and there templates that help with this (I have something in the works for this as well 🤫). Focus on the core of your product first.

Dark theme

Just don't. Yes, inverting three screens to black is simple and quick. But a well-crafted dark UI is surprisingly hard and time-consuming, let alone if you need to do it for every new feature you are gonna add. You'll need to consider contrast ratios, readability across different components, and how your brand colors translate to dark mode. Focus on making your light theme good enough first.

Password reset

Reset passwords for users manually until it becomes too much work. When someone emails you saying they forgot their password, just reset it for them and send them a new temporary password. This personal touch actually builds customer relationships early on. Most early-stage SaaS apps have so few users that manual resets take just minutes per week (if any time at all!).

Team features

SaaS products requiring team collaboration are a harder sell. Individual users can make purchasing decisions quickly, but team features mean you need to convince multiple people and navigate company buying processes. Start with individual accounts first.

Role-based Access

If you do need multiple team members within an account, give them all the same access. Maybe only limit account deletion to the first user (owner). Building permission systems is just too much work. Not just the logic, but also the UI for managing roles and all the testing scenarios.

Admin dashboard

Just use the Rails console until manual management becomes annoying or time-consuming. You don't need fancy charts and user management interfaces when you have 25 customers. A simple database query can tell you everything you need to know. Build admin tools only when you're spending hours each week on manual tasks that could be automated.

Custom Branding

Choose a solid gray color palette and one brand color. No icon or logo needed. Focus on making your product work well, not on perfecting your visual identity. You can always hire a designer later when you have revenue.

Multi-language Support

Use the language your main audience speaks. This could be English, but there are great SaaS products yet to build focused on other regions and languages. If you speak the local language, that's actually a competitive advantage in many markets. But internationalization is a pain. Date formats, currency handling, ongoing translation maintenance as you add features.

Welcome email sequence

You probably read this in some SaaS handbook/must-do guide. “A successful email sequence that gets you customers for life”. Just do not add it. Just stick to one simple email you send to the user to remind them about your app with a link to log in to your app. Simple. Focus on making your product so good that users want to come back, not on crafting the perfect 7-email drip campaign.

Comprehensive payment/billing setup

Just use the most simple setup by using the payment provider's no-code solution. Like this one I use for my SaaS, built using Stripe. Avoid building custom invoicing, tax calculation, or subscription management using their API for an in-app experience. These systems are incredibly complex and full of edge cases that will consume months of development time.

Deletion of records

Creating records is easy. Deleting records can raise all kinds of new issues that are tricky to solve. Sometimes it's not even clear what the path for deleted records should be. Removing a team member? What happens to their created records? Delete them too? Attach to another user (see how single user accounts make things simpler!)? Which user? What about audit trails or data dependencies? Instead, just don't allow deletion at all in your first version. You can always add proper deletion later when you understand your data relationships better. If they really need something deleted; do it for them.


And that's it: an incomplete list of features you should not add to your first SaaS. There are likely many more you should avoid. The rule of thumb I keep in mind is to focus on the unique feature of my SaaS and only add something once it hurts. This could be when doing things manually gets too annoying for me and my team, or when paying customers complain or ask about something repeatedly.

With all that said: it's important that I'm not suggesting you should half-ass features. By skipping unimportant, non-essential bits, you can spend more time on the important features and make them work great and almost without bugs. Your goal is to build something people actually want to pay for, not to check boxes on a feature list.

If you want to experience how this works in a real SaaS app you want to launch, you can hire me through my service of building a SaaS in a month.

Top comments (0)