MicroSaaS Playbook

MicroSaaS Playbook
Building a Micro Private Equity business
My main benchmark is Xo.Capital by Andrew Pierno and his team.
I’ve added complementary studies from others benchmarks.
Feel free to reach me @bokrms with suggestions and feedbacks =)
TL:DR
Micro PE means a focus on value investing in profitable, niche SaaS companies.
XO buys small, profitable SaaS businesses. We operate and grow them.
We're not VC (we buy 100% of the company) and operate like a micro PE firm.
We don't need 10x returns for our model to work well.
We believe the chances of one of our acquisitions going to zero is less than starting from scratch
Business Model
1

Motivation
Having done it and seen the downsides, I'm now more focused on bootstrapping profitably. There is a
subset of people in this space who are not anti-vc, but realize, as I do, that most businesses are not
VC scale.
This part is somewhat normative (i.e. this is my opinion). The VC backed startup game is a way of
life. Once you take the money there's really no going back.
I haven't heard many people speak about buying to operate. Specifically, a group of one or two
partners acquire a business to take it over and run it long term. Perhaps this is a slightly nuanced
position compared to buying for cash flow. In the cash flow scenario, the idea might be to put together
a portfolio of businesses. In this case, I'm talking mostly about one big bet. All your eggs are in this
one basket. This is not to say this is a bad idea. Most employees and entrepreneurs spend their lives
betting on just one company at a time.
VC Model
The VC model itself operates on power laws. If 1 in 20 portfolio companies ends up being a unicorn,
the other 19 just straight up don't matter (financially). Also, VC backed companies have a few different
ways to exit (even if it's a bad exit) including traditional private equity. These micro SaaS opportunities
are small enough that they don't make sense for a larger private equity company, and unless they're an
acquihire, they're generally not good for strategic acquisitions either.
So where does that leave the bootstrapped founder(s) after they've built a great small business but
want to move on? Before micro acquisitions became a thing, the answer wasn't very clear. My position
is that there is a giant hole in the market for profitable small SaaS businesses to have a great exit, and
for the buyers to take the company onto the next stage, whatever that may be.
Business Model (Micro P.E)
2

Micro private equity is the buying, operating and selling of companies on a smaller scale than
traditional private equity. Generally the purchase prices are sub $10M and are not high growth venture
companies. The focus is instead on cash flow and stable growth. Micro acquisitions are a synonym.
Colloquially, people use the terms interchangeably.
The short version is this:
Buy a company
Use cashflow to grow / maintain the product
Pocket the excess cash.
Maybe sell it, but that's not the goal
What are we buying
Buy - Obviously step one is to acquire something. I don't think it needs to be (and perhaps shouldn't
be) something large.
Grow Profitably - Some buyers prefer all cash, some prefer to use debt. Either way, generally there is
a more conservative approach to growth. Growth can be expensive, and time consuming, but if it's
neither, then by all means, go to the moon!
Hold/Flip - Some people in this space are more comfortable flipping sites, holding them for a short
period of time with the goal of reselling them quickly. Otherwise, you can hold and pay yourself
dividends along the way. Eventually, you'll have paid back the principal and have a revenue generating
asset you can reap the benefits of forever.
Fix the product "the right way"
Grow profitably. Make sure the cost of growth does not put you in the red each month.
Consider setting up a sales playbook or pipeline
Automate customer support and find a remote developer for relatively cheaper than a US dev.
But then again, we're not really buying 'tech'. We're not even buying 'companies' yet. We're buying
tools. Tools that do a job.
So I think we're getting closer to the answer. We're buying a combination of:
lightening ideia
a tool that does a job
a channel that works
a validated (to some degree) idea
Why buy and not build
If you're coming from the startup world, a few things should strike you as odd:
3

What?! You're not maniacally focused on 20% MOM growth?!
What about exiting isn't that the whole point of starting a company?
There are a bunch of reasons you might want to buy a company with existing cashflow instead of
starting one from scratch. A few of them are:
No need to guess if people will want the product. They're already paying for it!
You have an adjacent business that could also sell this product (i.e. let's say you have a service
business but no SaaS offering).
You can skip years of guesswork (what should we build, how should we build it, will people want it)
You want an extra revenue stream
Your skillset is in growth (going from 1 to 10), but not necessarily in going from 0 to 1.
Overall though, I've found it useful to think of micro PE as taking the real estate model and applying it
to SaaS. Buy, improve, and collect "rent" with the option to sell whenever you want to.
Founders put their heart and soul into this little project and typically spent an absurd amount of time
figuring out product market fit (or some semblance of it, let's call that product market foothold for
anything with < 100 customers or $10K MRR). That's great news for you as the buyer, you get to skip
that. You probably bought it with some ideas on how you'd grow it, or some kind of angle or unique
insight the founders missed.
First Mover
IDK. I didn't spend more than an hour looking but I couldn't figure out when this first started.
Whatever. Tiny capital has been doing this (with more modern internet businesses) for 15 years. I'm
sure they weren't the first. If you find something, ping me!
Buying MicroSaaS it's just like investing in "real state”
4

Now you see the full picture. Of course some people buy with no intention of selling. That's true for us
too, until someone comes along with an offer we can't refuse.
The other difference I'd like to point out is how different growth (or appreciation) can be for acquiring
SaaS vs buying real estate. Software scales. Even service businesses can scale if you put in good
people processes. Yes, real estate is likely a much lower risk investment, but the upside potential on a
good SaaS should be very high indeed.
Additionally, when you buy a SaaS company with existing cashflow, you're already mitigating a lot of
the risk of "going to zero". This is quite different than a venture backed startup that has to swing for
the fences or go broke (due to Venture Capital's reliance on power laws for outsized returns). When
buying a portfolio of SaaS businesses that already have revenue, a modest 5% growth rate per month
over 3 years will work just fine. If it's more, great! But, it doesn't have to grow at 20% Month-over-
month.
A note on depreciation. I'm not a lawyer or accountant, etc so consult your people. But, as far as I'm
aware, when you build software and ultimately sell that software (an asset purchase for example and
not as a stock sale where the acquirer buys the shares of the entity you created) that is not considered
capital gains. However, if you buy software already built and sell it later, that is capital and can thus be
depreciated. This is amazing! You can depreciate the asset you purchased just like in real estate.
Again, please consult the team you probably don't have.
TLDR;
If you're investing in real estate, consider buying a SaaS. You'll like the margins and the growth better.
And if you're interested but don't have the time to execute this on your own, my DMs are always
available!
Funding
Fundraise: 1M will buy 300k ARR ~
This raise will be a small $1M and will allow us to position ourselves as the acquirer of choice for
bootstrapped SaaS businesses doing sub $10k MRR.
The difficulty will then lie in deploying that capital quickly and efficiently. $1M may sound like a lot, but
when you're talking about buying cashflow, it's actually only going to buy us an additional ~$300k of
ARR. We'll still have to be patient and make sure we're buying great businesses at great prices.
What’s 2022 Xo.Capital Goals
What's Next:
Last year I had said several times that I wanted to do one acquisition a month in 2022. That's a bad
goal for a few reasons. If we were set on buying small SaaS companies sub $10k MRR then 1 a month
sounds doable. But, if we're also going to play with raising from outside investors, doing a
crowdfunding campaign, applying for an SBA loan, etc that timeline is just not going to line up.
This year I believe we can:
Raise capital from outside investors on a deal-by-deal basis (fundless sponsor)
Buy a (barely) 7 figure SaaS with an SBA loan
Crowdfund one of our acquisitions
5

Buy 3-5 more smaller companies.
Market today / tomorrow
Concretely, let's take a micro SaaS making $1k a month.
A year ago you could pick that up for $1k * 12 months = $24,000 top line times a 3x multiple = $72,000
on the high end. Realistically it's probably $24k at 85% margins = $19.2k times a 3x = $57.6k. But right
now? I've seen zero revenue products selling for $50k to $150k on these marketplaces. It's crazy!
If you're not above hustling on indie hackers or twitter, you could likely find a micro SaaS that makes a
little revenue and pick it up for a decent 3-4x. I do believe that whatever happens in the macro
environment, multiples are going to be driven up by demand as more and more funds like ours
formalize and raise capital. We might be looking at 5-6x in two years as "normal" no matter what
interest rates do.
Another idea if you can't find a profitable SaaS to buy is to pick up something from product hunt that's
been dead for 6 months. Usually the developer who built it hasn't thought about it in forever and it's
just sitting in a Github repo rotting away. You could probably pick up something pretty close to done
for under $10k. During this hot period, you could focus on launching it properly and putting in the time
and effort to finding customers. I always remind myself that this is very difficult to do. It's much easier
to buy something with revenue, but then again, these are not normal times. It might be worth the risk
and be cheaper to buy an asset that just needs to find the right audience.
About buying MicroSaaS
You're buying revenue. Not growth.
Knowing what you want out of an acquisition is half the battle. If you're just looking to acquire
cashflow, then the answer is easy: no. Don't buy anything with $0 in revenue because you're in the
business of buying revenue!
Buying for cash flow is straight forward. Low churn, some growth. Growth doesn't have to be crazy
but it should be at least 1.5x the churn (i.e. if two people unsubscribe from your product, 3 people
subscribe each month).
Quick side note on growth: Generally sellers want you to pay for growth. When buying for cash flow,
it's hard to justify paying the extra multiple for growth
If you did want to automate it, then that's work too. Good work. Work worth doing, but work
nonetheless. That's why I'm adamant you should consider these investments as active income instead
of passive income.
There's also an intangible feeling to buying and holding. You have one thing that I'm not used to having
when dealing with startups... time. If it takes another month for the re-write to make sure you're
operating profitably, that's okay. So long as churn is low (which, it better be, you checked this in due
diligence right?!) you have time on your side.
Learnings from buying, growing and selling a Micro-SaaS
What we got right
6

Growth / MRR Stabilization
I don't want to make it out like we didn't win on this deal. We did win. It just so happens the win was
more of an educational one than a monetary one. We ultimately didn't lose money on the deal but we
didn't 10x it like we wanted to.
We didn't own this one for very long, but the biggest lever we pulled for growth was simply going back
to all the delinquent users who were still using the product and not paying. This boosted MRR by a
hearty 25%. Sometimes it's the simple things. It's stuff like this that makes me realize just how early
we are in this space. A rational actor would have done this work before the sale. They didn't and we
benefitted.
Side note. Billing is still a monumental pain in the ass. Even with Stripe. People are delinquent, people
run out of money, credit cards declining, they need like 36 people copied on every damn invoice.
People hop on the chat to get us to get them their invoices despite them being available in the app
itself, etc, etc. Needless to say, our next hire will be a support person.
Product Stabilization
One of the things we did get right was moving off an expensive hosting provider like Heroku. We paid a
team to do the migration for us and went from $1,300 in expenses to under $300 in expenses. Oh
yeah, and all kind of problems went away (like the servers crashing every couple of hours). We got a
little lucky here. If moving hosting providers didn't happen to solve a bunch of ancillary issues, we
would have had to pay yet another dev to come in and unfuck the thing. Glad it worked in our favor, but
it very easily could not have.
Buying The Right Things.
This product is sticky. Customers that are using it heavily are unlikely to switch, because frankly it
would just be too much work. Think of where all the bugs live for your product. Is it Jira, is it Trello?
Wherever it is, moving to a new tool doesn't happen too often because the pain of moving all those
tickets would be quite an undertaking. This is why there are about a billion project management tools
out there. Once you get a team signed up and using it heavily, they rarely switch. So all this is to say
that the tool we bought did something valuable and was sticky. This was tremendously helpful
because with low churn, even mediocre growth (for a SaaS) can compound into something wonderful
over a long time horizon.
What we got wrong
Surprise #1 - Most Of The Cash Comes At The Sale
If you're considering buying micro SaaS companies because it's going to "kick off more cash than
Apple's new dividend", I have some bad news for you. When we took over Toybox, it was hosted on
Heroku, which cost us something around $1,300 a month and made around $4,500. So let's say you're
looking at this on a spreadsheet, and think "Great, my mortgage is about $4k, so basically if I buy this
annuity (SaaS company) then 75% of my mortgage is paid for, awesome!" You're not completely
wrong. On a month where there's very little outside expense, then you may very well be able to pocket
that cash and tell your friends this company you bought pay's your mortgage and you'll be the envy of
your suburban backyard BBQ.
7

Now let me crush your dreams (just a little!). There are very real expenses sometimes. Yes, on a quiet
month, your bank account may pile up with cash, but I would consider it unwise to take any kind of
distribution in the early months of operating the biz because frankly you don't know what you don't
know yet. Yes, you probably saw some yellow-ish flags in diligence but there's nothing like getting
handed the login to intercom and being swamped with random customer requests to temper the
excitement on your new purchase. For us, we lost a member of our team who had the expertise in this
tech stack. That caused us to spend money on freelancers who we otherwise would not have. Lots of
money (relative to the cashflow).
If you do this long enough, you're going to make a mistake. Our mistake came at acquisition #3. You
just have to own it, deal with it, and take action to make it right.
Buying Toybox was a mistake. There, I said it! I see that now (thank you retrospect!). It didn't fit with
the two products we already purchased. There was no marginal benefit to our little ecosystem. We
were blinded by two things. One, the company was a YC alum. We wanted that on our deck. We have
it. It came with a price. The other (unforeseeable) speed bump was a team change. Each of us loosely
were in charge of one acquisition. 3 technical members = 3 acquisitions. This worked until one of the
members left (maybe a story for another day). We were then 2 technical members operating and
building for 3 SaaS products. The beginning of all three purchases were marked by weeks of heavy
development. Fixing stuff we knew was broken, fixing stuff we learned was broken, and of course, the
developer go-to of completely rewriting one of them from scratch (actually ended up being the right
move!). In the future, I'd stagger the acquisitions a bit better so that perhaps when one product is
moving off the heavy initial development, that may free the (future) dev team to work on another.
Pick a thesis, and stick to it
We're still congealing on this one. We're going to be raising a fund here pretty soon and we will
absolutely pick a thesis and stick to it. When we're doing this with our own cash, it's okay for us to be a
little looser.
Still though, we have 2 dev tools and I think whether we like it or not, it makes the most sense to keep
buying dev tools. The thesis for fund 1 can be different (Say AI, or climate, or whatever), but whatever
it is, we will have to be slightly more cautious when dealing with other people's money.
Ideal team structure
Building Out An Operations Team
We're going to have to do this. It's going to sit at the GP level. I don't see this any other way. Without
each individual company having enough cash to be able to support a full team, we're going to have to
get some alpha / leverage by using shared resources. There's nowhere else for them to sit other than
at the GP level.
I think this topic deserves it's own post, but loosely this looks like:
One support person
Two devs (the companies probably have to be similar tech stacks for now until we can afford
multiple teams specializing in different languages / stacks).
One CEO - someone who is full time.
8

One growth person - Someone continually running experiments and bringing back data on
effective channels.
A small army of contractors + tools
That's five mouths to feed. A product making $2k a month can't afford this, but 20 companies making
$2k a month can if we're careful (and use oversees labor + our own time).
Earn-out templates
100% cash up front
This is about as straight forward as it gets. You write a check and get handed the biz. The founders are
happy, and you now hold 100% of the equity and the risk of the business going forward. As a buyer,
this is your least favorite. Cash is precious, and having all your cash tied up in deals doesn't leave you
with many options.
The Churn Out
Sometimes you find yourself looking at a relatively new business with relatively high churn. Let's say
an uncomfortable 30%. If zero net new customers come on, you'll have zero cash flow in roughly a
year. This is a nose dive. Hopefully you can sweep this one under the rug because you fucked up.
But maybe there's some growth too. Not much, and perhaps some months not enough to cover the
churn. Enter the "Churn Out". Structure the deal so there's less cash up front but if the total MRR stays
at or above X for the next Y months, you'll pay an extra amount. This incentivizes the sellers to help
you transition and may even encourage them to help grow the business. This isn't always going to fly.
We did a deal with a "Churn Out" because we were moving all buyers from Paypal to Stripe. We were
worried that a bunch of people were not going to move so we structured the deal such that if MRR
stayed at or above the MRR at the time of purchase and after the transition to Stripe, we'd pay an
additional amount. For the record, MRR did continue to grow and we didn't lose many customers and
had to pay. And we paid gladly
The Earn Out
9

Share the wealth. Earn outs take all kinds of funky forms in the real world, but the simplest version is
when you pay an additional amount if certain customers close or if MRR crosses hurdles. Say for
example the current owner has a pipeline of customers she expects will close over the next 12 months.
She did the work to build the pipeline and wants some upside if they do convert. You could structure a
carve out in the agreement to give her additional cash, perhaps on a monthly basis from just those
named customers in the pipeline.
Another version could be even simpler where if the MRR crosses X within Y months after closing,
there's an additional payout.
Seller Financing (parcelamento)
Seller financing allows you to pay a purchase price in installments instead of all at once. We did this
with our first acquisition. We agreed to a price, and we payed it out over 3 months. This is nice
because depending on the business' cash flow, you can use some of the business earnings to pay off
the acquisition. It usually isn't dependent on business performance and is just an easy way to spread
payments out over time.
SBA Loan
We haven't done this yet. We will. I'll report back on the reality of getting an SBA loan to buy a
software company. In theory you can put between 10% and 25% down in cash and borrow the rest at a
lovely interest rate with a 10 year payback period.
Generally you want to keep things simple. Often the sellers of small businesses don't know anything
about finance and there's nothing worse than explaining to someone how they're not going to get all
the money up front. But, these tools can help overcome the burden of tying up all your cash
immediately when purchasing a new business. Try them all! Ping me on twitter if I missed one!
Thesys on fremium (low touch) vs b2b inside sales (high touch)
Freemium is a great fit for a shared service model because we can really have one function serving
multiple products. The only reason this works is because individually the scale of each co is quite
small. For example, let's say sheet.best has 2 hours of support tasks each week total. I can't really
justify a full time support person for that even though I loathe customer support (I know, I'm supposed
to pretend I like it, but I just fucking don't. Sorry, not sorry). But, if I have 5 companies that each
require 10 hours of support tickets each week, well, you get it. I can have one person doing customer
support for multiple companies. It's likely the same with marketing. I don't think we have marketing
figured out in any real way despite some decent growth stats but I do know that a content pipeline is a
content pipeline. We're building one, and whether that process outputs some technical post for our
developer audience or some riveting industrial news for our domestic manufacturers, it's still just a
content pipeline.
$25k ARR (WorkClout) = 1 to 2 customers
$25k ARR (Freemium at $25 / user / month) = 84 customers.
10

84 customers is cool. It's diverse, unlikely to all churn at once, makes potential buyers feel
comfortable. But this is a trap! 84 people ask a lot of questions. mostly dumb questions that are
answered on the site already! In any group of 84 people there's also always a few that want you to be
their bitch over support. "Get me my invoices for the past 6 months in one PDF?" "How do I do this
really weird thing with your product" etc.
But a smaller number of customers, especially enterprise (ish) customers are different. They mostly
just STFU and pay their bills. They're never late. They only ask for things they really need. And
cognitively there's actually something really nice about having a smaller list of customers who you
actually know. You can text them product ideas and they'll be straight with you. "No, we don't need
that". Or, "Yeah I think that would know Billy's socks off, please go build that!". You can send them fruit
baskets for the holidays. And when push comes to shove, if you need an exit, they'll be the first people
to put a bid in. They're more strategic, etc. etc etc.
Winning by default on price / Winning by Growth
Winning On Price
If you buy something for too much money, and are too reliant on the optimism of future growth, you're
in a bad spot to win by default. Winning by default on price means if we had to sell something the
moment after we bought it, could we still not only get our money back but make a little bit of profit
from the transaction as well. Thankfully transaction costs in this space are very low compared to real
estate for example.
Now we're not always going to get a great deal. We may end up with a fair deal, or a deal, but it might
not be a great deal from a price perspective. Then we have to rely on higher risk things like execution.
Obviously fine, but not winning by default. In practice that means we'll likely pass on deals we
shouldn't. I'm okay with that for now. We're still building up our credibility where a few higher points of
IRR will make a big difference for our eventual fundraise.
Winning By Growth / Sales
Despite that, we have managed to grow our portfolio companies decently well. Nothing crazy, just
calm, comfortable growth. If you really knew what you were doing in growth / sales I think that you
could win by default because you (hopefully) know a great product when you see one, and more
importantly could make 20 phone calls and close a 6 figure SaaS deal.
This skill was our most recent addition to the team. Someone who knows sales (amongst other things).
If you've ever made the mistake of hiring a sales person too quickly due to lack of product-market fit
(spoiler alert, sales can't fix your market fit problem), then I hope you've made the equal and opposite
mistake of hiring a salesperson too late (think of how much farther along if we hired this person a year
ago!).
11

I've talked mostly about sales here, but the implications still hold for growth. A shit product is not
going to get any kind of viral loop. It's also not going to work trying product led growth if the product
sucks. Also you'll probably fail at product led growth. I could include a section here on 'winning by
product' but i think that would be really misleading. If you can't tell, I'm not a fan of the way people
have been talking about product led growth, but I'll save that for another day.
Ok, you caught me. I've said nothing at all about tech. It's not that tech doesn't matter (it does), but it
sort of doesn't. I can't tell you how many dozens of VC pitches I've done where not a single tech
question was asked. It just doesn't matter as much as paying customers do, as much as traction does.
And since we're in the business of buying cashflow, the same applies for us.
Pricing
WorkClout was XO's first non-self service, non product-led growth purchase. As a result, the first 30
days since purchase have looked quite different in comparison to Sheet.best or Screenshot API (a
more in-depth post on this topic coming soon).
Setting up a new pricing strategy without having a strong grasp on the value metrics, customer
behavior and market expectations was a little bit naive; however, having spent the majority of the 30
days listening to customers, identifying gaps in the product, and prioritizing alignment of value +
investment, I put together some initial observations of WorkClout's monetization strategy
Observation #1:
Check out this awesome breakdown of SaaS Pricing Strategy by Patrick Campbell, CEO of ProfitWell.
A “value metric” is essentially what you charge for.
Our current pricing, even without knowing what the actual is, misrepresents some of the key value
metrics for a software tool like WorkClout by giving away an unlimited volume of every key feature of
the platform.
12

Observation #2:
Because there isn't a clearly defined value metric due to the broadness of the feature sets, the existing
approach to monetization will either a) automatically disqualify smaller businesses who do not value
"unlimited" or b) ineffectively close the larger customers.
Pricing based on a value metric (vs. a tiered monthly fee) is important because it allows you to make
sure you're not charging a large customer the same as you'd charge a small customer.
Taking a snapshot of a random sample of users in WorkClout accounts, you can see the size-able
variance in user counts. Without delving into usage metrics, there is a linear correlation between
number of users and amount of value derived from the inspections generated through the WorkClout
platform.
13

Are we leaving revenue on the table with some of the larger customers who require many users while
simultaneously losing out on new revenue with some of the smaller customers with fewer user
requirements? Maybe.
Observation #3
Finally, based on observation #1 and observation #2, it is safe to believe that WorkClout fits multiple
customer segments; therefore, to maximize revenue, creating a monetization strategy that befits the
multiple customer segments seems important.
When you undergo the work of figuring out which customer segments value which feature, you can
tier them based on who values what. An alternative and maybe easier way of saying this is how your
price is set by how valuable is the problem you are solving for the customer.
If we were to extend that snapshot of the random sampling of WorkClout accounts to include "yes or
no" characterizations of Feature usage, I wonder if we can track product behavior patterns to tier
things based on what matters.
So What?
The observations point to two specific experiments to improve the monetization strategy at WorkClout.
A consequence of this experiment is we invalidate the existing customer profile and uncover one that
aligns a bit more with a product-led growth strategy.
Build a tier offering a low barrier to entry that offers a user-based component to support the
smaller SMBs and mid-size companies that do not value the "unlimited everything" model
Ensure that the price point and the value metrics align so that companies who are big enough in
size to warrant an "Enterprise" price also couldn't just get away with a competitor's free product.
This #2 experiment is to test if we can minimize churn risk with a higher investment requirement
for a certain tier of WorkClout.
Building customer segments based on size of the company and level of commitment to digitizing the
quality/compliance processes will optimize the correlation between usage of WorkClout and the price.
14

Readings
Pricing Strategy Guide
Condensed version of #1
Pricing Strategy is Product Strategy
Free Trials
WorkClout: Are the free trials working?
https://notes.xo.capital/free-trials-vs-demo-requests/
Bonus: First filter (reddit)
Operational Models
Model 1 - You bought a job (A.K.A the one (wo)man band)
Congrats, you just bought a job. Being CEO of a micro SAAS might either make your mom proud or
sound cool at your first cocktail party in 18 months, but the reality is much more modest.
Sidenote: lol
Micro SAAS companies are often labors of love. Founders put their heart and soul into this little project
and typically spent an absurd amount of time figuring out product market fit (or some semblance of it,
let's call that product market foothold for anything with < 100 customers or $10K MRR). That's great
news for you as the buyer, you get to skip that. You probably bought it with some ideas on how you'd
grow it, or some kind of angle or unique insight the founders missed.
There is absolutely nothing wrong with buying a job. In fact, I was speaking with Nile from https://
www.nocode.tech/ / Concrete Capital. He bought a job, and then turned that into an anchor (See
Model 4).
15

This section is mostly here to tell you that you bought a job, if you're reading this to figure out how to
operate a company, god help you.
The process I see for regular micro SaaS companies is something like Build => Grow. If you buy
something and don't have to touch the code, that would be the ultimate. I've heard other companies
like ours say everything from 'make sure the tech is rock solid or don't buy it' all the way to 'screw the
code, you're buying traffic and customers'.
Whether that 'Build' phase is just a check to make sure everything runs like you think it does, I still
think it's step one. If you can't trust the product to work when you sleep, how in the world is the thing
supposed to make $$ when you sleep! Also nothing ruffles my feathers quite like customer support.
The 'Build' phase to me is complete when you have at least one (ideally two) dependable devs to build
incremental features. For tiny companies, they can be contractors but they should know the codebase
well.
Once you are comfortable with the tech (or became comfortable because you had to write the damn
thing over yourself) that's when you can start the 'Growth' phase. Ideally when you bought it, there
was at least one channel that showed promise. If so, step on the gas, see what happens. Test all the
usual channels getting enough data to objectively say a channel is revenue positive or revenue
negative. The good news is that I believe only one channel needs to work well to get to ~$10k-$20k
MRR.
Model 2 - You hire an operator (Trying this model with the #1 Fund)
This is the model I want to dig into a bit as I'm certain it will work, it's just a matter of figuring out a
minimum run rate it will work at. I think it's roughly $200k ARR (from a North American perspective).
That number might be lower where you are (opportunity?) but we'll circle back to this.
If you naively thought you were buying a passive income stream (slightly guilty on this one) and found
out you actually bought a job (guilty again), then this is step two. There's no way for us as a fund to
continue not only stacking funds but also stacking companies if our heads are in the weeds operating
time. So we can't do it long term, but someone has to.
Here's the rub. Hiring a full time person (even just one) is expensive. If the business only does $5k
MRR, that doesn't leave much room for a salary.
PE firms buy companies with people. Those people run the business, or used to before they were
bought. The PE playbook varies widely, but let's look at a common one: Fire + Squeeze.
16

Step 1 is fire some business unit(s). I'll run through a somewhat recent example. Mind Body, a fitness
company your S.O. has probably booked a yoga class through at least once, went public. That didn't
go so well. A PE firm came in and guess what they did? They fired the sales people. The balance sheet
looked great without a large cost center like a sales team and they made the math work with a reduced
sales force. The squeeze is to get as much cash (or as little churn) as possible. You can't do this with a
micro SaaS. There's no head count to cut, and hardly any customers to squeeze.
Another common play is to put the PE firms employee(s) onto the board or into senior leadership. This
also generally involves firing people (as is tradition). This also doesn't work with a micro SaaS. There's
just you buddy! Though shalt not fire thyself!
At face value the concept of 'We'll take the PE playbook and apply it on a smaller level' is a good idea.
It just seems to have a minimum floor value of cashflow to work. And micro SaaS's tend to be under
that threshold.
So, we sort of need a different playbook for micro SaaS. Here's the experiment I'm going to run as
soon as we either buy something with enough cashflow to do it, or grow something until there's
enough cashflow to do it.
Hire a 'JR CEO'. I don't think I "invented" this, but I really love this concept of hiring a JR CEO.
Someone who effectively is CEO but reports to you. You can edit instead of write from scratch. Quickly
course correcting will be much less time intensive. Also, I believe most decisions are two way doors,
you can easily go in, and come back out if you were wrong. Not only would this be a cool opportunity
for someone a little earlier in their career, but it would free up the partners time to repeat the model.
I think you need $200k ARR to do this. Here's my math:
1 JR CEO - $50k. Not sure if you could find someone for $50k, but you should be able to be
scrappy and make it work. Somewhere between $50k and $75k sounds reasonable.
1 Developer - $50k. I think you could get someone out of a bootcamp or a more senior person in
another country. Devs in LA are $10k. Devs in Viet Nam are $3k. Devs in Morocco are $2.5k.
Expenses - $25k. Server costs, support system, other bullshit
Marketing Budget - $25k. This is going to be inefficient spend since you probably don't know
what's going to work yet. Maybe your CEO can do this, but it would be. nice to afford an agency or
two to speed up experimentation.
Buffer - $50k. Shit happens.
The "Pro Move" would be to buy something and run it yourself first. Then over time, grow it into a real
business where you don't have to do all the work. When you go to sell it, you the people, who are now
employees of the business (right?!) increase the valuation because now the next buyer doesn't have
to go through the bullshit that you did. They have their own playbook to run. They don't call it 'micro'
for nothing!
17

At some point, I'm going to raise a $1M fund, buy one company, and execute on this. I'll let you know
how it goes.
Model 3 - You Buy An Anchor For Your Fund (Future)
Growth by acquisition is a tried and true strategy. Read some books on it. People have been doing this
forever with boring ass businesses like CPA / law firms.
The insight I want to point out here is that if you have an anchor in your portfolio of companies (i.e. a
mothership), then it makes the next acquisition that much easier. Everything points to the mothership.
The mothership is the main point of monetization. Everything else can just feed it. That frees you up to
explore other potentially cheaper acquisitions like a newsletter with a shit ton of people on it making no
revenue. You don't care about the revenue in that case because you know that if you point that group
of people (in a tasteful way) to the mothership, you can make your money back on the acquisition.
I love this concept. We're not doing it at XO yet, but I'm thinking about this daily.
If you want to pin it to an existing concept, think the traditional PE roll-up strategy. You buy one
storage unit site that has a great brand and then you just keep buying storage units. Do you buy thing
that are not storage units? No, if it's not a storage unit, you don't buy it. That's an easier pitch to
investors too.
It's not sexy but it's worked since people figured out money can make you more money.
Model 4 - Passively watch your investment go to zero while drinking adios motherfuckers in thailand
I put this in here to dispel any ideas of micro acquisitions being a means to passive income streams. I
know there are at least 2 people who read this newsletter that have 99% passive businesses.
Congratulations (tips hat).
For the rest of us mere mortals, if you don't work on the business, it can and likely will go to zero. Take
Toybox for example. That codebase hadn't been touched in a year and a half. Customers were pissed
off, churn was high, and my god did those servers crash every 6 hours. That's when suckers like us
came in and thought we'd buy it and just put the cashflow in our pockets. We were wrong. This
business is going to need a lot of love to turn it around.
A note on no-code
I've spoken with several people in the past few weeks about no-code and their relationship to micro
acquisitions. Here are some findings:
Nocode is a growing space. You're not too late.
Buying a company that was unprofitable with 2/3 engineers, flipping the product to nocode such
that it's profitable with one Bubble.io developer is a thing. It's here. This is a really dope idea.
Buying a thing that doesn't have much traction yet, flipping it to no-code and being a fast-follower
on a trendy product niche is a thing. It's also here, and also pretty cool.
18

Shared Service Center
Shared resources
Full disclosure. I'm buying for cash flow, so I'm not the best person to talk about this. In reality, buying
to flip and buying to hold are functionally equivalent. What changes is the timing.
When flipping, you might sacrifice short term profitability for growth but much of the work is still the
same. If the product needs development, you'll have to do it or hire someone to do it. Your product
isn't going to grow very well if the product sucks.
I'm mostly referring to SaaS businesses, but even SaaS has some people operations necessary for an
awesome customer experience. Namely, support.
One of the things I'm still figuring out is how we can have a portfolio of companies using
shared resources.
So for any individual company, paying someone full time for support doesn't make sense. But if we
could hire one support person and have them do all support tickets across all our companies, that
would be amazing! Development would ideally work the same, though so far we've bought 3
companies each with different tech stacks, which makes sharing developer resources slightly more
complicated.
Tip:
If you're considering making your first acquisition, it can be helpful to be aligned on goals. This is
pretty similar to a startup. Although the answer may change over time as you inevitably get more
information (i.e. we bought a lemon, or this business is growing like crazy!), it's still nice to have
a north star, especially when buying with other people.
If you're just getting your feet wet, try to buy something you're going to hold on to for at least a
year or two. Not only are there potential tax benefits, but the mindset might prevent you from
buying something stupid.
Harvard Business Review recently profiled ByteDance and claims their org structure is their super
power. Or rather the way they do SPP. The key is specialists. This is an unhelpful observation for tiny
companies. You can't afford to hire a specialist in market research for example, you have to lean on
product (typically) to serve as market research when exploring a new product or feature idea.
Obviously if you hired a ninja market researcher, your product person would be thrilled. They'd get the
answers they need faster.
Additionally, if you task a product manager to go create a new app, the product manager might come
back with a great idea that you'd then have to go build from scratch. At ByteDance, the answer might
be to tweak existing tech. This is really the only way ByteDance could have launched 140+ apps in
their first 2 years. You're never building from scratch.
19

Comparison to the way AWS (Amazon) sets teams up.
Amazon is another company that is lauded for its efficiency, but their setup is quite different than
ByteDances'.
(my interpretation) Product teams don't control as much of their own destiny, and that's a good
thing. At Amazon, each team is somewhat independent so long as the contracts between services
are upheld (i.e. APIs between teams / services are contracts). At ByteDance, teams do not always
get to chose the technology, they may be forced (again, in a good way) to use something from
another team.
teams can work on more than one product / project.
(my interpretation) You're hiring weapons (specialists), not generalists. This is an uncommon
approach. As a startup you're often forced to hire generalists. When ByteDance says they have a
'Video Processing Team' for example, you can bet your ass these guys are going to be able to
accomplish some wicked video processing shit. This, practically speaking, for anyone who has
worked at a large co knows this is certainly not always the case with 'experts' who work on other
teams at the same company. (i.e. oh ya call Joe, he's our best 'Video Processing Guy', and you do
and Joe is a quack). A simpler example. If you have a specialist in market research on a team, you
as a product owner don't need to mess around yourself, you can tap the team to help and they will
be (must be) better than you at market research... bc it's their specialty.
Side Note: Use your network and find them. Even if you can't afford now. Keep them close.
Overall these guys cast a wide net within a constrained space (i.e. many different ideas that all
revolved around short-form video content) and leaned on specialists for precision and speed. They
took learnings from all the apps launched to make the next attempt a little better. It's genius and
incredibly difficult to execute on.
As XO congeals on our own SPP, I think we take note of a few highlights from ByteDance.
As soon as we can, start building out SPP teams with specialists. (Andrew, will you share?)
Try to buy companies with close / complimentary tech stacks so we can re-use some technology
between companies (i.e. shared stripe integration code). Build out our own code to be shared
between companies.
Top down OKRs that cross teams (i.e. no silos) and a flat org chart.
Where to buy and how to sell
Marketplaces around the web
Marketplaces
https://www.notion.so/7ac103ac889e49259f642a9f653f53ad?v=05002e1175054ad9915a5f013a20fe4f
A new tool for teams & individuals that blends everyday work apps into one.
Lessos Learned
Lessons Learned - Product and Metrics
20

If your servers have had any crashes in the past month or cpu spikes that aren't easily
explainable... that's a new dealbreaker. It's probably a clusterf*$# we don't want to deal with.
If your code doesn't scale and will require a significant re-architecture... that's a new dealbreaker.
We may also start imposing strict requirements around programming languages. It's just too
difficult to wrangle so many different projects in so many different languages.
Moving up stack helps mitigate all of this. If you can acquire the team that wrote the stuff, then it's
not such a big problem, but for smaller deals, where we have to execute big engineering efforts,
it's just too tough to do.
Nearly all micro acquisitions are distressed assets. Even if they don't market themselves as such
(who would!), they are often actually alpha versions of what you'd build if you could start from
scratch. And so far, for 1/3 companies we started over from scratch.
Don't buy a bunch of these at the same time. We did 3 with 4 partners (3/4 write code) and it was
still too much. Do one, get it on a path, then consider doing another.
If you're considering jumping in, just do a small one, and understand that it's going to be hard. If
this was easy, everyone would be a passive income millionaire, writing books and courses on how
to be a passive income millionaire.
Get the obvious metrics in a report daily, and turn obvious knobs to unlock growth and increase
conversion.
Lessons Learned - Diligence
Diligence is hard. It's even harder to do technical diligence while looking at random files through a
screen share in your third favorite programming language.
Reliability / Uptime - Make sure you can view the error logs of the servers. Note any crashes, or
uptime less than 99.9%. If it's less than that, why is it so low? There should not be any response
times greater than 1 second. How frequently are response times longer than that? Why?
Code Quality - This is so hard to do before getting full access to the code. I don't think we have an
answer yet. The short of it is that no matter what kind of diligence you do, you're going to run into
surprises.
Architecture diagrams - It's important to know where a product is going to fail first. All software
has limits, and you just need to know where those are.
Lessons Learned - The Passive Income Myth
If you think you're going to buy something, and not touch it for two years and get money in your bank
account every month, you're somewhere between ignorant and wrong. Bottom line is that thinking this
is going to be passive income straight up will not work. These SaaS companies do not have intrinsic
value like land does (in most cases in the micro-SaaS world). They can and sometimes do go to zero.
People will have questions. Someone needs to answer them. People are going to have issues (even if
there are zero bugs, which is highly unlikely). You will have to answer them.
Lessons Learned - Growth is the answer
If you have amazing engineering chops, congratulations... but it doesn't matter half as much as growth
does. If you can't grow the product you just bought, find someone who can and partner with them or
start studying. This is where 80% of the work is.
Lessons Learned - Dev Ops Is Hard
21

Keeping things online as they're growing is hard. Most likely, the thing you bought has a weird way of
doing things (docker compose on a single digital ocean droplet? Yup) that was comfortable for the
previous team but is uncomfortable for you.
As soon as you take the reins, you should ask the seller to walk you through a new deploy. Make a
small change to the readme or something, commit it, and go end to end through a deployment.
Document EVERYTHING along the way. That will at least give you some confidence.
Lessons Learned - Observation Is Hard
I still cannot believe how difficult it is to get basic business metrics. It's so important and such a pain
point I'm going to build a solution for ourselves to monitor all the usual metrics, plus some churn
prediction. Maybe this turns into a saas, not sure yet.
In the mean time we have some basic stuff hooked up to Metabase and sent to a slack channel each
morning. It's a nice way to know how things are going. It took me an embarrassingly long time to even
see which company was growing the fastest quantitatively. (it's Sheet.best :)
Lessons Learned - These are not liquid assets
We ran an experiment last week putting one of the projects up for sale. Partly because we bought too
many too quickly, and partly to test liquidity as a seller. Lo and behold there are a bunch of damn tire
kickers on the marketplaces. I'm sure there are some good people in there, but zero people have asked
for a meeting (out of 35 or so interested parties), which I find strange.
Lessons Learned - Critical bugs deal breaker
We're starting to get better about getting everything we need before wiring money. People just tend to
change their behavior after they've been paid. Just a fact of human nature i guess. In this case it's
some critical bug fixes. Yes, we're now going to ask (require!) certain bugs to be fixed before the
handoff. If it kills a deal so be it.
Mostly #1. Also sometimes people get busy.
Lessons Learned - You're buying a job
Yeah, you are. Buying a micro SaaS is buying a job. It's now your job. And there probably isn't enough
cashflow to hire a US based dev full time, so that engineering work is probably going to be just you for
a while. Alternatively (like we've done), you have to scour through hundreds of mediocre devs on
Upwork at cheap rates in inconvenient time zones. It sucks.
Lessons Learned - Diligence is balance and don't buy more than one at time
All that being said, diligence is a balance. If you ask more questions than another party that puts a bid
in, you might loose because you were 'asking too many questions'. We had one where we didn't do
that much diligence because they were a Y-Combinator backed company. That was a big mistake.
Also, cautionary note. You're going to be wrong, and you're buying a job. I'd partner up with some
friends (or random people on indie hackers / trends.vc / etc like I did :) and I'd start small... And dear
god just buy one at a time. We did 3 at a time and it was foolish.
Due Dilligence
22

Step by step
Others
Xo.Capital portfolio metrics
The Economics of Micro SaaS · January 2022 "Investor" Update · March 2022 ·
How to form a DAO
How To (Legally) Form A DAO In The US - part 1 · Creating A DAO - Part 2
This session is from others benchmarks
Micro Angel threads
Go to Market - Tips and Steps
MicroAngel State of the Fund: February 2022
https://microangel.so/p/february-2022?s=r
New Reconcilely website, reached $200k cash-on-cash, new content and outbound sales process. Closing MRR: $25.5k
Estrutura Macro - TLDR
23

Content production
To power our new blog, I created a new content production process and, with the help of contractors,
released 8 new articles to the blog targeting a variety of long tail keywords relevant to Reconcilely’s
organic strategy.
Within the current arrangement and at our current pace, I estimate we could probably produce as
much as 40,000 words per month. The goal for now is to reach customers that would benefit from our
existing product value proposition.
As we increase integrations, it will be clear what type of content we should produce and publish to
meet customers halfway as they search for our solution.
The content production process can be summed up as follows:
Conduct research on keyword strategy
Silo themes together and arrange large groups of similar keywords into those silos
Determine the initial list of focus keywords and the potential traffic they represent
Create content briefs that will product content that will answer the search query for each of the
keywords on our initial list
Utilize AI-powered content platforms like Frase.io to create initial article outlines relative to search
queries
Produce first draft
Source and add images to text as made relevant
Define a title, description and URL slug for the article based on the target keyword
Finalize the content and produce a feature image using Canva
Put it all together and publish the article via Webflow CMS
24

Outbound Sales & Affiliate
This feels like the Achilles heel of so many indie hackers. Outbound is seen as a devilish activity that
will return very little for too much input.
In a world where inbound marketing and product-led growth, one might wonder what the purpose of
outbound is and what role it could ever play vis-a-vis other more elegant means of acquiring users.
The number one purpose of outbound lead generation is to build a process by which an existing list of
prospects can be turned into new customers.
This is very difficult to do on an inbound or PLG basis since you already know who you are going after
and want to pitch your solution up-front so you can immediately put points up on the board.
Consider the Australian Shopify market, which is comprised of roughly 100k active stores of all sizes.
That’s not a lot, but it’s not small either.
Provided a list of those 100k stores, there’s a clear outreach path whereby the list can produce a
decent number of new customers.
The simple reason that’s true is because of those 100k stores, a percentage — never mind how small
— will be looking for your solution right now and if you aren’t in front of them at that moment, the
opportunity will be lost to a Google search.
In short, it’s important to respect the context in which outbound works, but also what the upper ceiling
of performance will be, and the consequence of burning through 100k stores and not having any other
means of acquiring customers is of course severe.
One of the main things blocking the use of outbound sales is the cost implied in that process. You
need people talking to people in a high-touch format, and that assumes a much higher cost of
acquisition than, say, self-service SaaS driven through ads.
The fact is you need individuals that you pay to be talking to other individuals to elicit a conversion rate
out of that process which historically has been pretty shit.
For this to even be possible for a product like Reconcilely — which offers ARPUs of ~$20 and LTV of
~$350 — the cost of those individuals needs to be really low.
25

Finally, a use for those VA outbound messages on LinkedIn.
I decided to come up with an offer that would make hiring those VA types not only possible, but
advantageous vis-a-vis the kind of income they’re used to and the kind of offer I could make them.
I created a presentation that I would use to shoot a video sales letter, which in turn would be hosted
on a page I could send prospective VAs to.
This would make it possible for me to source new VAs from existing Facebook groups where folks are
looking for sales jobs as well as direct anyone from elsewhere to the video so they can better
understand the opportunity.
The goal is to circumvent the outbound sales limitations by leveraging an economic reality (low cost
workers) which would itself take advantage of my offer.
This is a seriously good offer for individuals in parts of the world who already bet on virtual assistance
as a means of making ends meet. And it’s a win-win for both our company and them.
My goal at this point is to validate the manual process I’ll require of the VAs and to use that validation
time as a way of training new hires to quickly ramp up and start driving installs.
Of course, I need to be very deliberate about that and be careful not to raise an army of spammers —
which of course is the opposite of what I’m after.
Instead of spamming, the goal is to leverage low-cost labor as a means of checking under every rock,
and having the ability to chat 1:1 with real merchant prospects who would happily use Reconcilely to
solve their ecommerce accounting were they introduced to it at the right place and time.
I’m using a similar value proposition for powering my affiliate offer, which considering an existing
audience of merchants could well turn into a valuable source of commissions:
26

Joint Marketing Ventures
Beyond all that can be done on your own, something else I’ve been meaning to explore is joint
marketing collaborations with other app developers.
Sure, marketing collabs are the basis of many partnerships, but what I’m after is some systemic
advantage that could be acquired by working with others that I otherwise could never acquire on my
own.
Let me explain:
Part of why marketing channels like Facebook Ads are losing value is because acquisition costs are
rapidly skyrocketing.
It’s real-time bidding on a very finite number of people whom are interacting less and less with ads. It’s
inevitable.
The number of people trying to reach Audience ABC on Facebook is rising, and the likelihood anyone in
Audience ABC will interact with ads is rapidly falling. Thus, costs are increasing.
While this may fully disqualify Facebook as a channel for some app developers, it teeters on the edge
for others.
It’s not profitable, but it kinda could be. It’s not enough to invest in, but clearly represents some
potential if a few things could be figured out — namely cost per click and or cost per lead.
In considering different ways to reduce CPL, I’ve been meaning to use joint ventures as a way to
reduce those costs.
Imagine I spend $2,400 on, say, Facebook Ads, to drive webinar attendees for a Shopify-focused
program intended to show merchants how they can save money on shipping costs (for example).
The goal is to drive new customer acquisition for Postcode Shipping in this particular example.
The breakdown might look something like this:
$2,400 spend on a warm list of non customers (ie. retargeting)
27

$2 CPC → 1,200 clicks
30% convert on webinar squeeze page → 360 signups → $6.67 CPL
50% attendance rate on the webinar → 180 attendees
40% conversion to install → 72 installs → $33 CPI
~40% install to paid conversion → 29 new customers → $82 CAC
29 customers * $250 LTV = $7,250 LTV
29 * $20 ARPU = +$580 MRR
The results wouldn’t be terrible, but they wouldn’t be good either—and jeopardized by 5 different
spots in the funnel that could fail to perform as required to produce the projected acquisition cost.
These numbers are pretty optimistic, but they can often become impossible if the top of the funnel
breaks down at the start (i.e. clicks end up turning $4+, then what?)
The risk implied by the funnel performance, and the CAC it enables, could potentially be quelled by
working with other app developers and splitting the campaign bill.
If I partnered with 2 other developers and delivered the same funnel, the webinar value would go up
(from additional perspectives) and my acquisition cost would be cut by 2/3 as my partners would each
pay their share of the campaign cost.
The goal of course is to reach a larger number of customers (as the targeting would now include my
partners’ traffic too) while decreasing the total cost per lead — which can be done by sharing leads
that sign up for the webinar (as an example) between partners.
In that example, I could then realistically expect the same 72 installs — and 29 eventual customers —
but at a cost of $2,400 / 3 = $800.
At that rate, we’d be looking at a CPI of $11 vs. $33 and a CAC of $27.30 vs. $82. It could transform the
viability of ad networks the economics of which have started to price out bootstrappers.
With the website up, it makes sense to kickoff paid media experiments to figure out at least one
repeatable process to profitably acquire new customers at scale.
28

Planning and orchestrating growth strategy for my Shopify app
As we kick off the Growth phase for Fund I, I’ve taken the opportunity to tear myself away from coding
and start building much-needed infrastructure to support the growth of Reconcilely and Postcode
Shipping.
Naturally, I’d love to optimize my mid- and bottom of the funnels right off the bat. As mentioned in the
January 2022 monthly report, the app store listings really needs help.
Further than that, the first growth marketing experiment I almost always start with is at the last step of
the funnel.
Start optimizing closest to the money.
So shouldn’t I start with that? Make more of what I have?
That question led me to zoom out so I could get a lay of the land as it relates to all the things I could do
to help accelerate the products run rates.
Should I work to earn more installs or should I optimize the process of turning installs into customers?
It’s evident I need to do both.
This is a common pitfall.
As a boostrapper, there’s a limited energy budget that you can allocate across different projects.
The more complex the project, the more energy and time it requires to execute.
If you have a pedigree of creating high quality products, you may even run into quality assurance
obsession as your perfectionist approach feeds your creativity and motivation but inevitably slows you
down.
What makes you unique also eventually makes you slow.
Your speed and ability to stay nimble are crucial, so pooling all of your chips into a single initiative is
only really worth doing if you don’t have a choice or if you already have observed some evidence that it
has a higher potential to succeed.
In other words, you should double down on what works, but you can only do that if you have
something that works — bearing in mind that 80% of the growth of a startup at any given moment
comes from one channel.
A channel producing a small trickle of installs can easily disqualified as not the main channel because
when things take off, then tend to do so quickly and dramatically.
The channel response for 80% of your growth won’t feel like a trickle of rain. It will feel like the
thunderous and continuous roar of a waterfall as leads pour in.
In our case, both products have only ever grown through the App Stores, and while they have an
inherent affinity to grow from specific types of channels - be it due to the market they serve or as a
result of the ARPUs we collect - building those channels requires a serious amount of time and energy.
What we do know is that the App Store currently provides a trickle. So while it does represent the lion’s
share of installs, it’s clear there’s potential hidden away in another channel.
Additionally, some channels are dependencies for other channels to be possible to execute. That’s on
top of the energy spend.
For example, you can’t offer guest posting quid pro quo’s with other apps if you don’t have a blog, and
you might not be willing to have a standalone blog until you ship a new website.
29

This is oversimplified, but the general order of initiatives can produce return multiplication relative to
energy expenditure.
If you can hit many birds with a single stone, do it.
But beware of the difficulty implied in trying to do many things at once, and the subsequent
impossibility of delivering the level of quality you might produce were you to focus on a single thing.
On perfection
Importantly, perfection is too expensive at this stage.
Perfection is the absence of fault, and fault is a natural byproduct of speed.
Done is better than perfect. Especially if you’re searching for market/product fit. Done lets you see if
you get a trickle or a waterfall.
Forcing yourself to allocate less time for each activity allows you enter a state of flow that can get you
pretty close to a finished product, albeit still imperfect.
If anything, you should beware of the pitfall of perfection and all it entails, both financially and time-
wise as you struggle to complete the roadmap you’ve set for yourself.
A good rule of thumb is to only start working on something if you intend to finish it.
And it’s only possible to finish something in a small sprint if the allocated time for that task is short.
That forces you into a creative zone in which you focus on only delivering the most possible value in
the leanest way.
That won’t create a perfect result.
But it’ll get you 70% of the way there.
At that point, you can go ahead and improve/polish it so you can get to a point where you’re 90%
happy with it.
Then stay happy with 90% and move on.
The last 10% improvement represents a diminishing return as compared to the improvement you could
produce elsewhere (from 0 to 70 or 70 to 90) from the point where you stand.
Turn to Occam’s Razor to remind yourself that the best solution is often the simplest, too.
Embrace the fact it’s impossible to do everything at once and be perfect, and produce a workflow to
create the highest possible quality with the least amount of time and effort.
And with that culture in mind, I started by taking stock of the ammunition at the disposal of each
product to better understand what systems need to be created.
I don’t want to recreate the wheel.
In the past, I’ve resisted launching partnership programs as the workflows they required consumed too
much energy for me to be able to fulfill other obligations at once.
Today, new tools are available to reduce that barrier to entry. Since my approach so far has been
fractional services (support, design), utilizing SaaS products to bootstrap those systems is a probably
an ideal example of good enough.
Worth considering is the status of future tasks so I can safely ignore them in the short-term while I
focus on what I’m concerned with at a given point in time.
There’s a mountain front of me, but I don’t need to figure out how to climb it all at once.
30

Instead, I created some checkpoints that I know I need to walk through, and give myself just enough
time and energy to get myself there, while staying happy with 90%.
Everything is organized on a little canvas divided by the moment in the lifecycle when a visitor
becomes a user.
This canvas visualizes my progress constructing different systems that have a good fit with the market
Reconcilely serves as well as the ARPUs enabled by our business model.
Green is done or good enough.
Yellow is work in progress.
Pale yellow means it’s a to-do. But not a focus right now.
Naturally, I’d love to optimize my funnel right off the bat. As mentioned, the app store listing really
needs help.
But I need to zoom out.
Prioritizing growth efforts
Part of my criteria for acquiring products is that these products be very stable while doing one thing
really simply and consistently.
This quality generally results in the products having very healthy install-to—paid conversion rates.
Since both Reconcilely and Postcode Shipping share this quality, I’m much more interested in
accelerating the rate at which new customers enter the funnel since that funnel is already producing at
a good clip.
The good news is that — like many Shopify apps — the products would benefit from implementing best
practices from top-tier SaaS products and bringing those lessons over to the Shopify ecosystem.
There’s so much to do to further increase the conversion rates.
But it might not be the right first step.
31

Consider this:
Say the value we currently generate is x.
The problem is that the total potential locked behind better conversion rates, let’s call that x+y1, is
smaller than the total potential that can be unlocked from creating a repeatable customer acquisition
engine (x * budget).
While conversion optimization helps you make more with what you have, it’s still limited to a ceiling of
what you have.
If I get 20 people with a 20% conversion rate and 100 people with 100% conversion rate, 100 people is
the max I’ll be able to optimize up to.
Another reason why distribution matters more than product is because it represents x * budget.
As you discover a profitable means of acquiring customers from a repeatable process, multiplying the
results from that process is as simple as increasing your inputs, which is something you can very much
be in control of.
Despite there being a lot of potential hidden away behind optimization efforts, the energy it will take to
find them is greater than the energy it will take to create new growth systems.
I have a vested interest to keep launching new systems so I can get myself closer to that repeatable
acquisition process so I can use it to rapidly scale and make the most of the Growth phase.
With that preamble out of the way, there are two main levers I’m usually concerned with in this Growth
phase:
Establishing 1+ repeatable processes to acquire new customers
Discovering our number 1 customer acquisition channel
Respecting our customer acquisition costs
Volume & longevity
Optimize how efficient we are with existing customers
Optimize post-install activation + decrease time-to-value
Optimize trial conversion
Increase customer retention + champions
These main objectives are completely different beasts.
It would take a team to attack them all at once.
Alas, such is the bootstrapper’s life. You’ve got to prioritize.
Now that we understand why acquisition (and not activation or conversion) is our first growth focus,
let’s review some of the channels I’ve selected for each part of the funnel.
In no particular order, my goal is to create good enough results for each of these channels across
different stages of the lifecycle so they can each have a chance to stand out as the channel we should
then swing all of our weight into.
It would probably make sense to focus on Activation, Conversion and Retention tasks (making more of
what we have) after I’ve taken the time to at least establish the following Acquisition systems:
Acquisition
Shopify App Store
32

App Partnerships
App Integrations
Agency Partnerships
Partner Certification
Content Marketing
Search Optimization
Paid Media
Social & Community
Activation
App Store Listing
Post-Install Email Campaign
App Onboarding & In/Out-App Guides
Time to Product Value
Conversion
Free/Trial to Paid Conversion
Expansion Path
Optimizing App Pricing
Behavioural Analytics & Cohorts
Retention
Same-day/1/3/7/30-day+ retention
Experiments to increase retention KPIs
On the execution front, we’re progressing well.
As of February 1st, several new acquisition systems have been created, some of which are already
producing returns, with many more on the way in the coming weeks.
The goal is not to set-and-forget these but rather to build a toolkit that can be used to react to new
opportunities as they arise, and to make it possible to collect result samples from those channels to
better understand what to double down on.
App Partnerships, Affiliate Program, App Integrations, Agency Partnerships have all kicked off in
January and moving forward.
Some of the most fundamental ways to grow on the App Store is by going where the cameras are;
proverbially being featured in section of the App Store itself, or even better, within specific apps that
your target market already uses.
As opportunities to interact with those apps come up, new connections can be made for merchants
from both sides to discover new apps that can help simplify their store operations.
The first batch of channels can be started off without many resources and with zero code, so I started
there.
Agency and app partnerships, affiliate program and app integrations will likely play a crucial role
moving forward, so I’m very excited for the three of those systems to be going live.
33

As they continue to warm up, I’m refocusing my attention towards the new websites so we can launch
the blogs, content production and search optimization to begin attracting customers by providing
resources that accurately respond to their search queries.
Before I can do anything direct-response, I needed to start with Segment on the front-end, since I
didn’t do that yet.
I had to do this so I could effectively quantify the number of users at each stage of the installation
funnel as entered and exited through.
It’s important to know how many installs you get but it’s just as important to know what happens
between the moment an ad is clicked and the moment the app is installed (or not) so you can optimize
that process and remove any friction from it.
This is also true of the front-end interactions after the user has installed, so as to elucidate reasons
behind day-1 uninstalls and/or where and why install-to-paid conversion might be failing.
Thanks the front-end Segment implementation, we also now have the data we need to optimize our
post-install UX, which in this case means reworking the mappings section of the Reconcilely
onboarding flow.
Another benefit of the front-end Segment implementation is that I can now set up pixels for different
ad networks so I can measure my acquisition funnel end-to-end regardless of ad network.
It also makes it possible to start retargeting customers intelligently depending on which stage of the
lifecycle they’re in.
34

I set up Hotjar to start getting some qualitative data about the way customers are using the products
so we can start asking different questions that our data stack is now in a good place to answer.
While making sure that our customer’s data stays private, we now have access to recorded
interactions so we can relive our customer experiences from their perspective and derive hypotheses
from there.
This will come in handy later when trying to optimize activation and conversion. But it also comes in
handy now to explain user behaviour across the top of the funnel.
Between the qualitative data we get from HotJar and the quantitative data we get from Segment, we
have end-to-end visibility and can extend our data platform for any new properties anytime without
disruption.
We can now make data-driven decisions at the acquisition layer too, which until now had been a show-
stopper for all of these systems we’ve been meaning to start building.
That unlocks a variety of new channels for us, like paid acquisition outside of the Shopify App Store.
35

These systems are now up and running and can be used:
tech integrations (with other shopify apps or product-led)
technology partners + co-marketing with other apps (blog, newsletter, partner directory,
recommended apps section in the apps)
service partnerships (certified agency list, accountants)
affiliate program
In February, most of my focus is on building the infrastructure for
producing search-optimized content and pages that rank
cross-selling between reconcilely and postcode shipping
collecting case studies for reconcilely + postcode
engaging influencers on youtube, instagram and tiktok
kicking off audience building + retargeting campaigns
Once those systems are up and running, I’ll swing my weight back towards the product and
what happens when customers install:
App Store optimization
Review pricing plan selection
Redesign onboarding from the ground up
Accelerating time to value + showing it
Trial email campaign
Trial retargeting
The purpose of these systems is to set them up in a way that they can operate mostly on an
automated basis, so I can relegate to check into them once in awhile and adjust my strategy.
And the reason I’d be adjusting the strategy is so I can inch myself closer to profitable spend relative to
my product lifetime value. If any of those channels produce that, I can increase my budget until the
returns from that channel can justify a new hire.
It’s once something clearly works that I can refocus most of my energy into it in pursuit of expanding
and hiring myself out of that process.
And by then I’ll have a clear picture of the metrics a future hire would work with.
And they’d be primed to succeed by doing more of what has worked, and taking advantage of building
all of the optimizations left available via a good enough mentality.
My job at this stage is to discover the thing we should be doing pretty much with 100% of our time. But
the search for channel/market fit can be methodical if you make it so.
It’s easy to get overwhelmed! But you’re gonna make it.
Keep showing up and lay bricks every day.
Scoring system for deals
must-take deals (90%+)
great deals (80%+
good deals (70%)
36

bad deals (<60%)
disqualified deals
Must-take deals tick all the boxes and can be scored at a low multiple. They're no-brainers. Just write
the check and run.
Great deals are fundamentally sound with a strong gut feeling that the asset will overdeliver on its
targets
Good deals may not hit all investment criteria but are good enough not to pass on, especially because I
don't know when the next great or must-take deal will appear
Bad deals fit my investment focus but do not pass my investment criteria. I do not invest in bad deals,
obviously.
Disqualified deals are outside of my investment focus. Stick to what you know.
I use a simple 24-point yes/no grading system to score deals.
✅
Is the app history strong
✅
Is the tech stack manageable
✅
Is the support burden low
✅
Does the app have many (good) reviews
✅
Can this be a buy-and-hold
✅
Can this be a buy-and-grow
✅
Can I close a deal under a 3x multiple
✅
Is the potential cash on cash return 30% or greater
✅
Is it default alive
✅
Is it meaningful revenue
✅
Is churn under control (20% is just too much)
✅
Is the ARPU fairly strong (>$15) for Shopify
✅
Is technical debt under control
✅
Any feature/integration that could make MRR pop
✅
Is net negative churn possible
✅
Is app ranking stable
✅
Is the churn rate acceptable
✅
Is the expansion rate acceptable
✅
Does the expected MRR growth align with fund goals
✅
Is the visit to install conversion rate healthy
✅
Is the the install to trial conversion rate healthy
✅
Is the trial to paid conversion rate healthy
✅
Does it have an expansion path
Tips on what to look in the first moment
What's the growth rate looking like?
What's the churn looking like?
37

Do you have anything on the roadmap that customers want that you haven't yet released?
What are the top 3 customer support queries about?
What's the tech stack?
Who would be staying? The support staff are external I'm guessing?
Do you see any revenue expansion at all (customers upgrading from one paid plan to a higher paid
plan)?
Lastly, I can say I'd be willing to explore a strong offer provided you're open to a small cash balance
component, typically not more than 20% (paid over no longer than 12 months usually).
SureSwift Capital threads
How to evaluate a Micro-SaaS
First, since MRR is a SaaS metric that most Founders track.
Beyond MRR: The basic math behind a bootstrapped SaaS valuation
Calculating your SDE
Business profit before taxes
+founder(s) salary
38

+founder(s) benefits
+depreciation
+adjustments for any other non-essential expenses
= SDE
SDE is similar to EBITDA in that it tries to remove taxes and non-cash expenses. It differs in that it also
removes costs related to a founder’s dual role as both the owner and the operator of the business.
That’s useful for estimating how much a bootstrapped SaaS business is worth, because typically the
founder works both on and in the business, and SDE accounts for that dual role.
That means the founder’s salary, as well as expenses like personal health insurance that usually come
out of the company’s profit and cash flow get added back in.
These kinds of expenses benefit the current owner, and typically don’t get passed on to a new owner
(at least in the same form), so they’re considered “discretionary.” In other words, they aren’t essential
to operating the business.
Not sure if an expense is discretionary?
Here’s a quick checklist:
✓ It benefits the owner (like health insurance)
✓ It doesn’t benefit the business (like advertising) or the employees
(like hourly wages for a contract developer)
✓ It’s documented on your tax returns and P&Ls
Ballparking long-term value with SaaS valuation multiples
Getting back to the original formula for valuing a bootstrapped SaaS business using SDE — it’s time to
look at the multiplier part of the equation. If SDE is an attempt to measure how much cash a business
can bring in to a new owner, then SaaS valuation multiples are a measure of the business’s long-term
potential value.
For smaller, bootstrapped SaaS businesses (that are profitable and growing) valuation multiples tend
to range between 3x and 5x.
Businesses with higher profit margins, TAM (Total Addressable Market) and YoY growth rates, and
lower customer and revenue churn will have multiples on the higher end of that range.
39

On the outside of that range, a lower SaaS valuation multiple can come into effect if the business is
flat, or declining. Or multiples could spike past 5x if your YoY growth is insane, or in a strategic
acquisition (more on those in a moment).
However your current math works out, be careful that your margins and growth rate take into account
your current reality. Sure, in theory any business has the potential to double in size in the next year. It
also has the potential to lose half or all of its customers in the next year.
When would a revenue-based valuation be used for a SaaS company?
If a company is in the very early stages when it’s acquired, or it’s growing more than 50% YoY, it may
make more sense to do a revenue-based valuation since there’s not a stable history to look at with
SDE.
It’s also worth noting that different buyers can put vastly different valuations on a business.
Smart buyers aren’t just buying history, they’re also buying what they think they can help the
business become in the future.
There’s going to be a big difference in the ‘fair’ price between buyers that might bring very different
goals, assets, and strategic direction to a given business. One oversimplified way to look at this is that
some buyers are ‘strategic’ and some are ‘financial.’
‘Strategic’ buyers may be able to get more long-term value (and therefore be willing to pay a higher
price) because there’s a good fit with other ways they’re already making money and/or serving
customers.
That’s why ‘strategic’ buyers might put a purely revenue-based or even technology-based valuation on
a company. But these types of buyers also typically only want to buy bigger companies, so they don’t
usually come into play with smaller SaaS deals.
A purely revenue-based valuation also indicates that the buyer will radically change the operations and
cost structure of the business they’re acquiring, so they ignore the current ops and cost structure.
40

Simple example: the business has a top line revenue of $200k. After operating costs like employees,
your email marketing software and other SaaS you use for the business and servers, you’re left with
$90k. You add another $20k of expenses to your business like your cell phone bill, your annual
Macbook Pro upgrade and so on, then you pay yourself the remaining $70k as a salary. Your SDE
would be the $90k and a reasonable valuation of the business would be some multiple of that $90k.
Much like when you are pitching a client on how many “hours” a project will take, the multiple is just a
polite proxy for what both parties are really thinking about: the actual amount of money being
exchanged. Once I started taking the idea of selling the business very seriously I explained why I felt
the “multiple” discussion was a problematic proxy and just moved to speaking in whole dollar amounts.
If we close in the next X months, my price is Y. I recommend this approach.
At the end of the day, the valuation of a business is where the buyer’s willingness to pay and the
seller’s willingness to sell overlap. The SDE + Multiple framing is just a way to attempt to simplify
communication, but I think just speaking in whole dollar amounts is more direct and sensible.
How to prepare your startup for an exit
How to Prepare Your Startup for an Exit (or Anything Else) - SureSwift Capital, Inc.
https://www.sureswiftcapital.com/startup-exit-strategy-tips/
Only 44 percent of small businesses make it to their fifth year, the timeframe when an acquisition becomes most likely.
FE International Firm threads
How to value a internet business in 2022
Financials
How old is the business?
How has gross and net income been trending for the last 1-3 years? The last few months?
Can a new owner replicate the cost structure? Can they make any savings?
Are there any anomalies in the financial history of the business? If so, are they explained?
Can all of the revenue streams be transferred to a new owner?
How stable is the earning power e.g. are CPMs in this niche on the decline/hard to replace?
Is the owner an influence on the earnings power (i.e. owner-specific earning relationships)?
Traffic
What percentage of traffic comes from search? (i.e. what percentage is potentially at risk from
search engine algorithm changes)
How secure are the search rankings? What is the mix of short and long tail?
How has traffic between trending for the last year? The last few months?
Has the site been affected by any Google algorithm changes or manual penalties?
What is the industry trend (see Google Trends)?
Where does the referral traffic come from? Is it sustainable?
Operations
41

How much of the owner’s time is required to run the business?
What are the owner’s responsibilities? Are there high technical requirements?
What technical knowledge is required to run or manage the business?
Are there employees/contractors in the business and how are they managed?
Niche
How competitive is the niche?
What are the barriers to entry?
Is the niche growing?
What are the recent trends and developments in the niche?
What expansion options are available?
Customer Base
Where does the business get customers from?
How much do customers cost to acquire?
If subscription, what is the customer lifetime value and churn rate?
If one-time, how active is the customer base? Are they re-ordering?
Is it possible to remarket to the existing customers? Is there a mailing list?
Other
Are there physical assets or specific regional responsibilities with the business?
Are there any licensing requirements in order to run the business?
Does it infringe in any trademarks?
Does the business offer any unique advantages? (e.g. trademark)
But How Much Is My SaaS Business Worth?
SaaS businesses typically fall within the 4x – 10x annual profit (SDE) range, and this can be
determined by a large number of SaaS metrics.
In the initial assessment it is useful to filter these variables into a few that have the most influence:
Age of the business;
Owner involvement;
Growth trends; and
Churn and other SaaS metrics.
Evaluating the above metrics helps determine whether a SaaS business’ multiple falls towards the low
or premium end of the valuation spectrum:
Age of the business: A SaaS business with a longer track record demonstrates that it has proven
sustainability and is also easier to predict in terms of future profit. Businesses that are 2 years old are
the preferred entry point, and at 3+ years they start to receive more of a premium multiple. Younger
businesses are still sellable, albeit to a slightly smaller investor audience that may have a higher risk
tolerance.
42

Owner involvement: Part of the appeal of running a SaaS business is the potentially passive and
predictable nature of the income it brings. Businesses that require relatively little time and have a team
in place are more attractive than those that require a lot of owner work. Outsourcing can help here
(more on that later). The other dimension to this is the technical involvement of the owner. If an
investor must replace an owner that is performing a highly skilled role, this will either increase the
replacement cost or put off non-technical investors, which reduces overall demand for the business.
Trends: Few investors aspire to acquire a SaaS business that is declining, and correspondingly few
owners want to sell a SaaS business that is growing rapidly. The key is to sell a business that is
trending consistently and, ideally, modestly upward. Naturally, the faster the business is sustainably
growing, the more the multiple will stretch toward the premium end.
Churn: It is well documented that customer metrics are of vital importance for SaaS business owners
and consequently they are of great interest to investors. Churn, lifetime value (LTV) and customer
acquisition cost (CAC) are analyzed by investors when appraising the customer base and by virtue the
quality of the business’ revenue.
Valuation Spectrum
The following diagrams should give you a good feel of where a business could be valued. For
businesses valued under $2 million, you can expect a 4.0x to 6.0x multiple.
For businesses valued over $2 million, you can expect a 6.0x to 10.0x multiple.
43

While the general valuation drivers above are a key consideration, it’s important to note that every
SaaS business is unique and each has its own priorities in terms of metrics.
As the valuation process goes deeper, more business model-specific factors come into play when
determining the final multiple.
Traffic Valuation
Another approach to determining the value of a website, specifically sites that have yet to be
monetized but have traffic, is the traffic value method. To do this, the buyer must research the top key
phrases that drive the majority of search traffic to the site. Then identify the cost-per-click value of the
keywords. For example, if a site has three key phrases driving over 90% of its traffic, find the CPC in
Google Adwords and multiply that for each phrase by the number of visitors being driven to the site by
that search term. That will give you some sense on the value of the traffic for the site.
The traffic valuation method can be useful for devising a value for a non-monetized site (e.g. sites
primed for AdSense) but falls down against other methodologies with its prescriptive approach to
traffic-only evaluation. Websites that don’t rely on significant traffic (e.g. software or SaaS businesses)
to drive revenue, will be valued significantly below fair market price using the traffic valuation method.
Traffic metrics can be an interesting way to triangulate or sense-check valuations. Justin at FlipFilter
has written a nice article on them that is worth a read for more information if you’re interested in how
to value a website.
SaaS.Group threads
44

The seller side history (an understanding on the persona)
Selling Juicer by Ryan Macinnes.
Read the full article above. This text will only focus on the selling part.
Growing and Burning Out
Our original goal with Juicer was to be able to pay our rents with it. Since Amit and I were 50/50
partners this worked out to being about $3000 per month. We didn’t really expect to actually be able
to achieve this, but it was good to have a goal. We managed to hit this goal in the next few months
after we got our first customer. When it rains it pours. It was a very strange feeling after spending 6
months working for essentially 0 return.
Of course then, a funny thing happened, that neither of us expected or predicted. It kept growing.
Even though we had hit our goal.
So we kept working on it! We kept improving the product, making it easier to use and capable of doing
more. The primary thing I worked on, on a daily basis, was customer service. Every day more and more
customers would contact us, that, after a year or so, it got to be a fulltime job in an of itself.
It was really nice to be this close with our customers as well as being the main developer on the
codebase, as it allowed me to really see the problems and issues with the platform they were having
through their eyes, and it allowed me to notice trends with customer service issues, and improve the
platform to prevent those issues from reoccurring.
Eventually this started to burn me out. I was answering questions all day as well as keeping an
increasingly popular website online (in the end we were getting 100s of millions of requests a month)
all the while also trying to add useful features and improve the User Experience. Yet another reason it’s
a good idea to have a partner: he was able to point out to me that I was burning myself out, and he was
right.
So we hired a customer service person. We were recommended an overseas resource by some friends
who was supposedly good and cheap. They didn’t end up working out because while they were on top
of things, they were unable to do the thing that I really needed them to do: think for themselves.
Essentially they needed us to write a script: if the customer asks question a), respond with answer b).
The problem was, if there was even a slight variation in the question, they didn’t know how to answer it
and would come back to me and I would have to answer it. This resulted in me not really saving
anytime and in fact spending more, because I was still answering all the customer service queries but
also teaching a person how to do it who fundamentally didn’t get better or learn.
So we decided to spend a lot more money and hire our friend Bryan. He was, and still remains, the
best. I can’t emphasize enough how important it is to spend a lot of money on customer service. It’s
worth it both in terms of your customer satisfaction and therefor bottom line, but for your mental
health. Bryan is personable to the extent of being a people pleaser. He almost habitually wants to make
the customer happy. And he’s smart. So you never have to tell him the same thing twice. Bryan is so
good at helping the customers that he could probably build Juicer from scratch now, even though he
has no idea how to develop things. Hire someone like Bryan. He likely saved me from a mental
breakdown.
Thinking About Selling
45

I originally came across Patrick McKenzie (aka Kalzumeus aka patio11) right when I got back from
Japan the first time when I read his amazing article on Japanese Salaryman which blew my mind and
really opened my eyes to Japanese culture. So I looked into him a bit more deeply and it turns out that
he is in the Bootstrapped Startup world. And it also turns out there is a term for what I was doing (that
is to say, starting a startup without venture capital). So we had a lot in common so I started following
him more closely.
In 2017 I came across an episode of his podcast where he interviewed Thomas Smale, one of the
founders of FE International and thought it was very interesting. I had never given too much thought to
selling, mostly because it seemed almost impossible to do, but here was a company that made it
significantly easier.
I mentioned this all to Amit and we started vaguely thinking about the idea of selling. A few people
contacted us around this time with interest in buying us, but we always found that as soon as we
started discussing revenue numbers, they could no longer afford us, which was okay because we
weren’t pursuing the deals seriously, just seeing what was out there.
Juicer had been chugging along pretty reliably and consistently for the last 2 or 3 years, and had really
been on autopilot for the last year as I had been living in Japan studying Japanese full time, so I was
really only working on it in my free time.
But slowly and surely Amit and I started talking about selling more and more. It was around this time
that we read Tyler Tringas’ article about selling his own business. Selling a SaaS business is a lot more
reproducible than say, selling Instagram. With Instagram, you are selling a shit ton of millions of users
who are highly engaged in your platform, but there’s no clear way to determine how much that is
actually worth in real life dollars.
With a SaaS you know how much the company makes every month, you know by how much that
increases every month. You know how much it costs to acquire a customer, and how much money you
will make over the lifetime of that customer (LTV), so valuing a company is extremely straightforward.
Usually you are looking at getting between 2-5x yearly revenue. The difference between 2x and 5x
seems to be primarily based in the yearly growth rate. How much is your total revenue growing every
year? So for a seller (like us) the ideal time to sell your business is RIGHT before the inflection point
where your growth rate begins to decrease (not that revenue is decreasing, just the rate that revenue
is increasing, starts to decrease…hah)
We started doing some math, and the more we thought about it, the more likely it seemed like we were
going to try to sell.
The main reason I was ready to sell though had nothing to do with logic or money, it was all burnout.
And it was a different kind of burnout than I had felt years previously before we had hired Bryan, it was
a slower-burning-burn-out. It came from a few things:
The only customer emails I got were the hardest ones
Even though it wasn’t much work in terms of the number of hours, it was a huge amount of work in
terms of mental bandwidth and background thinking throughout the day
With intercom customers tended to ask a lot more repeat questions
The way I structured my day, answering emails basically first thing that I didn’t have too much
mental energy left over to do stuff for Juicer, let alone work on other projects
Got real tired of the codebase, but was too much effort to update it to something more modern.
46

MicroSaaS Playbook

Recommended

Recommended

More Related Content

Similar to MicroSaaS Playbook

Similar to MicroSaaS Playbook (20)

Recently uploaded

Recently uploaded (20)

MicroSaaS Playbook