4 Features you don't need in your SaaS product

The temptation of feature bloat

I want to share four features that I think most products just don't need, especially the specialist pieces of software I build that serve very particular markets and solve specific problems. This is almost the opposite of what some people think of when they consider tech entrepreneurship - those big Silicon Valley mass investment, millions of users type products. We're not talking about that here.

Most of my clients have a core user base which is a mix of their current clients or customers and some new ones they've attracted to use their platform. They'll probably use the software as a first rung on their product ladder and upsell them on their core service offering. It's a slightly different approach, and with that focus, here are four things I think we should avoid altogether in early-stage SaaS products.

1. Credit card subscription billing

The idea that users can go to your website, read about your product, register, enter all their details, and input their company credit card to be billed monthly is, in my opinion, a massive waste of time for most new products.

The development effort to build something like that is quite substantial. Yes, it can be handled by services like Stripe and Paddle, so it's not the most complicated thing in the world, but it adds a significant layer of complexity. If you're selling a new product to a small user group, why not just register them in the system manually?

The personal touch advantage Create a simple admin interface where you can enter their information and invoice them normally like you would for any other service. Ask them to set up a standing order if needed. This is probably a better customer experience for them, even though it's slightly more work for you.

There's a tiny bit more admin involved, but it's probably nicer that they're getting almost a concierge service from you. You're going to set them up on the platform and show them how to use it rather than just providing a faceless registration page.

The documentation trap If you go down the self-service route, you'll need extensive documentation, possibly training videos, and the expectation should be that many users won't get the value from the platform. Many will churn, saying it's not for them. If you personally onboard them, show them how it works, and set up their billing, you've got a much deeper connection and relationship with them.

I appreciate this might not be scalable when you've got 100 or 1,000 customers, but that's a future problem. That's a good problem to have. If you're at that level, you'll have the money to invest in automated registration and onboarding processes. Wait until you're there.

2. Dark mode

I don't know if you're familiar with dark mode, but many websites allow you to pick light or dark themes, or listen to your system settings if you use dark mode as standard. For developing a new product, it's just a waste of time.

The styling complexity Dark mode adds significant styling complexity and development cost. Every interface element needs to be designed and tested in both modes. Colours that work in light mode might be completely illegible in dark mode. Images and icons often need different versions.

The priority reality It's not going to make or break your product. If someone says they won't sign up because it doesn't have dark mode, trust me, they're not the person you want to deal with anyway. They're probably not serious about solving the problem your product addresses.

Focus on core functionality that delivers real value. Dark mode is aesthetic preference, not business necessity.

3. Advanced account management

Don't attempt to add loads of controls where users can manage their profile, upload photos, manage their account, delete their account, access their data, and all the other bells and whistles you get on some platforms. When you're just starting out, it's completely unnecessary.

The simple alternative If users want changes made, you can either build a simple interface that you, as super administrator of the platform, can use to help them, or the developer working on the project can change something in the code. Instead of building out all these controls so people can do it themselves, handle it personally.

The relationship benefit This approach actually strengthens the relationship with your users. They see you as responsive and helpful rather than hiding behind automated systems. It also gives you insight into what users actually need versus what you think they need.

When you do need to scale this, you'll have real data about which self-service features are most requested. Build those first, not everything you imagine users might want.

4. Advanced system notifications

For early-stage products, advanced system notifications are similar to the account management issue. People seem very tempted to add automated weekly emails, monthly report emails, "when this happens" notifications, and all these different alert systems.

The annoyance factor These notifications can actually be seen as negative by customers. Many will instantly ask for them to be turned off or request controls to disable them. You end up building notification systems and then controls to turn them off - double the work for no benefit.

The feedback-first approach It's much better to get your product live without all that and get some feedback. See if people would actually like notifications. If so, you can ask them what they want to receive because until they tell you, it's just guesswork.

This doesn't mean don't send anything out via email or notification, but keep it really minimal in the beginning. Don't go overboard on alerts, data reporting, and insights. Let users shape what they actually want to receive.

The common thread

All four of these features share a common problem: they're solutions looking for problems. They seem like good ideas in theory, but in practice, they often create more work than value for both you and your users.

Development time vs. user value Each of these features requires significant development time that could be spent on core functionality. They also add complexity to your codebase, making future changes more difficult and expensive.

The feedback loop By skipping these features initially, you're not just saving development time - you're creating opportunities for meaningful user feedback. When users specifically request these features, you know there's genuine demand.

When to revisit these features

Later down the line, these features may become valuable. Once you've got paying customers and clients, revenue coming in, and the product is generating ROI, you can start to look at adding them.

They may absolutely have value and may become requested by customers or needed for scale, but they're not things you need today. The key is building what users need now, not what you think they might need someday.

The MVP mentality

This approach aligns perfectly with building a focused MVP. It's about getting to market quickly with core functionality, then iterating based on real user feedback rather than assumptions.

By avoiding these four features, you'll launch faster, spend less money, and build something users actually want. You can always add complexity later when it's justified by demand and revenue.

The goal isn't to build the most feature-rich product - it's to build the most useful one. Sometimes that means doing less, not more.