Ask HN: How to let SaaS customers pay for new features? | Hacker News Reader

Ask HN: How to let SaaS customers pay for new features?

3 pointsbedatadriven3 comments

We have a successful, growing, niche b2b saas product. A few of our larger customers have expressed interest in paying for missing features. These are in general good ideas that we'd like to build anyway in time, but the relatively small size of our dev team and the complexity of the product means it will take longer than they'd like.

In the early days of the product, we did a lot of billing for specific features and it led to a lot of stress, ux incoherence, and a total shift of focus from our product to project management, which I personally am not very good at.

Are there alternatives means of partnering with customers that would give us the resources to develop faster without loosing our focus on the overall product and committment to quality over deadlines?

View on HN

It sort of depends on how much they're offering. Hiring contractors to build features might be an option. (As someone who's been freelance it's rather common practice)

An alternative is to spawn a new UX to the app... Be careful here. At one place I worked we spawned a different private version of our app that made it possible for big clients to whitebox. We called the team "commercial". Different UX, different pricing for users of the different UX. It worked rather well. They paid for the changes to the UX for their "white box".

Where we went wrong. We should have called them markets. That is my one bit of advice. Call the different UX a different market.

Then you get something for free. You get to go international. Instead of just "Wallmart" being a market, and "Target" being a market. (with different language, different fonts, and different assets (including emails). You GET UK being a market, and Sydney being a market, and ...

If you do it right, you have a pattern for building things for different business, and different geography. Win win.

Final cheat code.

If you eventually plan on breaking your database into many different DB's don't go fancy on the user_ids. Just change the sequence to increment the ids by 100, instead of 1, and all users built in region/market 0 get n00, while users built in region/market 1 get n01, and so on. It's not so you know where the user was built, it's to guarantee uniqueness of the ID. It's a pile easier than changing your whole system to UUID's.

Thanks. This is interesting to hear as we are also eying additional industries where our product could be useful. Though the present issue is with developing features that would be welcomed by all users within our current vertical.

From what you've described, it sounds like you shared infrastructure (db, etc) between markets? Different versions or one monolith with feature flags?

I think there is a fine line between iteratively developing your product as a whole and leaning it completely toward your biggest customers. It might not be ideal to turn your product development team into a software solution team that trying to meet every customers' needs.

> These are in general good ideas that we'd like to build anyway in time.

Meaning these features are already somewhere in your product roadmap. How about just share your future development plan and give them access to professional customer support? Anything further than that like shifting development effort to their needs completely just feel wrong in a product point of view. Sell your most valuable features, not your dev team.

> Are there alternatives means of partnering with customers that would give us the resources to develop faster without loosing our focus on the overall product and commitment to quality over deadlines?

This might be highly unrelated due to different business model, but for my previous startup I stuck in the same boat for a while. Eventually, I made part of my product open-source, build a community of fans that love the product. Afterward, the development support and contribution from the community is enough to keep the product going.

Reply on news.ycombinator.com