I made a small scheduling mistake on Substack which delayed this update from appearing in your inbox by a few weeks. My bad. 🙏

A healthy and happy new year to you!

Had a lot of fun this month working on some new features for portfolio products which are going to have a large impact on their ability to acquire and retain customers in the new year.

Namely, our goal for December was to make the most out of the lull in user acquisition resulting from end-of-year store closures and new app installs being at their slowest.

Since we’d have less new interactions with merchants, we could afford to really put our heads down and create as much new value as possible during the meatiest Improvement month yet.

And boy am I glad we did that!

In the meantime, this was our first down month since the fund kickoff, and I’m attributing that slowdown to both the end of year as well as recent changes made by the Shopify App Store team.

Typically, things start to kick back up by mid- to end of January. But I’m a little concerned by the redesign of app listings on the app store.

If you’re not aware, they’ve added recommended apps at the bottom of the page, and typically, those recommended apps are direct competitors of the app itself. That means you could be spending (expensive) Shopify ads to drive traffic to your listing only for that traffic to head over to your competition.

I’m not super excited about reporting a down month, but it certainly illustrates the variable reality of maintaining a revenue growth rate off acquisition channels I cannot control.

There’s more than one reason to own user acquisition, but just as many reasons not to do that. In our case, observing consistent linear revenue growth is a luxury that enables us to focus almost exclusively on product.

Focusing on growth would certainly get us some more juice in the short-term, but at the cost of feature improvements and deliveries that customers are waiting for, which would create pressure against new revenue (in the form of churn).

But it also delivers the truth that if acquisition velocity changes, so too will our operational comfort and prioritizing.

And that’s why I’m glad to be closing up some of the most intense engineering work I’ve produced for the products to date.

I had a whole lot of fun doing it, but I also recognize some inefficiencies in my technology stack that I’ll carry with me moving forward.

Ad nauseum boilerplating can kill your vibe!

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.11k

• MRR Growth: -2.35%

• 30-day Revenue: $24.2k

• Rolling cash-on-cash return: $151.4k (+26% / +0.26x)

• 30-day ARR growth: -$6.97k (-2.35%)

• Cumulative valuation increase: +$584.20k (+102%)

• Current Total ARR: $289,380

• Fund valuation @ 4x: $1,185,408 (+102% / +2.02x)

• 10-Month Total Return (MOIC): +128% / 2.28x

I finished the year convinced about what kind of activities are most likely to produce positive momentum in the new year, and amplifying the value proposition of the products made the most sense relative to that.

I started and completed two large features which are about to open the door for pricing refactors, from introducing free plans to cutting the number of paid plans and introducing mechanisms for additional revenue expansion moving forward.

On the fund side, we’ve surpassed $150k in cash-on-cash returns in approximately 10 full months of operations. The gravy in this milestone is that I’ve recovered all of the funds I deployed to acquire Reconcilely. In just 10 months!

We’re standing at 26% cash-on-cash and adding about 4% per month, which means I’m expecting to pass 33% for the full year two months from now.

Despite having planned and executed a playbook specifically designed to produce 33% in cash on cash in the fund’s first year, I still can’t believe just how well this experiment has worked so far.

I’m planning on producing 70% in cash-on-cash returns by the end of the second year, and at this point, we’re nearly guaranteed to hit that goal.

Producing a 33% cash-on-cash return in 12 months was made possible through the actions I took over the past 12 months.

Though that may sound obvious, the main insight is derived from the fact that it took me 6+ months to acquire my second product after Reconcilely, which had a material impact on cash-on-cash volume during those 6 months — an impact I won’t suffer as I kickoff the new year with both products.

Thus, we should be adding (4% * 12) another 48% in cash-on-cash returns from February 2022 to February 2023.

This is even more spectacular than I had expected, considering it will allow us to surpass our fund maturity cash-on-cash goal of 70% with a two-year performance at approximately 33% + 48% = 81% cash-on-cash.

If we can accelerate revenue, all the better.

Otherwise, we’re still on-pace and continuing to stay focused on our goals.

We’re closing up the improvement phase for Reconcilely over the next month or two, and I’m starting to shift fully to growth on both sides. I’m giddy about it!

Reconcilely

Last month we kicked off some huge and hairy new features for Reconcilely that have been requested for well over a year by now.

We’ve lost customers due to not having those features, and don’t have as much leverage versus the competition, especially as it relates to features used by larger (and thus more profitable) merchants.

In other words, features useful to mid-market merchants like Costs of Goods Sold reporting and tracking category support for Xero meant we had to crack open an R&D process and deliver tangible business value.

It’s funny. The initial line between Product-led growth and ‘Build it and they will come’ is pretty blurry.

If the product is the main method of attracting new customers, then it makes a lot of sense to place it front and center, but I can’t imagine how I’d feel if I were to build these huge new features in a vacuum.

Forget selling the feature after you’ve built it, how will you even know what to build?

It’s fine to be your product’s user and to have an intrinsic understanding of the customer experience and what might improve it. But you’re just one data point. And your experience would only be worth one vote.

You may find that 50% of the customers who would use the feature would use it differently than you would, and that can have a very real impact on the end-result in the product, as you’d have built something you’d find intuitive, but which would feel complicated to other people, whose opinion matters more than yours in this context.

In my case, I’ve been collecting feedback and insights about both COGS and line-item splitting for a few months. At first I couldn’t even understand what customers were looking for because I haven’t run into these problems myself.

Either way, we’ve saved ourselves a lot of anxiety by keeping our sights on what our customer is really trying to accomplish.

In that regard, I’ve spent pretty much 90% of the month writing new functionality. It’s been amazing. Can’t remember the last time I got to do that. I shut out all distractions and worked on the hardest possible problems I could find.

Here’s some of the stuff I worked on.

Custom Mappings for Countries

For the past several months, Reconcilely has made it easy to regroup line items on invoices it creates by product types.

This is great if you want your invoices to have a deeper layer of detail about where sales are coming from.

We’ve been receiving feature requests from European merchants especially to extend this functionality and to let them split their line items by country, which would make it much simpler to report taxes (or sales) collected across different regions, making VAT remittance much more time and energy efficient.

Basically, if a customer from Germany buys something on the store, and that store has German VAT requirements, the merchant might elect to create a country group for Germany and define specific ledger accounts to use when processing orders and creating invoices, rather than using the general mappings.

The reason I like this direction is because it lends itself really well to a further product extension called Tracking Categories/Codes which basically help trickle this region-specific data down through the rest of Xero’s reports.

That means I could create a Tracking Category called ‘Regions,’ which might include Germany in there.

From there, when an invoice is created and a line item is attached to the ‘Germany’ option in the ‘Region’ tracking category, the value of that line item will propagate across all other reports on Xero so those reports can contain details specific to the german region, rather than one large number encompassing all sales from everywhere.

Tracking categories is pretty advanced functionality, typically only required from larger merchants which incidentally would find value in paying a little more to access such a useful feature.

That means country groups is the first step towards bolstering the Unlimited plan, which would then lend itself well to increasing the price of that plan in the near future when introducing the free plan.

The result from that will be positive pressure from the bottom (free plan increases installs) as well as from the top (better features for the Unlimited plan justify increasing its price).

This top/bottom approach is pretty much how I’ve been thinking about product for the past little while. There are a few moves that have dual advantages despite requiring much more effort.

Testing country groups has been a little challenging because custom mappings is a feature we didn’t need to refactor since acquiring the product. But it locks the app’s logic into doing things a certain way that makes handling additional custom mappings of another type quite complicated.

We’re approaching a release here, which is a top priority because VAT requirements are putting pressure on our merchants and they’re going to need to get those declarations out as soon as possible.

While I did have to work on the full stack to produce a working front-end for the settings, I’ve left the process of adjusting the app’s core logic to use the new mappings to Eric. I find that we move quickly when I can quickly materialize front-ends and Eric can use the new options to update our logic infrastructure and update our unit tests.

It certainly takes more time than working alone, but it makes it more possible to expand the scope of the work through division and conquest.

Cost of Goods Sold

This is another exciting feature because it’s easily one of the most requested ever since launching Reconcilely.

It’s also the main feature that competitors have been using to sell higher-priced product plans, which we can disrupt by making this functionality universally available to any and all paying customers.

The general idea here is quite simple:

Reconcilely makes it easy to send sales data to Xero in the form of invoices, that way you can reconcile the deposits in your bank with a matching invoice in a few seconds, removing the manual labour implied by bookkeeping and reconciliation.

The thing is that accounting for sales only represents one half of the reconciliation process.

After all, you only get a clear picture if you know how much you have leftover after your costs. It’s one thing to know how much you’ve collected in gross sales, it’s another to determine your gross profit from that.

And the only way to do that is to keep track of the costs you incur per good sold.

If a customer buys 2 items for $100 in gross sales, Reconcilely will create a sales invoice in Xero to account for the $100 bank deposit, and the invoice will contain line items to describe which items have been purchased, and what their unit price is.

COGS will accomplish a similar goal to account for the costs incurred to make that $100 sale. If the 2 purchased items cost you $12 and $15 respectively, you’re incurring $27 in cost of goods sold to make that $100 sale.

And your Xero account should reflect this $27 both from the perspective of the unit cost to add to your inventory, as well as change in inventory caused by the purchase.

In other words, when a sale comes in, you need to account for the cost of each SKU that was sold, and then credit your inventory and debit your COGS relative to the change made by the sale.

And that information has to propagate across the rest of Xero so you can get an accurate picture of your profitability at any point in time, which reconciling movements in and out of your bank accounts to account for buying inventory and eventually selling product.

We’ll be automating that entire process for our customers by first exposing all of the SKUs the merchants sells to them so they can ensure the accuracy of their costs.

Experience has taught me that a vast majority of merchants on Shopify don’t actually fill in the native ‘cost’ property of their product variants as they either manage that externally or (gasp) not at all.

With the costs, we can start debiting and crediting the inventory and COGS ledger accounts for each transaction that happens while using the cost values assigned to each SKU.

I expect to make this feature available to all customers freely. Besides gaining an upper-hand on the competition relative to their pricing plans and feature gating, we’ll also create a new dimension by which the volume of invoices we create for merchants will double.

Revenue expansion can happen for Reconcilely provided merchants send an increasing number of invoices as the pricing tiers are earmarked based on the volume of invoices that can be sent, on top of feature gating.

It’s in our best interest to increase the number of invoices we send for our merchants so they can start to rub shoulders with account upgrades that would either unlock new functionality or enable more invoices to be sent.

This engineering work has been pretty painful. I’ve come to hate Redux due to the amount of boilerplating I have to endure to get data from point A to point B.

But it gets the job done, and I’m not about to upend a product convention just out of convenience. Things do take longer as a net impact though.

As these two features release, I’m starting to move out of Product and towards growth. Namely, I’m releasing a new website for Reconcilely, which I expect to invest a lot into.

I’ve discovered how to properly render React apps inside of Webflow sites and will be using that knowledge to create a unique set of user experiences and tools on the marketing site to kickoff organic, paid and outreach-based growth.

With the new website and brand launching, we’ll release a major update to the app store listing, start some A/B tests with the app icon, and make a deliberate attempt at securing higher rankings within specific app store categories.

Postcode Shipping

As I start to kickoff marketing activities for Reconcilely, I’m going to be implementing front-end analytics for both it and Postcode Shipping as a means of keeping track and then optimizing funnel performance.

I’m likely going to touch up the website too and then jump right into an experiment per week. I’m iterating on some messaging and value props right now to make sure I have the appropriate message for the audiences I will try to reach.

By and large, there is no major change here besides some bug fixing. I’ve had the opportunity to dive into the churn incurred by the app over the last 6 months and identified the reasons why customers are leaving.

It turns out there are several features that customers would like to have access to, which have made it possible to furnish the product roadmap for Postcode moving forward, while also understanding the general feeling of the market today vis-a-vis the value proposition of the app and the shipping rates it enables.

I don’t want to open Pandora’s box here especially with Eric still being so focused on Reconcilely, but I can get some data on the customer acquisition side to better understand what it will take to be profitable on spend.

The most important growth channels for both apps still feel a little bit out of reach:

• Tech partnerships represent feature integrations we would create and expose to other leading apps on the app store. These features would need to be delivered ahead of things like COGS, the absence of which causes churn every month — and the risk of perpetually pushing COGS off is too great

• Agency partnerships represent relationships with companies that serve DTC businesses who would benefit from the technology our apps make available. Making these win-win requires a serious commitment to create content that help agencies understand and sell our app while making the economics work for the agency partners. Not something you can half-ass.

• Influencer partnerships feel like a low-hanging fruit that shares a lot of similarities with straight ad spend and I’m liable to try one of these soon. There’s a direct before/after changing that these content creators can reference when talking about the apps and how they might optimize their processes using them

• Co-marketing with other apps feels so obvious, but again requires serious energy and time commitments to make it work. Doing blog swaps, newsletters and webinars is a fabulous idea, but I can’t do those if I’m writing code all day.

All in all, I’ve been itching to take off my product hat and put on my marketing hat to start building systems across these four main dimensions. It’s alright if I write code provided I’m materializing progress on either of these fronts.

And as I’ve learned in previous months, true progress is only possible if you focus fire on a single thing at a time - especially in a bootstrapped context like this one.

That defines the next few months quite well from the perspective that elbow-grease will be needed to create all of these new systems on pretty much a full-time basis.

The MicroAngel Awards

The MicroAngel Awards pot is now up to $3,850. 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

No adjustments this month. Just cold hard executing on product.

I’m ripping myself from the process of creating (despite still having things to release) because the energy I’d spend upon the product, at this point, is better served going into creating growth systems.

I need to start taking home learnings on that side so I can corner the best channel for each app and start rapidly scaling revenues there. As those systems start to create a positive return, it might then make sense to bring on a growth partner to own it.

For the past few months, the search for a third partner has been open, and I’ve met many amazing individuals who’d do great in the role. But I haven’t pulled the trigger because I’d be setting them up for failure.

In the next months, I’ll be able to qualify just how difficult that job would be considering the current state of the products and value propositions.

The difference of course is that I’ll be incurring the pain first as I benchmark the metrics any growth leader would inherit as they embark on the journey with us.

It’s entirely possible that the need for a growth partner will dissipate as I create growth systems, but in the meantime, that’s the area where I’m most needed, and I trust my partner to hold the Product torch and continue delivering additional value to customers so I can make use of those efforts to create constant, reliable product-led growth.

Onwards!