MicroAngel State of the Fund: May 2022
Planning the next great adventure, growth experiment wins, pricing research, strategy & roll out. Closing MRR: $25.32k
Hey heeeey microangels,
Thanks for checking into what is the 16th edition of the MicroAngel State of the Fund. Sixteen. Insane how fast time goes by.
So fast that two-thirds of the experiment is now complete.
And we can all agree the results at this juncture are phenomenal.
This was an interesting month for me personally because I lifted my foot off the accelerator for the first time in over a year to begin laying the groundwork for my next great adventure.
Since the start, the very design of this playbook has been to challenge the idea of committing thousands of dollars of your own savings to buy up a year’s worth of personal runway to then be spent chasing after product-market fit.
The most dangerous part of that plan is that going from 0 to 1 usually takes longer than the time your runway will buy:
Find a market with a pain
Build a prototype that solves that pain
Go to market quick and scrappy
Earn valuable feedback and turn it into an improved product
Reach market/product fit, get to revenue
Grow the run rate enough to cancel out personal burn
All that — in one year or less. However long your runway is, the odds of making it under those parameters are not great.
And the sad part is that this reality has nothing to do with your own talents or your ability to code/market a product.
Instead, the playbook aims to field the would-be runway to acquire cash flowing, high-margin SaaS products that you could feasibly operate mostly on your own.
The result of this plan is three-fold:
Provided your investment is strong enough, the cash-on-cash returns provided by your acquisition’s free cash flows could immediately cancel out your personal burn and buy-back time
In the time you hold onto your investment, and provided you’ve made good investments, it is likely you will observe stable growth which will result in a capital-gain later when you decide to sell.
You buy back most of your time along the way.
Thus, not only would you grow your runway (rather than burn it), but you’d buy-back your time and set yourself up for a liquidation event that will provide you additional proceeds to keep growing.
The time you get back from your free cashflows allows you to grow your own portfolio at your own pace or to reinvest that time elsewhere when it makes sense, provided the portfolio continues to tick along.
I fully benefited from that this month as I dove ever-deeper into the next iteration of the MicroAngel journey, and one which I’m so excited to be working on.
In the meantime, we’ve continued our heads-down product work to make progress towards important integrations that will have a dramatic impact on run-rate in the mid term.
Nearly 100 people have already joined the MicroAngel Community. If you’d like, you’re more than welcome to join and participate in the Discord, where we chat microsaas, bootstrapping and web3.
PS. This post is image-heavy and Substack complained about the post being too large for email. If the content cuts off for you, you may prefer reading directly from the site or Substack app.
Current fund lifecycle stage
✅ Buying (02/2021 - 05/2021)
✅ Fixing (06/2021 - 08/2021)
✅ Improving (09/2021 - 12/2021)
→ Growing (01/2022 - 08/2022)
Roll up (09/2022)
Exit (10/2022 - 12/2022)
Fund Activity
Funds Deployed: $573.5k
Products: Reconcile.ly, Postcode Shipping
Closing MRR: $25.32k
MRR Growth: 0.74%
30-day Revenue: $25.42k
Rolling cash-on-cash return: $275.32k (+48% / +0.48x)
30-day ARR growth: $2.23k (0.74%)
Cumulative valuation increase: +$641.67k
Current Total ARR: $303,792
Fund valuation @ 4x: $1,215,168 (+111.89% / +2.12x)
16-Month Total Return (MOIC): +159.89% / 2.6x
Some exciting news here as we cross the 2.6x multiple threshold. At the current monthly yield (4%), we can expect to hit the fund goal of 2.7x by mid-September 2022, a full 6 months ahead of schedule.
Given that pace, I’m looking at a total multiple on invested capital of nearly 3x by February 2023, the target maturation date:
2.7x in 19 months with 6 months left (0.04x per month)
0.24x from remaining six months
2.7x + 0.24x = 2.94x total MOIC by end of month 24
We’re still not in a rush to sell the portfolio, and things are developing in a very interesting manner in that regard. We may not end up selling the portfolio to a PE fund but to ourselves.
If that sounds a little confusing, I understand, but it will all make sense soon.
My plan is to decentralize the fund moving forward and to power both fundraising as well as investing and operational decisions via a decentralized governance structure.
Under this new model, the Microangel DAO (decentralized autonomous organization) would live as a set of constitutional rules embodying the playbook, its intentions and the target parameters surrounding good investments per the playbook.
The sales earned by the DAO would flow through to its treasury, which would in turn be used to acquire cash flowing SaaS products, the free cashflows of which would be redistributed equally among participating DAO members.
Under that scope, MicroAngel could sell its portfolio to the DAO as its very first acquisition, and the funds for this acquisition would be raised through a token sale the participants of which will become the DAO’s founding membership.
It’s an early idea for launching the whole thing while closing the books on the current experiment while benefiting from the very attractive infrastructure and opportunity I’ve laid for future sellers.
In other words, I want to keep working on these products but under a different set of circumstances which in turn open the doors to the future for other microangels to join and co-invest.
Product
With a bunch of small features out of the way and a new UI in the app’s most critical sections, we’ve noticed some good feedback and comments from merchants using the UI and the engagement from new users is on the rise.
The changes I made to the onboarding last month also seem to be having the desired effect as we observed a +20% increase in onboarding completion.
Despite this, there’s a part of the onboarding that still introduces a lot of friction/work for the customer and it’s not ideal - there’s more juice to extract there for sure, and like everything else experiment-related, I’ll hack at it next I’m around that piece of code.
Importantly, growth is definitely back on track. There’s a mix of both increased demand from the app store as well as some success from the marketing channels I’ve built here and there.
A 5% month is definitely a good month. Especially when you can celebrate a milestone like surpassing 500 active merchants. 🎉
Pricing
The main thing that consumed me over the second half of the month has been researching, validating, designing and implementing a multi-step pricing project to accomplish several related goals.
Namely, pricing needed readjusting so it would:
Enable better cashflow + retention by selling yearly plans
Sell larger plans by communicating the new features they include and gating features from lesser plans
Introduce promotional and hidden tiers to be used for one-time offers to customers either in a failed onboarding or close-to churn scenario.
These tiers would also be used with the existing customer base who would be offered a lifetime discount on the new pricing tiersExecute stealth price increases across the monthly and yearly plans nice and slow while keeping an eye on conversion metrics related to that funnel. Keep increasing the numbers until the funnel conversion buckles.
This does not impact new customers — only changing the pricing tables and thus newly installed users so the way they onboard can be benchmarked against previous flowFinalize the new prices and make announcement to existing customers that prices will be changing at a certain date, and add a call to action for all existing users to claim a lifetime discount by switching to those new plans now rather than later (when the promotional pricing will be gone).
Research
The first order of business was to research the current customer behaviour and to establish a benchmark as it relates to:
The number of visitors on the plan selection page
The typical number of ‘plan selections’ against that number of visitors
The typical breakdown of selections between all available plans to understand which plans tend to be chosen
By keeping an eye on how the number of plan selections change (from each phase above), I can form a holistic understanding of the high and low level impact of my changes:
First, does the overall selection conversion change? Has the change meaningfully impacted the number of users down-funnel?
Second, has the breakdown of plan selections changed?
Are customers choosing more expensive plans as a result of the changes?
Are they choosing plans with the features that we have released, only available in larger tiers?
Does the increase in more expensive plans more than make up for any losses in plan selection conversion?
In the end, what is the ideal scenario to optimize pricing relative to run rate?
Since I know how likely each install is to select a given plan (based on 12mo+ of data), I can get an idea of what will happen if, say... I double pricing but suffer a 20% decrease in conversion at the plan selection?
In that case I'd still manage to boost MRR run rate by +37% even if customer acquisition slows 20%
Cut customer growth by 20% but increase revenue growth by 37%.
Worth it.
I started playing around with different scenarios, the most important options being options that increase ARPU mostly through increases in prices to the larger plan customers who are currently paying too little for the value they receive.
I assigned conversion decreases ranging from 10% to 20% which I expect to ink in as I discover the thresholds and impact of my changes.
Importantly, having an Unlimited plan altogether is not ideal — you should be charging a concentrically larger amount to each larger customer with no real cap.
The thing is there comes a threshold where spending hundreds or thousands of dollars on this solution would be a non-starter, leading to the hire of developers or using competing solutions.
In that regard, it was clear there is an advantage to having a smaller plan as it represents a strong amount of demand for the product, but not at the cost of hurting the ARPU.
So the price increase would gradually be steeper for each plan. The result of this being a proper price anchoring mechanism.
Your SaaS prices should go up geometrically with each additional plan, not linearly.
This approach makes sense. A large store with thousands of orders per month won’t sneeze at $99/mo while a small ecommerce operation under 100 orders per month is far more price conscious.
Naturally, these changes can have a dramatic impact — hopefully good.
But I wanted to ensure that the roll-out would make sense and would have some natural continuity as it relates to the reason and justification for increasing prices.
I have several changes to make, so I’ll make them sequentially while keeping an eye on my metrics.
Pricing Roll-out
Running growth experiments is a matter of discipline and process.
You need to be conscientious regarding each detail you’re testing for and have both the means of implementing your test, quantifying the results and having a dedicated place to record results.
In the end, the purpose of this multi-stage roll-out is to reduce risk and to be able to extract the maximum amount of value from new installs using the new tools and features at our disposal.
I set up a dedicated page on Notion to govern the new pricing tiers, starting by taking inventory of all the new features we’ve released over the past few months.
In the page, I allocated them intelligently to different pricing plans so that the price anchoring mechanism would work and the new pricing plans would feel justified when compared to other plans.
In other words, I needed to communicate through the plans just how much additional value would be unlocked from upgrading to a bigger plan, additional to the number of monthly transactions and orders Reconcilely would process on a customer’s behalf.
I ended up realizing we had a lot of underused leverage.
It hadn’t clicked just how much value we’d created until I took the time to itemize each new feature and categorize them into their relevant plan.
Green rows are completely new features.
Yellow rows have been modified/adjusted.
White rows remain unchanged.
Purple rows represent hidden features unavailable to the public.
I made sure to stack each next plan with features that are highly relevant to the kind of business we’re targeting with that plan:
Starter — small stores, starting out
Standard — stores selling in single currency
Pro — high SKU stores selling in several currencies
Unlimited - high volume, high SKU international stores
The features in each plan speak specifically to those target personas who already use the app and told us what kind of features they want out of the platform.
The strongest anchor is on the Unlimited plan for obvious reasons.
To avoid overwhelm and to ensure we get clear data from each change we make, the multi-step roll-out for the pricing is going to go like this:
Phase 1: Introduce Yearly Plans
The first easy change we can make is simply to introduce a yearly plan to the page and to make that pricing plan the default selected option.
The benchmark for yearly plan selections is something like 10-11%, which would have a nice impact on the cashflows every month if 1 out of 10 signups paid up their expected entire LTV in one go.
This would not only positively influence the time it takes to payback the cost of a customer’s acquisition, but it would also set the table for increased retention and LTV moving forward provided customers are satisfied on a yearly basis.
By providing 2 months free to a product that is essentially set-and-forget, the odds we’ll see a net positive outcome out of introducing yearly plans are humongous.
Phase 2: Adjust Plan Overage Fees
For some time I’ve been mulling a shift from overage fees on a per-order basis to charging on a credit-basis.
The fact is that the overage fees in their current form completely fail to shepherd customers towards any plan upgrades because the cost difference the overage fees represent is a smaller delta than the cost of upgrading to another plan.
In other words, it’s cheap to go over plan than it is to upgrade.
If it costs $0.04 per order over limits of the $9 plan, then 100 orders would cost barely cost $4 for a total of $15 (the next plan is $17). If only 50 over, that would barely register $2 extra.
So not only do customers not upgrade, but the revenue generated from overage fees is completely useless.
This issue is easily visualized.
If these numbers were 10x higher, I might not mind since that would represent a meaningful share of our revenue. But they’re not.
The overages should be playing a crucial role in pushing revenue expansion but the impact it brings represents a drop in the bucket for both customers and the app, nullifying its purpose.
To solve this, I’m increasing the cost of overage and simplifying the process of charging those overages rather than billing cents at a time to kill two birds with one stone.
Moving forward, the overages will be billed $3, $4 or $5 at a time rather than $0.02-$0.04 per order. This will have an immediate on the impact of going over on both the customer and Reconcilely’s one-time revenues.
Next, we’re jacking up the cost of going over from $0.02-$0.04 per order to $0.15-$0.25 per order depending on the plan.
That will increase the impact of the total spend implied by going over versus upgrading.
Spitting pennies might not phase you. But quarters add up quickly.
Once we layer on the additional features we’ve released which will be gated behind larger plans, this effect will magnify further.
Phase 3: Populate New Features
Provided we are seeing stable conversion rates after the first two phases, things are looking pretty good and we can set the table for the final phase.
The best way to justify a pricing increase is to constantly create additional value for customers without asking for anything in return.
We release new and innovative functionality in a sort of stealth beta by maintaining a very basic allow list that determines whether an existing customer can access a given new feature.
This bootstrapped feature-flagging allows us to selectively invite merchants who ask for these features to try them in a closed beta.
That allows us to move quickly with respect to those customers’ feature requests (rather than bogging down in process trying to make it completely production ready) while reducing the surface area to the customer only should a beta feature go wrong.
Once we know the features work well and answer the use case properly, we can decide which feature to gate it behind, battle-test it, and then release it publicly.
My original idea was to have a single plan based on the merchant’s revenue size and to serve each of these features as a buffet of a-la-carte plugins you could pick and choose based on your use case.
But the migration from what we have today to that is quite a leap, one I’m not inclined to make at this juncture.
Perhaps once we launch QBO, there might be enough user volume to test the impact of such a change on a small but significant user sample without affecting the rest of the userbase.
Phase 4: Change Pricing Amounts
As long as our plan selection conversion and breakdown stay healthy (or improve) after the 3 phases, we’ll move to the final move which is to increase the plan prices to our prescribed numbers.
This is where stellar execution matters most:
The ideal change would be to change the pricing for all existing users.
Obviously, an 77% increase in MRR would be game-changing.1
We provide far more value today than we did a year ago, and if you want to keep that value, you’ll happily pay a more fair price to keep that value.
This reminds me of a demo I had this week with a new customer who called us a hidden gem and extremely underpriced — this was a Shopify Plus customer who said $99/mo was more than fair for the value offered. Perfect.
We can produce a pretty dramatic impact on the runrate by ensuring the pricing changes only affect new customers. And we can do that by grandfathering all the existing customers and changing our plans, which only new installs would see.
How you grandfather is really important so as not to tie your hands with regards to existing users.
They should eventually have a way to upgrade, especially to access features released after they were grandfathered.
And that’s the approach we’re going to use here.
The 500-some active merchants currently on the different feature plans will get to keep paying the price they currently pay — forever.
If you want to keep your current setup with the same features at the same price, forever, you can.
However, the features they have access to are only the features they’ve had access to until now.
If they want any of the features releasing under the new plans, they’ll need to upgrade to gain access. Otherwise, long-time loyal customers can continue to pay their current price in exchange for the exact same functionality.
To incentivize existing customers to upgrade, a time-limited promotional discount can be offered on all of the new pricing plans, the total price of which would still represent an increase over their current spend.
This is why we have promotional pricing plans.
Those remain hidden outside of the public pricing plans but can be used to populate a one-time offer for either existing customers upgrading away from grandfathered accounts or within the scope of another use case like support or downselling.
Thus, existing customers looking to upgrade will be able to do so while claiming a lifetime discount on the new plans.
The discount they can claim climbs based on the pricing plan, with the largest and most valuable plan offering the steepest discount, the type that can build just enough FOMO to cause an avalanche of revenue expansion.
Since we’ll have introduced yearly plans by then, large customers who already use Reconcilely in the long run might elect to lock in this price ahead of time, leading to a massive increase in both cashflow, run rate, retention and lifetime value.
Learnings & Adjustments
We’re just vibing this month, setting the table for the future while keeping our hands in the present.
I wouldn’t change anything for the world right now.
I’m in my zone of creativity and genius, am learning every day and meet smart and interesting folks every day who are both optimistic and deliberate about contributing to that future.
We are forever grateful that this direction is even possible. This entire thing could have been a bust from day one.
Instead, its potential is starting to become more and more obvious and the activities we complete help us progress ever closer to that.
With six months left to the journey, I’m really excited to see how fast things continue to evolve both here and for the DAO.
And I’m so glad to bring you along for the next ride!
Until next time.
Thanks to MicroAcquire, Arni Westh, John Speed, Henry Armistread, Ariel Jalali & the many other silent sponsors.
→ Sponsor MicroAngel here ←
Note that unlike apps running on Stripe, Shopify Apps bill through Shopify itself. And the subscription mechanisms offered by the API makes it impossible to automatically graduate a customer from one plan to the next.
Since you’re stuck having to explicitly ask the user to upgrade to a new plan, the only way to force an upgrade is to lock functionality to the customer and send an email saying ‘hey, we’ve increased our price. your stuff has been paused until you pay up,’ which suuuuuuuuucks.
Since new customers explicitly select a plan (during onboarding), new plans can be introduced to new users without impacting the current userbase whatsoever.