Our Industry Was Pricing Out “The Little Guy,” So We Rebuilt Our SaaS Payment Model From The Ground Up.
Since launching Aquro earlier this year, we’ve witnessed a concerning trend in our industry: The squeezing out of the very audience we set out to serve in the first place.
For example, back in August, one of our primary competitors announced a severe price hike: Their lowest paid plan for hybrid developers — the term for those using web-languages to write apps for native iOS/Android installation — would effectively double to a whopping $90 per month (or $60 per month, for those who could afford to shell out a $720 annual payment).
The backlash was swift and definite, and comments on their announcement prompted a response directly from the CEO of the company. Within days, that response itself was also sporting a comment section full of frustration from current and prospective customers alike.
Another major player in the industry has a point of entry of $39/user/month, which sounds more fair, but is restricted via lack of external data connection capability and several other nearly essential features reserved for higher plans. Where do those plans start? $149/user/month, of course! You and your friend want to work together on an app idea and need to be able to communicate with an external DB? That’ll be $300/month, please.
We’re not so naive that we think these moves are without purpose: Both companies have probably both noticed that it’s much easier to pay the bills by nabbing several agency/enterprise clients, and pushing prices to position yourself as that type of provider, than it is to acquire thousands of customers at a few bucks per month.
But do the two have to be mutually exclusive?
We actively work to seek out larger business contracts ourselves, but does that necessitate cutting out the very audience (individual web developers who want to try their hand at making apps) who our company’s mission was built upon?
We don’t think it does.
Even so, we noticed as we toyed with various pricing models, that even if we tried to keep individual pricepoints lower than our contemporaries, we ourselves were drifting toward the standard SaaS “plan” approach, in which a number of features and app projects slots are bundled together so that someone has to effectively pay for all of them in order to access the one or two things they’re actually interested in.
This in and of itself started to feel like it might be fundamentally flawed.
In the same way as flat pricing hikes, could combining the value of various features to get a pricepoint also be prohibitive to curious prospective developers, if a large enough percentage of those features were things they would never touch (and whose value contribution effectively became zero)?
Back to the drawing board.
We started collecting as much qualitative feedback from our users as possible: What kind of projects were they working on? What seemed like a fair price to them for the tool we had to offer? Why had they come to us instead of a competitor? How many apps would they be creating?
From our conversations, a few points were repeated often enough to become glaringly obvious:
- There was a clear difference between the needs — and the budgets — of those who were creating their own personal app projects vs. those who were creating contracted apps for a client.
- Many users in the former group would only ever create one or two apps, while those in the latter group might create an unpredictable and increasing amount throughout their time with us as they took on various client projects.
- Timing was tricky: Many developers wanted to give Aquro a try, but wouldn’t be ready to commit within a trial period due to time constraints or the fact that they weren’t ready to actively work on development yet.
It became pretty obvious that standard packaged pricing in the industry — in which an account pays X amount of money for a flat amount of app projects and accompanying features — was going to result in customers frequently both overpaying and underpaying depending on their needs. In short, the pricing too often scaled seemingly arbitrarily, rather than in 1-to-1 sync with the needs of a particular app project.
From here we moved toward pricing that was paid per app project, but we wanted to segment even further if possible. Our challenge was creating a free or extremely cheap entry point into the product that was useful and complete, without diminishing the value of paid app types.
We knew we were onto something, but the final piece of the puzzle came to us when perusing one of the most popular tools in the dev world: Github.
Github lets developers use more or less their complete product, without restriction, for free. The only stipulation is that free projects are open-source, meaning other users of the site can see what you’re working on and try out the code for themselves.
Not only could we use this same distinguishing factor to justify keeping a nearly full-fledged version of Aquro free for use, it could help us address point #3 above (timing) by creating a sort of indefinite trial period to help developers get comfortable with our tools.
Plus, we inadvertently stumbled upon a 4th point that we hadn’t picked up on when interviewing our users: community building.
By creating a public App Library for open source projects to be listed in, we could probably start to build up this critical community component that helps to define some really great developer tools (Github itself being an example, and we even have to give a non to our previously open-source competitor Ionic, in this regard — they do a great job of helping users help each other in learning & education).
The punchline being…
All of this is to say that today, developers, we’re unveiling a brand new pricing structure with you in mind, and while you can’t always please everyone, dammit we’re going to try.
All Aquro accounts will now be free and remain open forever, no more hard trial period.
You will be able to create an unlimited number of projects without paying, and for each project’s first 7 days, there will be no limits in its behavior or even its access to backend services.
After one week, each app needs to be assigned as one of the types specified below:
As you can see, as long as you’re alright with a project remaining open source for a time and allowing others to learn from it, you can create, launch, update, send push notifications and emails from your app, etc. without every paying a dime.
As an app grows, shrinks, or has new privacy requirements, you can upgrade or downgrade it without penalty, and to keep you from paying for things you don’t need, every app project is billed separately. So if only one of your apps needs to be closed-source and have some more push-notification allowance — TA DA!— you just upgrade that one app, the rest of your projects stay free, and you’re on your merry way. No need to buy a package with 5 app project slots just to get “pro” level features for your one solitary project.
We’ll be keeping an eye on the effectiveness of this structure over the coming months, and be listening to your feedback to determine things like…
- Should each app’s ‘grace period’ be longer? 14 days? 30 days?
- Do these pricepoints accurately reflect the value derived from them, or are we missing something?
- Does the new structure, which offers a free element we’ve never had before, work to help grow our community quicker and increase the number of Aquro-developed projects in circulation?
Only time will tell, but we’re optimistic!
We’d love to hear your thoughts below, and whether or not you already use Aquro, we’d love to have you come hang out in our Slack chat and serve us up some banter, feedback, and/or tough questions — feel free to hit up email@example.com requesting an invite and we’ll get you in ;)