MicroAngel State of the Fund: September 2021
MicroAngel State of the Fund: September 2021
Building/training team, expanding Shopify ad spend, reorganized & improved Reconcilely code & paternity. Closing MRR: $23.8k
Good morning and evening to you, and thanks for checking in on the MicroAngel journey!
Between the Jewish high holidays and a two-ish week paternity, I didn’t allocate much time for focused work in September. Yet the machine continued to hum and cash on cash returns have continued to grow.
All things performance are green this month with continued growth from both Reconcilely and Postcode Shipping as Fund 1 crossed the $24k MRR mark, up 7% since last month to a combined $24.8k MRR.
Eric has been fitting in really nicely with my workflows and has taken ownership of his role with great pride.
So much so that he’s jumped head-first into the hairiest challenge he could find, and in doing so has set us up for rapid acceleration and cost reductions on the engineering front.
We’re also onboarding the Postcode Shipping support team to Reconcilely, producing an economies of scale effect between the two products for the first time as they now share support costs.
Spending on support certainly can affect cash on cash returns, but that’s still better than paying corporate tax, which is now a factor considering I’ve rolled up the products I bought personally into a holding corporation to enable the sale of equity to present and future MicroAngel partners.
I’m also excited to be working with Youssef from DesignDash to work on the portfolio’s product and marketing design.
We’re kicking off a first project within the scope of a greater design and user experience strategy that’s sure to take things to the next level for both Reconcilely and Postcode Shipping.
Lastly, I collected some data from my customer acquisition tests on the Shopify app store and found some results suggesting even more profitable returns aren’t too far away.
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)
We’re in a nice hybrid of fixing and improving between Reconcilely and Postcode Shipping right now. I like the pace of things. We meet every morning, run a lean scrum, and get on with our days.
While producing the roadmap proved to be a valuable strategic exercise, we didn’t do a great job of kicking it off on-time as we made a high-level decision early-on to deal with technical debt and any technology hiccups we weren’t super comfortable with.
Simply, we found that delivering the roadmap on-time was not possible given the existing debt and lack of flexibility with the code.
Early on with Reconcilely, I made a few small changes to the way the product behaves, but left the large deliverables to later because they felt like expansionary activities that could wait while I fixed more pressing issues.
Part of why I wanted to bring on a dedicated engineering partner at MicroAngel was to take the time needed to thoroughly investigate technical challenges so as to approach them from the most efficient angle.
As we finalized the roadmap, it became evident that certain things needed to be adjusted and/or re-piped for our own sanity, lest we would begin to fight with code we were too unfamiliar with and where developing that familiarity would mean spending an unfathomable amount of time and energy we didn’t want to waste.
I was prepared for some refactoring on my own, but the exercise felt a lot like working on Rube Goldberg machine due to the state of the code and how rushed it felt.
Considering the value encapsulated in the deliverables we want to deploy over the next 6 months, it made a ton of sense to take a step back and burn a month or two if necessary, but come out of it with much more flexibility and confidence as it relates to the code base and our ability to manipulate and extend it with new features.
On the fund side, I’ve been busy pushing papers in preparation for the next phase of MicroAngel I, which is to acquire a third product by leveraging the free cashflows it will represent as well as the combined revenue of the two initial products.
If done well, this third product could effectively be acquired for very little out of pocket provided some creative financing.
In that spirit, on my to-do list is to produce historical activity for both Reconcilely and Postcode charted over the past 18-24 months, so it can be possible to make the case for a cashflow-based loan about 4-6 months from now.
I spent a solid chunk of the month interfacing with my lawyer to re-capitalize the company I’m using for the fund while producing a new partnership agreement intended for Eric and future partners.
My newest daughter was born on September 3rd, which kicked off a wonderful two-week paternity during which my wife and I took the time to rest and welcome our child into the world.
This gave Eric plenty of time to dive into the Reconcilely refactor, which benefited him greatly considering he now understands the code as well if not better than I do.
As of today, our focus, in order of priority is the following:
Finalize onboarding the support team to Reconcilely
Hire & train selves out of daily support triage
Work through all open bugs/issues collected through support
Begin delivery of roadmap-specific features
That means the roadmap is effectively blocked until 1/2/3 are completed, which is not ideal but represents the correct tactic as it relates to the compounding returns those tasks will represent in the not-so-distant future.
Another way I’m reinvesting some of the excess cashflow into the portfolio is by onboarding a fractional design partner who can deploy UI, UX and marketing design activities on an ad hoc basis for me.
This is a much more affordable option than hiring full-time as I don’t have enough work nor the budget to justify that option, while collecting at least some of the benefit such an asset would bring to the portfolio.
The support team is about to kickoff with Reconcilely for the first time, which means I won’t be running front-line support anymore and will focus all of my time on product and growth.
In a way, building the team so far has helped to validate the kind of internal team that would be appropriate in the scope of second and/or third funds that introduce squad-based micro-entrepreneurship within higher-tier products.
Now that engineering, support and design resources are in places, I would love to figure out what kind of marketing resource would be most appropriate to onboard to fully enable the squad model vs DIY.
I’m toying with the idea of hiring a contract writer or two versus hiring a director of marketing who can spend all of their time further developing our lead generation systems. I don’t want to overbloat the costs needlessly, though any up-fron t investment that accelerates the run rate downstream is likely worthwhile.
While the cash on cash returns go down due to the additional costs, potential and speed both go way up.
You get to go further vs. faster.
Fund Activity
Funds Deployed: $573.5k
Products: Reconcile.ly, Postcode Shipping
Closing MRR: $23.83k (165% to goal)
MRR Growth: +7%
30-day Revenue: $25.07k
Rolling cash-on-cash return: $79.39k (+14% / +0.14x)
30-day ARR growth: +$19.32k (+7%)
Cumulative valuation increase: +$616.37k (+107%)
Current Total ARR: $297,468
Fund valuation @ 4x: $1,189,872 (+107% / +2.07x)
9-Month Return (MOIC): +121% / 2.21x
Headlines
New baby + short paternity break
Portfolio passed $24k MRR combined revenue
Reconcile.ly passed $7.5k MRR
Postcode Shipping passed $17k MRR
Signed on @YS as a fractional design partner
Reached Fund 1 Valuation goal ($1m / 2.00x)
Reached 82% of Fund 1 total return goal (2.21x of 2.7x)
Sourced lending options for Acquisition #3
Re-capped old corporation as a holdco, rolled Reconcilely and Postcode into it and emitted new class of shares for present and future MicroAngel partners
Postcode Shipping focused on workflow assimilation & training
Reconcilely focused on some code refactor & technical debt
Posting 100%+ ROAS from Shopify Ads over last 6 months
Reconcilely
Things have continued to progress in the right direction for Reconcilely as it reached the $7.5k MRR mark
I really should adjust that -20% column by now. I’ll get to that when I start working on the admin section improvements. Gotta stay focused on what actually creates progress and results.
Merchant growth has been pretty constant. We’ve added 21 new customers across the month, which goes to show how strong the conversion rate is from customers installing the app.
Which is a good omen for ad spend — the mild success implied by a 100%+ ROAS means I’ve been increasing budget to the ad campaign for Reconcilely.
It doesn’t look like there’s a ton of volume for me to capture, but it’s qualified lead generation I’m happy to compete for and build on top of.
Back in February, I kicked off a small paid acquisition experiment to see whether I could reliably buy MRR in the place most likely to produce qualified leads (the app store itself).
On about $3.2k of spend, here are the general notes:
CTR of 3.2% for 531 clicks and a CPC of $6.06
Install rate of 20.5% for 109 installs and a CPI of $29.55
Conversion rate of 56% for 61 customers and a CAC of $52.80Current return: $3,286 (102.1% ROAS)
Current LTV: $261
Expected captured return: 61 * $261 = $15,921 (494% ROAS)Verdit: Pump it!
The reason I let this experiment run for a few months is because I know Shopify’s reporting is off by a little while, and the ROAS grows over time as your partner account collects payments from customers having signed up through an ad campaign.
The app currently posts a LTV of $261 and an ARPU of $18, for a lifetime of about 14.5 months. I can expect each cohort of customers to stick around for that long, which will further grow the ROAS.
Specifically, these 61 customers should collectively produce $15,921 in lifetime value, which would represent a ~500% ROAS, which is fantastic.
At this point, I’ll leave the campaigns to run and begin developing additional channels to hopefully achieve similar or better results.
Of course, once I reach a certain volume of users, I can start recycling activity from one channel to another.
For example, all the impressions I pay for via Shopify ads should be recycled within Facebook, Youtube, Reddit, Twitter and LinkedIn audience pixels, enabling me to reach the same customers with greater accuracy and frequency without having to needlessly wade (and spend) through unqualified traffic to retarget them.
On the product side, I’ve been working on refreshing some of the transactional emails we send to customers, both from a functional and design perspective.
I’m liable to refresh these again once Youssef and I are done touching up the Reconcilely brand, but for now, the improvement is pretty obvious to me.
We’ve developed a brief outline and purpose for the new marketing website, which should be a net improvement over what is currently available at reconcile.ly.
Importantly, the new website’s purpose will be to rank higher for search terms that the app already ranks for naturally, and to do so by rapidly increasing the number of pages on the domain within the scope of a logical website sitemap that accurately answers search demand.
SEO isn’t exactly my strong suit and a skill I’ve been meaning to develop into a primary asset for growing micro-SaaS products. I’m excited to start investing into it and look forward to seeing whether my hunches are correct.
Finally, Eric is putting the finishing touches on some major repiping in Reconcilely’s highest level documents with the singular goal to significantly reducing the app’s overall database load, in and out of core processes.
The original seller wrote Reconcilely’s code in a huge rush and it shows, as that rush made way to paranoia about things breaking (due to the speed) which itself led to the implementation of incessant checks and re-checks and re-re-checks.
The result is a bloated, difficult to navigate landscape that I initially justified considering the critical nature of the data being transmitted on behalf of hundreds of merchants.
My hunch was that the solution was a little over-engineered but I didn’t have enough experience to definitely say so. Eric’s approach was not a full rewrite because those rarely work out the way we think they do.
Instead, his approach has been to refactor some of the app’s highest level calls and the way those calls are made and to lean out the number of times (and workers) involved in the overall process.
That would produce a leaner product with less redundancies and circular dependencies and a more linear process we could both understand and eventually extend per our roadmap.
It’s certainly not a simple process because its purpose is to simplify code that inherently was difficult to wrap one’s head around.
I initially thought that was due to the complexity of the app, but today I understand how that’s not the case, and we’re working to give ourselves enough flexibility to create a development environment that is more predictable and straightforward.
Overall, the product work is slightly behind due to these moves, but when I zoom out I recognize that the timeline itself is arbitrary, whereas the activities we’re undertaking are strategic.
I’m confident we’ll rapidly gain momentum following this small change. I’m still making some improvements but trying to limit myself to side stuff so they can easily be merged into the large PR Eric will push to simplify the app.
It can be pretty scary to make a big change to the code base and to some extent, we’re expecting something somewhere to break — knowing we have the two options of (1) quickly identifying and fixing the problem within the scope of the new deployment and (2) being able to roll-back to our previous deployment at any time and re-assess.
Since the majority of the customers are in the APAC region, we can adjust the timing of our push to production so it happens when most of them are asleep, giving us some additional breathing room were things to go wrong.
No stress. We’re making the product our own, and that’s a great thing to see my new partner both lead and implement so early in his tenure!
Postcode Shipping
Additional props should go to Eric who’s become the de facto escalation option for our support team working on Postcode Shipping.
The hand-off has been progressing diligently and we’re at the stage where daily meetings are spent going over any open tickets and/or bugs and/or in-development features that we’re going to take to the finish lines.
Eric’s already pushed a few changes to production to satisfy some customer requests, and things in general are in very good, stable condition as we begin to position our thoughts for the overall strategy.
Last month, I took a meeting that could have produced a large enterprise customer but decided not to push the trigger due to the obvious ramifications this would have on MicroAngel’s global momentum — it would even affect how much time Reconcilely got, which was a non-starter.
For now, the playbook is to continue absorbing workflows and processes that have powered the value prop for a little while and keep compiling ideas and feature requests as we go, so we can become opinionated about what kind of features our customers would most appreciate.
I’m likely going to link customers to a feedback survey across the app and within customer support replies, like I do for Reconcilely.
The survey in question has a simple purpose: to collect information from existing customers about the how and why of them installing and paying for Reconcilely:
Will use a similar survey for Postcode Shipping so I can better understand what drives the value proposition and what specific language customers use to describe the pain that our app solves.
The area we are most going to work on is the retention of new installs. Last month was a great example of the main improvement required to really unlock the growth for Postcode Shipping.
Despite being much younger, Reconcilely has a much stronger natural affinity to retain the installs it works hard to get.
That means that despite only registering 49 installs in the month, Reconcilely ended up with more net installs than Postcode Shipping did.
This is likely due to the general complexity of an app like Postcode Shipping — as it relies on actual effort to decide what rates should be used relative to user’s postcodes and the products they have in their carts.
That in itself can create some friction for new customers, but there’s also the general requirement of the app for merchants installing to have access to Shopify’s carrier rates, which is usually an Advanced Shopify plan feature or better.
That said, merchants who have smaller Shopify plans can still access the feature by prepaying their plan for the year ahead and getting in touch with Shopify support to unlock the feature.
The reality is that any merchant can install the app, and we know the vast majority of merchants using the Shopify platform aren’t big. The app is made for a niche, and that niche leads to fantastic retention, but not amazing conversion up-front.
The goal will be to introduce new features that decrease the general friction in the onboarding process so a greater proportion of installs can feel they can be successful quickly without having to invest a ton of time.
That is a clear area of improvement where innovation can make a huge impact across the board. In our case it’s improving net installs.
Win a Business via The MicroAngel Awards
Guess what!
The MicroAngel Awards pot is up to $2,300 👀
I think we’ll try the first edition when we reach a $5,000 pot.
The idea is that most of the revenue generated from this very newsletter is going to feed a MicroAngel Award pot up to the point that it is worth something like $5k.
When that happens, all is fair to market yourself as the person most worthy to win the business.
The MicroAngel Awards will see one lucky person be awarded a MicroSaaS business to grow and market.
The deal:
you’ll become CEO and own 100% of decisions
you’ll own 100% of the cashflows generated by the business
you’ll own a 30% equity stake in the business
you’ll choose what to build and how, pay yourself or reinvest
you’ll get 2 years to make the most out of the MicroSaaS before it gets sold
To qualify:
you need to be a MicroAngel paid subscriber (which means you’re effectively contributing to the pot)
you must commit to building in public, mostly via Twitter and co-writing on this very newsletter
mention @microangel_ with your pitch explaining why you should win — this is build in public from the start
you should have the skillset needed to succeed in the game, which generally means you can code and/or market and are very resourceful about what you cannot personally do
If you want to be a sponsor, please get in touch with me over Twitter. Otherwise, be sure to subscribe to both contribute to the pot and gain a chance to win.
My goal with this project is to help more people become microangels while testing a theory in decentralized microinvesting, the likes of which has the potential to completely revolutionize how angels deploy capital in the future.
Learnings and adjustments
Another month heading due North, with mostly good news across the board.
I’m satisfied with the general direction of the portfolio, but want to start giving more attention to marketing systems, especially within the scope of Postcode Shipping whose customer acquisition has stalled somewhat.
Most of the growth for Postcode Shipping this month came from ARPU growth, itself a factor of a pricing update that is slowly propagating across new customers signing up.
The main learning is not to wait too long before building customer acquisition systems and/or at least deploying early experiments that can yield intelligence in the future and guide the kind of actions most likely to produce strong MRR growth.
The arrival of Youssef is going to produce a profound impact on my ability to rapidly design and deploy marketing collateral across a variety of ad campaign experiments.
While the original purpose of the engagement is meant to be temporary, I’d love to develop a long-term partnership the unit economics of which are compatible and justifiable vis-a-vis the free cashflows of the portfolio.
It’s time I start developing the mechanisms to support a squad-based model as that represents the next iteration of this project and the one most likely to enable the scale I’m dreaming of.
They say “if you wish to go fast, go alone; if you wish to go far, go together.” I’m a big believer in this approach.
Fractional services can be a huge lever to pull on so I can mechanically increase MRR without having to manage a large payroll and while retaining the awesome ability to shed costs and post a high profit margin for future acquirers.
In the meantime, we’ll continue to show up, execute the plan, and hopefully maintain the great momentum we’ve built for ourselves so far.
Please accept my apologies for the lack of content on the newsletter lately. Neither the motivation nor the energy have been abundant until only recently, and my reaction to write as a means of therapy has suffered for it. I’m working on it. Promise.
Until next time!