18
21 Comments

Attempt to Increase MRR With Price Tier Change

95% of my customers purchase the "cheap" developer license shown below.

Developer license (109/year)

  • 1 developer
  • unlimited projects
  • normal support

Team license (449/year)

  • 5 developers
  • unlimited projects
  • priority support

After doing some customer research I noticed about 10% are existing SaaS products, 15% are start-ups (assuming from gmail/hotmail accounts etc.), near ly 75% of customers are web agencies. BUT nearly all of the agencies purchased the developer license.

The price of a team license should be far from shocking for a web dev agency (certainly when building multiple sites which agencies mostly do). To get more agencies to purchase the team license I decided to remove the "unlimited projects" option from the developer license. The developer license is still very suiting for startups and team license price should be very reasonable for profitable SaaS products.

By changing the price tiers to ones below I hope to make it better fit to my customers and see a change in purchase behaviour in the near future.

Developer license (129/year)

  • 1 developer
  • 1 project
  • normal support

Team license (499/year)

  • 5 developers
  • unlimited projects
  • priority support

Learnings for me. Things were going fine but I wasn't keeping a close eye on what kind of customers were buying. By monitoring that more closely I gained valuable insights into how to better position my product and price points.

  1. 2

    Hey Rik, I'm a big fan of a three tiered pricing model. Anchoring is when you have a high price on the right hand side, your chosen price in the middle and a low price on the left. The anchor is simply there to make the middle price look like a good deal. If you look at some bigger SaaS companies they use it. What's the difference between normal and priority support?

    1. 2

      Thanks @nomis_mikah I think I'm doing this on https://pqina.nl/doka/ but I might be wrong :D

      Normal support max response time is 5 business days, priority support is 2, priority support also cuts in line of "standard" support requests. I now realise I don't explain this on my product page, so might be a good idea to do so. Thanks for asking :-)

      1. 1

        Yes you are. Ok. So the only difference between the middle and the organisation option is the number of developers. Agree with Chris's comments below. Your real challenge is how do you police it. 🤔

        1. 1

          Yes, that's the only difference.

          I hope the "request support via the dashboard" will help police it a bit. But honesty if customers want to cheat then they will, if they want to pirate, they can. I've decided it's better for me to focus on customers that do want to play fair. Based on emails I get I find that most bigger companies want to make very sure they buy the correct license.

          1. 1

            I think your approach is a good one. And as you say if people want to get around the system they always will find a way. You're right about the bigger companies. They have to be 100% compliant which means making sure they do the right thing. Maybe that's where you focus should be and lose the smaller players?

            1. 1

              I've been moving in that general direction :)

              The higher price point also results in less support requests / more knowledgable customers. It's a higher price point compared to my older Envato plugins, compared to products like HighCharts/AMCharts/Webix Doka is still very cheap.

              1. 1

                I think that's def. the way to go. It then keeps you guys focused on the needs of your higher value customers.

  2. 1

    @rikschennink That's a great image editor you have there. Great work! Have you considered offering dynamic prices for individual developers? The reality is that developers in the Netherlands have vastly different incomes from developers in Eastern Europe, USA, etc. You could be capturing more revenue from devs with higher incomes, and increasing conversions with lower prices for devs earning lower wages.

    1. 1

      Thanks! I've considered pricing based on geographic location, because I'd love to have everyone on board, but it's currently not supported by Gumroad (my payment provider). Also, most of my cost is in support, and my support time is the same for everyone. One option would be to make support optional, haven't explored that enough yet.

      1. 1

        Geographical pricing would be great. Wes Bos uses this pricing strategy successfully.

        1. 2

          @rikschennink @mintran Ah, that's a great point regarding payment providers only supporting customers in certain locations. In any case, I'd be happy to help with my product https://modernpricing.com when pricing changes make it on your roadmap. Keep up the great work!

  3. 1

    I bet you could 3x your revenue by changing $129/year to $29/month.
    It's a lot smaller commitment, yet net revenue would be higher.

    Also, what features do they use on Dev plan vs. Team plan?

    You could easily offer most used features on Dev plan, but offer the 20% of rarely used, but needed, features on the Team plan. This way your customers would try on Dev, like it, and then run into the problem of needing that one more feature, and have to upgrade.

    Possible up-gradable options:

    • Load, transform, and save SVGs
    • Transform input images to other image formats
    • Easily integrate with third party libraries (whatever this means)

    Also, as someone who had to struggle with EXIF on Waddle, I can tell you that Copy JPEG EXIF data to output image is definitely a premium feature, especially if you support the new iPhone image format. It's a monstrous pain the ars!

    Image-manipulation of any kind is a pain, so perhaps your best bet isn't to try and convert people to higher plan, but to get 100x more developers to use your library.

    Personally, I am now using IMGIX on backend, because it's easy. I don't know if they have a good editor, but if they don't , you should partner.... or find someone like them, who is worse, and make their systems better.

    Hope this helps!

    1. 2

      Thanks for the feedback, very much appreciated. Some excellent food for thought :-)

      About the monthly plan. I'm hesitant because a monthly plan might make devs subscribe for a month, download the library, and cancel, then resubscribing when they need an update. Maybe I should just try this out for a week with a "fake" price panel.

      1. 1

        Perhaps that's the main reason they are not paying for more developers, because you are making it easy to download the code and use it for 10,000 people, if they want.

        Can you enable API keys on your library, thus only making it useful for paying customers?

        For example, I could get all the code for Intercom or HelpScout, but neither will work if I stop paying.

  4. 1

    Hey Rik, this looks like a great move!

    Suggestion: Since it doesn't really cost you anything more to add more developers to the system, I wouldn't cap it for the "Team" license. 5 feels really arbitrary anyway. If it's a large agency, they're just going to funnel support requests through those 5, just like they were/are with the 1.

    I also like the idea of bumping the "Developer" license to 3-5 projects. Or at least allow freelancers to buy additional project licenses at a reduced cost.

    1. 1

      Thanks!

      It's arbitrary, but also, if you can hire 5 developers, USD 499 shouldn't be an issue. Bigger companies do purchase double or triple team packages to cover their developer count, I find those companies also have legal department so want to do things right. I like the freelancer license idea.

  5. 1

    Nice work, the easiest way to increase revenue is to either charge more or get customers to bump up plans. I'm sure this will give you a nice MRR boost.

    One thing I would consider is maybe allowing the developer project to have 2 or 3 projects? As a developer I hate it when I love a cool tool, it's great so I don't mind paying for it. Then I have a super small side project but am forced to pay a bunch of money for the tool I already love on a site that I know is only going to get 100 users max.

    I guess it comes down to pricing in the amount of value your customers get from your product. I think ideally you would want to price on traffic, or users. Unfortunately, it looks like you would have no way of knowing that.

    1. 1

      Thanks!

      With every change I see what feedback I get from potential customers and adjust accordingly. Very curious if I'll start hearing this more now the default license is no longer unlimited.

      Pricing on traffic/users/etc is very difficult without adding something that calls home which would introduce all sorts of other trouble. I find seats scales best with organisation size, also bigger organisations often choose to play nice.

  6. 1

    Agencies tend to go with the cheapest option they can get away with so I would expect them to sign up with a single developer license and simply share the credentials.

    I can see this would be difficult to manage from your perspective as the per-seat licensing is offline so you have little control over it as there is no login / dashboard for you to enforce the per-seat restrictions.

    1. 1

      They might, and some probably will, there's nothing I can really do about it, and I've accepted that, hoping to see some change 🤞

      I'm working on a dashboard where customers can add "developers" which can then request support using the dashboard. If they'd share the account then everyone would be able to access everything (like manage licenses etc.) which might be scary for some companies.

  7. 1

    This comment was deleted 4 years ago.

    1. 1

      Thanks, so nice to hear that! :D

      Exactly, it should be pocket change, but for me it's quite a lot. The tricky part is to make the developers working for the agency to understand this, work in progress :D

      I've considered this but "Agency" is kinda of a mismatch with the customers that use it for a SaaS. Maybe I should add a description below the tier title. Something like "Perfect for SaaS solutions or Agencies"

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments