MicroAngel State of the Fund: July 2022
Yearly pricing boost, new team member, support platform migration & cash-on-cash acceleration. Closing MRR: $26.6k
Good morning and evening to you fellow Microangels!
I’ve just completed month 18 of 24 for Fund I, which means we’ve officially completed 75% of our journey to transform $500k into $1.5m, which we officially managed to accomplish last month.
The breakdown as of today goes something like this:
capital invested 18 months ago: $573.5k
cash returns collected over past 18 months: $328k
current cash-on-cash rate: 4.7% per month, 56% per year
minimum valuation: $1.277m
total value against invested capital: $1.6m
total multiple on invested capital: 2.8x
We’re fortunate to have 6 more months ahead of us to reap additional cash-on-cash and valuation growth before we expect to exit our investments.
Exciting news as the monthly cash-on-cash rate has been increasing as a result of our efforts. Cash on cash represents our monthly cash proceeds returned against our initial invested capital for fund I, which is $573.5k.
This is significant because our return is growing every month as we grow MRR.
That means we can get a general sense of our cashflow over the next 6 months provided the growth rate remains constant:
Based on that trend, we should be billing upwards of $200,000 over the next 6 months.
Were I to sell the whole portfolio today, there would be a $200k premium on top of the valuation to account for the cash-on-cash we’d give up from selling before fund maturity.
Since we’ve collected $328k in cash over the past 18 months, if we sell at the scheduled maturity date of February 2023, our total cash-on-cash proceeds should be somewhere in the $530k range, which is disturbingly close to our initial investment of $573.5k.
Thus, it might make sense to push maturity to April 2023, when we’ll have hit that exact number. From there, the exit proceeds would be pure profit, which is equal parts hysterical & magical.
Interestingly, we’ll bill 38% of our proceeds ($200k) over the last 25% of the experiment (6 months of 24). This represents the compounding force implied by increasing MRR over time.
You’ll make most of your cash-on-cash at the tail-end of your investment, so taking your time finding the right exit partner delivers more than one advantage in that regard.
Most of the energy over the past year and a half has gone towards one of the two products in my portfolio, Reconcilely, because its ceiling is theoretically higher, though the work required to extract it has been considerable so far.
Compared to last month, the share of portfolio revenues coming from Reconcilely has increased from 29% to 33% as a result of a successful experiment involving yearly pricing plans.
So we’re on the right path there, but also overall.
It’s especially special to be reporting solid growth during a month when I took off for a week.
Thanks to the amazing group of people supporting me, things continued to hum along while I was gone, and we’re back to building momentum now that I’m back.
100+ subscribers 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.
Current fund lifecycle stage
✅ Buying (02/2021 - 05/2021)
✅ Fixing (06/2021 - 08/2021)
✅ Improving (09/2021 - 12/2021)
→ Growing (01/2022 - 12/2022)
Roll up (1/2023)
Exit (2/2023 - 4/2023)
I’ve adjusted the remaining timeline to exit sometime in April, so we have enough remaining months (8) to fully recuperate our initial investment and give ourselves a pure profit exit.
Fund Activity
Funds Deployed: $573.5k
Products: Reconcile.ly, Postcode Shipping
Closing MRR: $26.6k
MRR Growth: 2.51%
30-day Revenue: $26.67k
Rolling cash-on-cash return: $328k (+57% / +0.57x)
30-day ARR growth: $7.82k (2.51%)
Cumulative valuation increase: +$703.35k
Current Total ARR: $319,212
Minimum valuation (4x): $1,276,848 (+122.64% / +2.22x)
18-Month Total Return (MOIC): +179.64% / 2.8x
Started off the month by welcoming Zubair Mohsin to the Microangel core team.
He’s our first dedicated hire for Postcode Shipping, which has languished for the past several months as we committed most of our energy into Reconcilely.
Zubair’s mission is to work with me to produce the new functionality required to introduce new pricing plans to Postcode Shipping which will effect a large increase in customer acquisition, revenue expansion and lifetime value.
On his first month, he’s dealt with a backlog of postcode shipping bugs, and we’re now preparing a roadmap of improvements to meaningfully impact MRR in the short term:
introduce a limited capacity free plan to boost installs
release a shipping demand analytics feature
release a shipping rates multivariate testing feature
release a shipping estimation widget feature
wrap new advanced features into a $49 advanced tier
kickoff cross-selling to and from Reconcilely
If we can manage those changes over the next 6 months, the Postcode Shipping runrate should rapidly accelerate and further increase our returns and/or exit multiple.
Thanks to this hire, Eric is now fully focused on Reconcilely, and I’m going to be jumping in between both products to increase value and runrate.
Our amazing support team still deals with both apps.
App Store Requirements
This month was expected to be mostly a write-off in terms of product momentum.
That’s due to the number of requirements we received from Shopify’ and Xero’s app store teams.
I’m happy that the Shopify requirements are mostly out of the way though.
We’re still waiting on some information from Xero, but things are headed in the right direction so we don’t shoot ourselves in the foot nor waste too many engineering hours in pursuit of keeping things afloat.
Support Platform Migration
For the past few months, our support team has communicated some significant distress as it relates to using the same workflow to manage support requests across different support platforms.
Specifically, weird workflow differences come into play when the customer reaching out for support expects a quick reply (on live chat) versus a useful reply (support ticket).
Furthermore, there is plenty of wasted energy and time implied by having to context-switch between one platform and the other, and work done to automate the support of one product doesn’t benefit the other product, which is kinda dumb.
At the moment, Reconcilely runs on Intercom and Postcode Shipping runs on Helpscout.
The issue I’ve had for some time is that Intercom is stupidly expensive.
Other than Crisp.chat, there isn’t any other product out there that offers Intercom-level functionality without costing several hundred dollars per month to operate.
I don’t love the idea of moving Postcode over to Intercom because that will create two undesirable results:
Customers who have become accustomed to support tickets will now receive live chat support when they don’t necessarily pay for it — it’s a mismatch in terms of customer expectations
It will result in a net positive increase in support costs since Intercom is far more expensive than Helpscout is.
Postcode Shipping’s helpdesk is actually standalone and powered by us directly, so there won’t be any migration required for that part of the support stack.
Similarly, we can’t quite move Reconcilely over to Helpscout because it doesn’t have a knowledge base feature as we need it and the Reconcilely userbase has become used to live support as a value-added feature.
The only alternative is to move both Reconcilely and Postcode Shipping to a completely different support platform, but that feels like a completely unjustified move that will backfire.
I don’t want to do anything that doesn’t add MRR, so this option is a non-starter that expands the scope of this migration beyond reasonable boundaries.
Thus, the only move that makes sense is to migrate Postcode away from Helpscout over to Intercom.
It’ll create a net increase in support costs for now, but at least it won’t result in wasted time, needless workflow changes or decreased support value for Reconcilely.
Pricing Increase Adventure
This has been such a fun experiment to plan, execute and measure.
Last month, I discovered that annual plans made up 57% of plan selections during my yearly plan experiment.
Based on the experiment, I estimated that cashflow could increase by as much as 40% as a result of the yearly revenues being selected month after month.
We ended the month with a 14% increase in cashflow, but that could have been 30% had we not messed up a small but critical part of yearly pricing for Shopify apps.
You see, Reconcilely has thus far been creating Shopify subscriptions on behalf of its customers using the REST endpoints of Shopify’s Billing API.
Those endpoints are slowly deprecating since the release of the GraphQL API endpoints some time ago, but they still work and to this day, we never saw the point of touching our billing code just because there was a new version of it.
To create a subscription, you basically have to send Shopify an object representing the details of the subscription — the name of it, the price, any extra charges, any trial details, the amount billed and importantly, the interval of the subscription.
Naturally, when we released the yearly plans, we set them up so the interval we sent out to Shopify (when a yearly plan is selected) would use the ANNUAL interval. This way, the amount of the subscription would be billed once a year, as expected.
Midway into the month, I checked into our Shopify dashboard to get a look at the proceeds received from merchants I had seen signing up to annual plans. I wanted to see if they had successfully converted from trial to paid, and whether we had successfully billed them the full yearly amount.
I was elated to find that multiple customers had signed up to the annual plans. But my heart sank when I noticed those customers were being billed on a monthly basis, which means the amount they had just paid was going to get billed again the next month, and every month thereafter.
When I saw per month, I audibly heard myself blurting out “That’s not fucking annual!”
I wasn’t happy.
This made no sense.
I had triple-checked the interval was set to annual. What the hell.
The problem here is that time is of the essence.
You have both customers already having been billed on what is evidently an erroneous plan and others who may be signing up to it right now.
The first reaction was an emergency production push to hide the annual pricing plans from the plan selection page.
That pissed me off because I knew just how powerful they had proven to be, but there was no way I would exacerbate the already annoying task of having to deal with the existing customers on the yearly pricing plans.
After hiding the yearly plans, I got in touch with Shopify to open an investigation.
They confirmed something was weird, but we quickly discovered the culprit, which frankly pissed me off even more.
It turns out the REST endpoints of the Shopify Billing API do not support annual plans. Full stop.
You can pass it an ANNUAL interval, and it will completely ignore it and use the default (every 30 days).
This is exactly what happened.
But wait!
The GraphQL API does seem to read the interval field, meaning you can only offer annual plans using the GraphQL API.
The fix, obviously, was to start using the GraphQL endpoint.
But of course, that had to come with its own set of nuances.
The GraphQL endpoints do indeed support annual plan intervals.
But guess what they don’t support? Overage fees.
Here we are, caught with our pants down, having to decide between yearly plans and overage fees we were planning on increasing and depending on to drive conversion and expansion.
Luckily, the math was very easy.
In the month, we earned upwards of $2,500 in additional cashflow from the yearly plan payments.
That means Reconcilely exceeded $10,000 per month in revenue for the first time, which is really exciting since we haven’t even increase prices yet.
By contrast, we earned $69 in overage fees in July.
Soooooooo…
In the end, we swallowed our pride and manually cancelled the subscription of each customer having signed up to a yearly plan and proceeded to refund their purchase accompanied by an email apologizing for the n00b move.
The hope is to get these folks back once we release annual plans again, but I’m not holding my breath for that to happen.
Lesson learned!
Overage Fees
In the meantime, we had to deal with a completely new and forced scope for the pricing adjustments since overage fees need to go away.
Overage fees have been pretty ineffective since the start because the cost of paying extra is still below the cost of upgrading to the next plan, so many customers don’t bother upgrading.
Of course, part of our pricing strategy was to rectify this by increasing overage fee amounts from $0.02 to $0.25 per order, such that the pain implied by going over plan limits would be significant enough to shepherd customers towards a plan upgrade.
Instead, not only did we lose that expansion dimension, but we also now have to adjust the user experience in the app for customers who run into and beyond plan limits.
Where previously, they’d simply continue getting value (in exchange for overage fees), we now had to decide whether we should even continue sending invoices for customers if they go above their plan.
The answer of course is no.
If there isn’t a way for us to bill customers for value provided beyond plan limits, the only solution is to force a plan upgrade.
What sucks on Shopify, when compared to Stripe, is that the merchant must specifically accept plan changes whereas Stripe enables you to programmatically move customers from one plan to the next.
Thus, when we announce the new pricing changes, we’ll also need to announce overage fees are gone — which should make most customers happy, but also force a few others to upgrade or look elsewhere for their reconciliation needs.
The problem is that we can’t push yearly plans without getting rid of overage fees (as they aren’t available in the GraphQL API), and we can’t get rid of overages without announcing that change to customers (since those over plan limits will cease to receive service until they upgrade).
This defines a catch-22 for us to solve — we need to release the yearly plans ASAP, but we can only do that after we announce the new pricing to customers.
The reason for this is we don’t want to do 2 pricing announcements.
I don’t want to announce ‘hey we are adding yearly plans and are removing overage fees’ to then announce ‘hey we’re increasing the price of plans’ just a few weeks later.
That’s amateur.
We need to limit ourselves to a single, effective pricing announcement that properly aligns customers and provides a way to get promotional pricing if they upgrade. It needs to make sense.
There is a massive amount of new value being held up from being pushed to production until the yearly pricing stuff is solved, so we need to change pricing and announce it soon while we complete the QA for all the pending PRs we want to push to production.
So the plan is to do one last pricing experiment in stealth.
I’ll proceed with the actual amount increases and benchmark plan selections to make sure conversions aren’t going to crater as a result of increasing the prices.
This is the ultimate test.
Provided numbers stay healthy, we’ll throw in the new prices into the large upcoming changes alongside the yearly plans and overage fee removals.
The last thing in the way of that is to make sure the app itself behaves properly in case you run into a plan limit, since right now all that happens is we start billing overage fees.
Since we’re removing overage fees, nothing will happen right now if someone goes over their plan limit.
Which is why I need to design user interface adjustments and paywalls where appropriate to properly call users to upgrade when they run into a limit.
Upon releasing the new pricing, we’ll announce that all customers are grandfathered — they can continue using Reconcilely as it has been before the release of all the new features going out of beta.
If they want access to those, they need to upgrade, and they can upgrade with a 20% lifetime discount if they do so within 3 days of the announcement.
We’ll also mention we got rid of the overage fees and offer all plans on a yearly basis for an additional 20% discount.
I’m looking forward to seeing the results of this change, which can have a dramatic impact on Reconcilely’s runrate which is turning red hot with the pricing changes, QBO release and new Xero collaborations.
Organic Demand
I’ve noticed SEO has been kicking off quick a bit, with lots of demand from crypto related queries.
Though much of the queries are educational, it does makes me wonder what the reality of crypto bookkeeping looks like for Shopify merchants.
It can define an interesting opportunity to simplify the process of reconciling crypto payments with accounting systems that don’t typically interact with the blockchain in any sort of manner.
We’re still quite low in the SERPs and there’s a metric-tonne of value packed away in the organic momentum.
With an average position of 36.6, there’s ways to go before organic leads start pouring into Reconcilely, but we’re headed there.
I have about 10 QBO-focused articles that I’ll be launching at once sometime this month to kickoff the capture of organic demand for Quickbooks related queries.
Quickbooks Launch sOoN
We stealth launched QBO to production and all that remains is to do some live QA and front end polish before submitting to the QBO App Store and doing a big marketing push.
Quickbooks launch is being held up by the pricing update, which we did want to push to production before releasing the QBO branch.
That way all these new installs would also provide the larger ARPUs we are after with the pricing update.
We also have a few pending requests from Shopify and Xero to deal with as well as some front-end logic to be ready for a QBO launch.
Everything’s coming up Millhouse!
Learnings & Adjustments
Mostly just full of gratitude for being able to spend time with family and enjoy an awesome work/life balance right now.
While my hands are certainly busy in the present, they’re looking into the future as I start seriously considering my next great adventure.
I don’t know yet if I’ll do this again full-time or just on the side, especially if that can be figured out.
I’d love to found something from scratch again, without any guilt as it relates to the opportunity cost it represents versus the microangel playbook of 3x’ing in 2 years — especially if I can do it again and again.
Been thinking a lot about how cash-on-cash rate growing opens up the door to compounding returns, which has been an interesting topic of conversation as the Microangel community prepares the Microangel DAO.
I haven’t done much work for the DAO itself this month, but I did spend a bunch of time interacting with web3 communities and building one of my own (for the Wizard Doodles) in the spirit of dogfooding.
I’ve learned an immeasurable amount as it relates to the how and why of different web3 communities and how our vision for a DAO might come together and succeed.
Community is incredibly powerful.
I discovered several market gaps and needs resulting from web3 crossing the chasm.
As technologies reach new levels of adoption, they change the status quo and the average adopter begins to run into the physical ceiling implied by the current generation of available technologies.
It’s a time to be building because folks want to be able to do things they could not do before, and the economic throughput implied by enabling those interactions is considerable and growing.
We’ve not yet solved the question of how to launch the DAO — which will be the main topic for our DAO Community Hangout on August 2nd (you’re welcome to join).
The main challenge is that the DAO should launch with a portfolio that enables the first auctions to offer tangible yield and not some future promise.
This assumes the DAO is making at least one acquisition prior to the public launch of the first auction, which itself implies fundraising and membership prior to launch.
The best idea so far has been to release a select number of tokens prior to launch and to sell them publicly to a KYC’d list of investors who would buy membership and fund the first acquisition.
The question becomes; if we’re going to execute a KYC’d initial token offering, should we just raise a year’s worth of funds right off the bat and do away with the daily auction?
It begs the question of what the MVP should be and how quickly we can get started investing and earning rather than infinitely trying to solve every bit and trying to launch a perfect product.
I’m looking forward to discussing this with you all and any feedback you have about today’s newsletter.
As always, I appreciate your support very much and would appreciate if you could share this newsletter with at least one connection who would be interested in microacquiring their way to financial freedom.
Until next time!
Thanks to MicroAcquire, Arni Westh, John Speed, Ariel Jalali & the many other silent sponsors.
→ Sponsor MicroAngel here ←
Micro Angel is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.