Thanks for checking in on the MicroAngel journey!

We’ve just closed month 10 of 24 for Fund I, which means we’re just two months away from this experiment’s halfway mark.

Already…!

This month was one of the more rough months on record so far, though it was easily one of the most active and productive.

At the beginning of the month, Eric and I swallowed the frog and kicked off a large, painful refactor of Reconcilely’s most critical systems which were now pushing up against the platform’s vital organs in ways that made it less reliable to customers and much more painful to improve for us developers.

Unfortunately, the large refactor didn’t initially go as smoothly as we’d hoped. As we deleted swathes of old and deprecated code from Reconcilely, we grew our exposure to the very real risk of something falling through the cracks and causing a system-wide issue.

As we deployed our upgrade to production, the server logs began to run red with errors.

It was fucking terrifying, not gonna lie.

Can you imagine seeing this? It’s probably every SaaS owner’s worst nightmare.

Thankfully we had just redone all of the server logging so to us, it just felt like another Tuesday. Like… It’s OK. Shit happens. Let’s just take care of it right now.

Support queries exploded with customers puzzled as to why their payouts were stuck and quite a few customers who joined in the month decided to pack their bags and uninstall the app amidst the very bad first impression we’d made upon them.

The first half of the month saw Reconcilely reaching $7.9k in MRR only to lose several hundred of those to customers unhappy with the way the upgrade had gone.

During the crisis, we were faced with a few options ranging from curling up in a fetal position to rolling back our changes to tightening up our positions and marching straight to the problem’s source.

In the scope of two painful weeks of hardcore engineering and firefighting, the platform upgrade was finally completed, and alongside it, a massive increase in performance, reliability and flexibility.

It was a wild, wild ride, but I’m glad we both (a) actually got through it and (b) used it as a growing experience between partners, as it was our first opportunity to really test our mettle and grow our relationship.

It was tough, but necessary. We had to run through the fire regardless of the risks because the risk implied by not doing anything grew by the day as we continue to acquire new users.

Amidst these challenges, I spent most of my time this month empowering the support team for Reconcilely by upgrading our admin panel with a variety of new tools to reduce the time it takes to service a customer support query while growing the use cases that the support team can handle without escalation.

Despite most of our attention going to Reconcilely, things have gone mostly swimmingly on the Postcode Shipping side, with a few small fixes required to close up support requests that have been repeating over the last few weeks.

We’re coming up on the middle-section of the Improvement phase, the purpose of which is to grease the wheels of an already working system and to enable a paid acquisition model granted strong user economics relative to the market.

We’ve also been working on a new marketing website with Youssef and that’s heading in the right direction. The expectation is to launch it by year’s end sometime with the intention of creating hundreds of page in a short amount of time.

All in all, it was a rough but necessary month. In the end, we came out of it with a stronger product and processes, but some of the worst churn we’ve experienced so far in the portfolio.

As if you needed more proof that improperly managing customer expectations will make it very difficult to grow a subscription business like a MicroSaaS.

I’m looking forward to the coming month as we start to deliver customer-centric features. With most of our code going into the Admin CP this month, it felt like we were starting to over-optimize an area that didn’t directly contribute to new MRR.

This month’s main goal is to implement and deploy a customer data strategy so we can keep track of the KPIs responsible for unlocking paid user acquisition moving forward.

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: $24.19k (165% to goal)

• MRR Growth: +0.7%

• 30-day Revenue: $24.2k

• Rolling cash-on-cash return: $102.65k (+18% / +0.18x)

• 30-day ARR growth: +$2.16k (+0.7%)

• Cumulative valuation increase: +$579.4k (+101%)

• Current Total ARR: $288,228

• Fund valuation @ 4x: $1,152,912 (+101% / +2.01x)

• 10-Month Return (MOIC): +119% / 2.19x

This was one of the main engineering months so far.

We’ve been trying to clean up some critical bugs and low hanging fruits to make space for an analytics implementation.

The reason analytics needs to come first is so we can quantify how much closer to our goals we are as a result of the changes we bring to the product and/or its systems.

Specifically, I’m concerning myself with the types of customers who are using our products at any time, and what metric is most indicative of the success for each section of the lifecycle.

I can cohort users of our apps based on their lifecycle stage, which then scopes the KPIs of that stage relative to the things most likely to graduate the customer to the next cohort.

First, we have folks evaluating the product. Those turn into product beginners, who then turn into product regulars, who then turn into product champions.

Evaluators

• New installs

• Listing view to install %

• Install to activate %

Beginners

• Onboarding success rate %

• Accelerate Time to value

• Trial conversion rate

Regulars

• ARPU, Lifetime value (retention * monthly price)

• Expansion rate, net churn

Champions

• Referral rate %

• Review rate %

Generally speaking, new customers/installs are barely evaluating your app amidst a sea of other options.

We have many competitors, which means it isn’t impossible for a customer to install our app alongside many others and to make a decision about which to stick with.

Similarly, customers who have made it into the app and successfully activated become beginners of the product whose primary mission is to get successfully onboarded and experience value from the product as quickly as possible.

A quick time to value is a critical requirement to maintain a strong conversion rate, especially within the framework of a trial. Reconcilely has a trial from install, whereas Postcode Shipping has an unlimited trial option.

I have to adjust the beginner’s experience relative to those business models and remove any friction from the first experience so they can reach a positive decision about continuing to use the product moving forward.

By the time I’ve earned a new user’s trust, I can become more concerned with the ARPU I manage to collect (through various features enabling various pricing plans) and focus my expansion work on the cohort of regular users, which make up the bulk of the apps’ recurring revenues.

Finally, it’s important to have a way to quantify and identify product champions, those customers who would happily leave a review or participate in a case study. This is the cohort of customers who already recommend us.

GOAL: To improve the above KPIs and present the appropriate unit economics to support a paid user acquisition model across a variety of channels.

Reconcilely

MRR growth slowed this week as a result of the churn caused by our engineering mishaps. Despite this, we ended the month at +$100 thanks to ARPU growth.

As we kicked off some work in the admin panel, I took the opportunity to review my MRR dashboard for the first time and compile additional information, from a dynamic ARR/ARPU calculation to getting an idea of what share each pricing plan occupies within the total MRR.

As of today, more than a third of the revenue comes from customers signed up to the Unlimited plan, which is something I like to see.

In the next month or two, I expect to release a really cheap and/or free plan to rapidly scale the installs for Reconcilely.

Considering it’s install-to-paid conversion rate is in excess of 60%, we can expect free customers to scale up to better plans provided a need for advanced functionality.

Between the free plan growing installs and future plans increasing ARPU and expansion revenue moving forward, we should be seeing the correct pressure being applied from both top and bottom.

Most of our energy this month went into upgrading Reconcilely’s core engine and ripping out or reorganizing code in just about every part of the stack.

Before, Reconcilely’s code displayed symptoms of a project that had been hastily put together as processes and the database began to break down under the load of the current number of customers.

Today, the code is infinitely more readable and accessible, more DRY (don’t repeat yourself) and recyclable for other use cases in the future.

We haven’t laid the foundation for new features as much as rebuilt the one upon which the existing product has been working.

We worked diligently on optimizing our API and webhook handling, while reducing complexity of code critical to the main functions of the product.

Our webhook response time was halved from from 0.30s to 0.15s.

Unfortunately, every additional thing we rewrote or ripped out created a new dimension by which things could go wrong.

The reason we were refactoring the code was because it was really hard to understand how certain processes worked, or it was outright impossible to work around the hacks used in the earlier versions of the app.

The upgrade was painful, but not catastrophic per se.

I say that because the severity of the issues should have produced a catastrophic response from the customers, but the nature of the product is that customers don’t need real-time data as that data is used within the framework of a monthly or weekly bank reconciliation.

For example, our webhook responses were pretty much all 404’s because of something we had changed in our webhook handling.

While inherently really, really bad, this would be catastrophic if it were something end users interact with.

As an example, Postcode Shipping provides shipping rates that end users end up selecting while checking out.

That app doesn’t use webhooks, but if it did, this kind of error would affect both a merchant and many of their customers, thereby amplifying the issue by several orders of magnitude.

Instead, our exposure to the issue was limited to the number of Reconcilely customers who had either joined on that week and/or any existing customers checking into the product at that time.

The problem was that our upgrade was live on production, was broken, and remained broken while we did everything we could to get it back to parity. In that week and a half, a bunch of customers did their bank reconciliations and ran into issues.

Though we simplified several functions, the orders or payouts of some customers found themselves in a weird state that we hadn’t accounted for.

These tickets were handled very gracefully by the support team, but they showed us the exact ceiling for what they could do for us before having to escalate, which made it important to develop new internal tools while fixing the production environment.

Eventually, we solved both of those challenges and cleared our server logs from errors and ended up with a stronger and faster platform, but with a proverbial chipped tooth considering the trust some customers place in the product had been shaken.

Today, things are back to normal on the engineering side and we’ve since collected two huge advantages:

1) We release code to production nearly every day now, whereas this was simply not something we could do in the past considering the code was amok with complexities and a growing number of bugs.

It wasn’t clear what could potentially break as a result of changing something until we rewrote how that thing works.

This is an important lesson for me as a microangel.

When purchasing, I placed a heavy emphasis on the existing code because of its potential for buy/hold, but this breaks down if you choose to grow instead of hold (as we do for Reconcilely) and are unable to do so because of the way something is written.

It might make sense to expect a rewrite, and in a way, I’ve assigned a few months to that end vis-a-vis the fixing stage of this experiment. I’m just surprised to have used up all of that time when I had originally planned it as a buffer.

2) We empowered the support team to do more without having to involve us.

As an example, amidst the issues we’d discovered during our upgrade, a few customers noticed that we had sent orders to their accounting systems despite their settings indicating us not to (oops!).

In the past, this mistake would be incredible painful to the customer who would have to manually void dozens or even hundreds of transactions.

Now we can just drop the invoice names for a shop and void them programmatically on their behalf. That saves literal hours especially if handling hundreds of invoices.

Customer support can use this tool to both process the request, apologize to the customer, and return a clear list of results from the bulk invoicing process.

This tool has already produced a 5-star review for us considering the emotional reversal created from initially having to manually void hundreds of invoices to being completely free of ever having to do that ever again.

In fact, it’s so useful that I think I’ll expose it to the merchant inside of the app. The app would do well to offer additional tools that save customers time, even outside of the scope of the internal processes of the app.

Speaking of reviews, the harshest result of the month is the 2-star review we (rightfully) earned.

In fact, this review prompted me to write the bulk voiding tool, as the customer lamented their first experience and indicated how the app had produced several invoices for them that they now had to manually remove.

It is what it is, you just have to keep rolling with the punches.

I’m following up every so often with the customer to both ask for forgiveness as well as to plead them to reconsider their review as it has a big impact on our ability to grow on the app store.

Fortunately, we reached 30 total reviews this month, which is a symbolic milestone of course and nothing more.

From my experience, 50-60 reviews is the threshold from which rankings begin to really escalate considering how few apps even have that many reviews.

On the marketing side, we’ve kicked off the spec and first design for Reconcilely’s new brand and website.

It’s just a sneak peek that is likely to change, but this is the direction we’re heading towards.

Still playing with different options for the mark but the branding is mostly on-point. It’ll be day-and-night with our current website, and I’m excited to be able to drive traffic to a destination we fully control.

Postcode Shipping

I’ve been immersing myself into different Shopify merchant communities across social media to try and better understand the type of customer for whom Postcode Shipping is the ideal solution.

Specifically, I discovered that smaller stores don’t typically run into the problem that the app solves.

A lot of customers opt for a free shipping strategy enabled by increasing the base price of the product and including postage fees within it.

I think that has a lot of merit on the consumer side, as it can very be a point of friction for customers to shop up to a cart total only to discover that total inflated by shipping fees when checking out.

Despite this, the realities of global ecommerce is that the larger you get, the less control you have over what kind of customers can find you.

This creates issue when customers outside of your usual sphere of conversions start buying product, especially if you’ve previously planned your profit margin around the postage fees you’ll incur for customers around you.

Someone can really dig into your profits by buying your products from a place that will cost quite a bit to ship to.

That’s a core pain that causes the customer to start searching for postcode-based solutions, but I’m trying to qualify where the lines between useful and not useful are for merchants across the lifecycle.

In the meantime, I’ve begun populating some Triage items for the product, mostly in the scope of collecting data from customers entering/exiting the app while defining which areas of the onboarding/first-UX should change to create a positive impact on the conversion rate.

The main play for Postcode Shipping is to increase the ARPU of customers by introducing new features. That means a lot of energy needs to be spent speaking to those customers to make sure what we release isn’t tone-deaf, and, quite the contrary, truly responds to their use case.

We’ve got 2 months left of support from the sellers which is why it’s important we start to immerse ourselves into the product — which, to the credit of the sellers, is in amazing condition.

Unlike Reconcilely, this product doesn’t need any fixing. It is incredibly well built and maintained.All we want to do is increase the run rate by optimizing the different stages of the lifecycle.

I would really love to be doing the same type of activities for both products at the same time (i.e. copy/paste), which is why we’ve been putting much more emphasis on getting Reconcilely up-to-snuff so it can benefit from the same activities that Postcode Shipping needs moving forward.

That probably starts now though, with the focus on analytics starting in November.

The plan is to implement Segment directly, but I may end up going the open source route with RudderStack, which seems to offer just about the same functionality.

Didn’t make use of the warehousing features on Segment so that’s not something I’m going to miss at all.

My interest is to implement a cost-effective CDP for both Reconcilely and Postcode Shipping that can be easily transferred to another buyer in the future while giving me the tools to quantify my changes in the present.

Win a Business via The MicroAngel Awards

The MicroAngel Awards pot is now up to $2,775. When it hits $5k, a lucky MicroAngel subscriber will win a MicroSaaS business!

Please get in touch over Twitter if you wanna sponsor. Otherwise, be sure to subscribe to both contribute and gain a chance to win.

Learnings and adjustments

It’s been a very interesting and eventful month, complete with learnings and adjustments.

More of a confirmation than a learning, I saw again how refactors never go the way we expect them to.

The difference this time is that we expected things to break (though perhaps not so violently) and were prepared to roll with the punches. It became part of the process and we were able to rapidly reposition the product.

We just kept running into new errors, but kept at it and released a clean build relatively quickly after it went completely red. It took about a week to reverse the damage our app had done for a few of the customers that had been impacted.

In the end, the refactor of Reconcilely was a necessary step to let the product grow out of its limitations and to enable us to develop it to its full potential moving forward.

I might be making this sound much more severe than it really was. I just know that someone with less experience and more debt (or investors) would have completely freaked out over what is a qualifiedly fucked up and scary situation.

Admittedly, I’d love to focus only on growth and marketing but am continuing to stay patient with Reconcilely specifically as my contributions into the product are still quite valuable at a time when that’s the most important missing piece.

As Eric gets into a good flow of releasing some of the new features (now that we feel so much more comfortable with the code) that we have on the roadmap, I’ll graduate naturally over to growth by taking the stuff we are building and turning that into materials to communicate with and acquire new customers.

In the hopes of this update finding you well, I’ll catch you next time!¹