This was originally posted on the Codetree blog in 2016. We sold Codetree in 2018.
What's it like buying a small software business? In this post we’ll walk you through the process of buying Codetree - a side project that we believe can be a big business. We'll also describe some of the mistakes we made, and unpack our thinking during the negotiation.
The process to buy a business
Here’s the high level process we used to buy a software business:
- Finding the right business to buy
- Offer and negotiation
- Sign letter of intent
- Do due diligence
- Sign Asset Purchase Agreement
- Close
1. Finding the right business to buy
Three days after we decided to build an Issue Tracker, we heard from FE International. FE is a web app broker and they had a B2B SaaS Project Management tool for sale. We had talked to FE a few years back about selling another SaaS business that we were running. Since talking to FE, we’d seen 60+ prospectuses from them, but nothing had been promising enough for us to buy. We had even looked an an issue tracker. We passed on it because it seemed like it sold to agencies for project work, a segment that is prone to high churn.
But this one sounded so promising that I sent an email to my partners:
It caught our eye because:
- Codetree was a good product
- It was in a space we had decided - three days prior - to work on
- It had existing customers we could call up to learn from
- The asking price was affordable and we already modeled out what the payback period could look like for various purchase prices here
- It had a steady stream of new trials per month
- The tech stack was familiar
- The founder, Derrick Reimer, had co-founded Drip. We were familiar with Drip because his co-founder, Rob Walling, has an excellent podcast called Startups For the Rest of Us. Rob seems like a good guy, and so Derrick and Codetree benefitted from a halo effect / social proof of being associated with Drip and Rob.
- The prospectus stated Derrick was selling to focused on Drip, which was a plausible reason to sell.
- There was lots of room to manoeuvre in the niche. We could make it a great layer on top of GitHub issues, or build layers on other services like BitBucket, or build a standalone app.
The key risks were:
- Github would improve its Issues product and render Codetree irrelevant
- Existing customers weren’t real
- New customers weren’t actually signing up
- Would new users keep coming
We asked some detailed questions over email to unpack some of the above questions. We also hopped on a phone call with Derrick and his broker from FE - David - on May 18th.
On our end, we had three goals for the call:
- Convince Derrick we could pay. When we sold our previous SaaS business, we learned that sellers get a lot of lookie-loos. If the potential buyer can’t afford the price, the conversation is a waste of time.
- Convince Derrick we’d make a good home for Codetree. Even if you get a check for your baby, you want it to end up in a good home. We’d been following Drip and the Micropreneur movement for a long time, so we had a lot of common beliefs. We’d also sold a business before so we had an idea of the kinds of things we wanted to see in a buyer to make us feel good about this (smart, credible, pragmatic, knowledge of the market, experienced, nice).
- Address some of the risks we saw above. This was an opportunity to unpack the risks we saw a little more.
After the phone call with Derrick, we debriefed (one sentence redacted for confidentiality reasons):
We modeled out what various offer scenarios looked like along with how long it would take to get paid back (those are the actual spreadsheets we used).
Seeing no major red flags, we decided to make an offer.
2. Offer and Negotiation
Before we talk process, let’s talk about a key element in any negotiation: your BATNA. BATNA stands for “Best Alternative To a Negotiated Agreement”. The book Getting to Yes popularized the acronym. It means: if you have to walk away from this negotiation, how good are your other options?
In this case, our BATNA was not good: start from scratch, or try and find a better issue tracker to buy. It put us in a poor negotiating position and affected our psychology. You’ll see how it made us less willing to walk away from the deal and less willing to push back on terms we didn’t like.
Deciding on what to offer
The asking price was $128,000 USD or 3.5 times Seller Discretionary Earnings (SDE). In their great article on valuing businesses under $5M in revenue, FE International describes SDE:
SDE is the profit left to the business owner once all costs of goods sold and critical (i.e. non-discretionary) operating expenses have been deducted from gross income… more easily it is described as: Revenue minus Cost of Goods Sold minus Operating Expenses plus Owner Compensation.
In short, it’s the amount of money that the owner COULD pay himself after expenses are deducted from revenue.
Based on the factors in the FE SaaS valuations article we felt 3.5x was not unreasonable, but was on the high side.
We included these items in the offer in addition to purchase price:
- Consideration (cash, terms, structure etc)
- Closing date (this also forms an important part of the decision)
- Source of funding (we will require proof of funds once the offer terms are accepted)
- Due diligence requirements (an outline of any due diligence must-haves to ensure we can accommodate them for you)
- Additional deal terms (e.g. Training hours, non compete, consulting etc)
Once we agreed on terms, we’d formalize the offer into a Letter of Intent (LOI).
Now, FE International has an “early access” list who see deals before they go out to the general public. We were on that list and thus saw this deal before it was posted on the web or sent to the general email list.
Since this went to the early access list, we wanted to make an offer for Codetree before it went to the general list. Which probably turned out to be a rookie mistake.
Here’s our first offer:
May 19, 2016
Hi Derrick,
Thanks for taking the time to talk with us yesterday. We think you’ve done a great job building Codetree and it has a lot of potential. We also like and know the issue tracking market. We’re excited to make you an offer and believe we’ll provide a good home for Codetree to grow.
Offer
We’d like to make an offer to acquire Codetree with the following terms:
Consideration
We’d like to offer you an all-cash offer of $103,500 USD (2.8x SDE).
Closing Date
We’re motivated to close ASAP. Barring any unexpected issues found in due diligence, we would aim to close within 30 days.
We believe the major factors impacting close date are:
Your turnaround time on providing items for due diligence
Our respective lawyers reviewing the purchase and sale agreement
Our accountant reviewing Codetree’s financials
Our review of code and metrics
Source of funding
Cash in hand.
Due diligence requirements
Here are the items we’d need for due diligence:
Google Analytics, Baremetrics, Stripe, and Mixpanel data from 2015 to present
Income statement and balance sheet for 2015 and 2016 YTD
Bank account + credit card statements for 2015 and 2016 YTD
Visit to trial conversion %age from 2015 to present
Trial to paid conversion %age from 2015 to present
2 customer calls
Live code walkthrough
Additional deal terms
We’d also ask for the following terms:
A non-compete prohibiting you from working on project management or issue tracking tools for two years from closing date
A linking agreement to keep two links to Codetree up on ScalingSaaS for two years from close date [http://bit.ly/1W3EU2B](http://bit.ly/1W3EU2B)
A non-disclosure agreement prohibiting you from publicly disclosing the selling price or number of paying customers at close
You make yourself available for 5 hours of training / support per week for 30 days after closing date
Factors Impacting Valuation
For us, risk is one of the key drivers that determines valuation. To understand the risk associated with acquiring Codetree, we looked at several factors that FE lays out here: http://bit.ly/1OCj1y4.
Age
Codetree launched in Jan 2015, making it a little under 18 months old. We are optimistic about Codetree’s potential, but its track record of generating predictable and growing cash flow is not yet proven.
Owner Involvement
Although Codetree is on autopilot right now \[ed: it’s not anymore!\], if left in this state, it will slowly contract as competitors’ products will improve while Codetree’s won’t. We believe heavy involvement from technical owners over the medium term is required to grow it.
Trends + Churn
Growth has been flat since October 2015. Codetree appears to be growing and churning revenue at roughly the same pace.
Customer Acquisition Channels
Codetree seems to reliably generate a small number of trials via search and the GitHub Integrations directory. Codetree hasn’t yet found a scalable and reliable way to acquire customers, and that’s one of the biggest risks to an buyer.
Customer Concentration
Codetree’s customer concentration is low, which is great. Unfortunately, because the total number of customer is small, losing several customers at the highest price point presents a not-insignificant risk to revenue.
Customer Competition
Codetree has several direct competitors (ZenHub, Huboard, Waffle), a potentially reasonable substitute (GitHub Issues), and other major players in the Project Management space (JIRA, Pivotal, etc). We believe that competition for customers is high.
Product Lifecycle
You’ve built a great foundation for Codetree, but it’s not yet a mature product. There’s lots of product development to be done before an owner would be able to focus more on other parts of the business.
Technical Knowledge
Because Codetree is a tool for developers and development managers, we believe technical knowledge in an owner is highly desirable.
Competition
We believe the GitHub Issues niche is competitive and becoming more so. ZenHub is the biggest direct competitor given their access to capital. We believe GitHub Issues presents the biggest risk because it’s heavily funded and presents major platform risk.
MRR vs ARR
Codetree’s MRR-to-ARR ratio is healthy.
There are significant risks associated with a purchase of this size, but we’re excited about this opportunity. We think our combination of Micropreneur mindset, SaaS experience, and interest in the dev tools space will make an excellent home for Codetree to grow and thrive.
We’re aligned with you in wanting to close quickly. We think that our 40+ combined years of software development experience will make this a fairly painless and fast transition for you, and we’re excited to move forward as soon as possible.
Thanks for your consideration,
Arif Bandali
Kareem Mayan
Ryan Stocker
David and Derrick declined the offer.
The 2.8x multiple was based on the comparables that we’d been looking at along with Codetree’s risk profile. We asked David to help us understand the asking price:
A brief aside: turns out the early access list is brilliant – for the sellers. FE’s job is to get the best terms possible for the seller. One way to do that is to test the market and see what price your deal will get in the early access period. If you don’t get an offer you like, you get to go to the wider market at the end of the week. This gives the seller more information about what the market says their app is worth. It also creates urgency in the mind of the buyers (“if we don’t buy it now, then it’s going to a wider pool on Monday!”)
Or at least, that’s what it did for us. Remember how bad our BATNA was? We really didn’t feel like walking away from this deal, but we had made a mistake.
Before making the offer, we had failed to play out the scenarios to their conclusion and determined our next move.
For example, it could have gone like this:
Scenario: we offer 2.8x SDE
| Potential response | Our options |
|---|---|
| They accept. | Celebrate! |
| They don’t accept, but lower the asking price. | 1. Accept their counter 2. Try and negotiate a lower price 3. Walk away |
| They hold firm on asking price. | 1. Increase our offer 2. Walk away |
Doing this would have helped us understand the ways the negotiation could unfold. We would have been able to discuss the scenarios more rationally with biases like Scarcity Bias playing less of a role in our decision making.
But, since they were holding firm on price, our options were to increase our offer or walk away.
The difference between asking and our initial offer was $24.5k, or a little over $8k for each of us three partners. The question for us became: was it worth $8k each to walk away from this deal and start a product in this space from scratch?
The answer: heck no.
We believed that in the our hands Codetree could be a very good business. Given our BATNA, we decided to offer Derrick’s asking price. It was Friday around 6p when we sent over the offer, and we gave Derrick until Sunday at 9a to answer. We didn’t want him to have a full-price offer in hand to negotiate against when the deal went to the wider market on Monday.
On Saturday at 930a, Derrick accepted.
3. The Non-Binding Letter of Intent (LOI)
FE International supplied a template for a non-binding letter of intent. Since it was non-binding, either party could pull out of the deal at any point for any reason. The letter spelled out the terms and conditions that we agreed to in principle.
The deal was set to close on June 7th after about two weeks of due diligence.
4. Due Diligence (DD)
Due diligence is where you try and discover where the product, marketing, and revenue bodies are buried.
Here were the key risks we needed to understand:
- Github would improve its Issues product
- Were the customers real? How engaged were they?
- Were users regularly signing up?
- Would new users keep signing up?
To address these FE offered:
- All supporting financial, operational and technical documentation
- Live screen share sessions for source code review (as many as we wanted)
- 1-2 customer interviews where we posed as Codetree customers satisfaction agents
- Whatever else we needed within reason
FE has a great article on advanced due diligence here. We pulled their spreadsheet template for tracking DD tasks. Here’s our list:
The bold items were things we needed to really feel good about to proceed with the deal.
Here’s what we looked for for each bold item:
Traffic sources
Is traffic highly concentrated in a handful of sources? If so, how likely was it to go away?
Visitor → Trial conversion and Trial → Signup conversion
We wanted to know how many visits we needed to get a signup so we could a) see how much upside there is in the funnel, and b) model customer acquisition costs.
Signups by referrer
We know where traffic is coming from; where were signups coming from?
Source code review + GitHub API integration
How hairy would it be to learn the codebase and start fixing bugs and adding features?
GitHub Issues Risk
How does GitHub view partners who build on their platform? How likely is it that they’ll improve Issues?
Revenue and expense verification
Do revenue and expenses line up with the Profit + Loss statement in the prospectus? We found a red flag here that we’ll get to.
Cancellation reasons
Why are customers leaving? Are the reasons fixable or not?
Stripe revenue verification
We needed to make sure that the revenue from the bank account was from the Codetree Stripe account. A formality - Derrick was trustworthy - but we’d be stupid not to confirm.
Support ticket analysis
What kinds of problems were customers having? How did they talk about the product? Were the happy or unhappy?
Customer phone calls
How do customers talk about Codetree? How is it integrated in their workflow? How could Codetree help them even more? We spoke to two customers who gave us pretty fair and balanced views on the product and how it worked for them.
Engagement data
How often are customers using Codetree? What are they doing in it?
Due diligence was a pain but gave us peace of mind that we were making a good decision.
Revenue and Expenses Red Flag
We only found one red flag in due diligence. It was a discrepancy in actual revenue and expenses vs what was in the profit and loss statement (P&L) in the prospectus. Since the purchase price was a multiple of earnings in the P&L, this had the potential to non-trivially lower the price.
Credit card statements showed that SDE was overreported by $652. Based on a 3.5x multiple on SDE, our $128,000 offer should actually have been $2,282 less ($652 x 3.5).
We pushed back on this, and on adjustments at closing.
Adjustments at Closing
Codetree collects money before the service gets delivered. An annual customer would pay for a year on e.g. January 1st for service over the next 365 days. And a monthly customer would pay on e.g. June 1st for service over the next 30 days.
Adjustments at closing are a money transfer from seller to buyer. This is so that the buyer gets the revenue for the service he’s delivering after the purchase occurs. Adjustments are usually reflected in a lower purchase price.
Here’s an example:
Let’s say the seller collects $1200 from a prepaid annual customer on Jan 1st. The seller ends up selling his company on June 1st. The seller has only delivered service for 151 days, but has collected payment for 365. So the seller would transfer (365-151)/365 * 1200 = $703 to the buyer at closing. This $703 represents 214 days of revenue that the new buyer would service after the purchase, until the customer was up for renewal again.
Revenue collected but unserviced by Derrick totalled $4,223 as of our June 7th closing.
Negotiating the Revenue Discrepancy and Adjustments
We let David know about the discrepancy and adjustments and expected the price to be lowered accordingly.
David pushed back, basically saying that May’s earnings were up, so if FE listed the business on June 1st, the actual asking price would be $135k. He ignores the annual unserviced revenue and says that if we took the $2.1k in unserviced monthly customer revenue, and multiplied it by 3.5x, and subtracted it from the “new” purchase price, we’d net out at roughly 128k (135 - (2.1*3) = 128.8k).
Remember, FE’s job here was to get the best price for their client. Let’s unpack this response a bit:
- The purchase price was $128k, not $135k. One reason for the big earnings bump in May was an annual client. Their revenue for valuation purposes shouldn’t really be lumped into a single month - 1/12th of it should be booked every month.
- We were asking for unserviced revenue to be removed from the purchase price, not unserviced revenue * 3.5x.
- We weren’t sure how to value the impact of collected but unserviced revenue on purchase price. It inflated the purchase price because there were no expenses booked against it yet, but we ran an analysis and found the difference to be not worth negotiating.
- He ignores the fact that unserviced revenue is actually 4.2k, not 2.1k.
tl; dr - we thought David was using convenient numbers to get the best deal for his client.
Our crappy BATNA loomed large, and we weren’t willing to lose the deal over a few thousand dollars. We didn’t even push back on the expenses discrepancy - we conceded it.
But we looked at the data and called David out on booking an annual sub in May to inflate MRR. We also pushed back on the adjustments at closing.
David responds by ignoring the fact that he’s counting all of the revenue of an annual sub as profit and reiterating his point.
We respond once more:
David says no to adjustments at closing. He concedes the point that in “normal” deals of this nature we’d get $4k off the purchase price. This deal, apparently, was abnormal because there were other buyers in play.
Gut-check time
So, gut-check time. How hard did we want to push back on this? Were the other buyers really serious, or had they just expressed some interest? We were at the end of the due diligence period. If we pushed back, would Derrick really want to go through all this with another buyer, only to end up with them insisting on the same adjustments?
Odds are high that if we pushed back, David would have either conceded at least some the adjustments. But maybe not - maybe it would have been take it or leave it, in which case we’d be no worse off.
In the end, we didn’t even bother to find out what David would have done if we made the adjustments a point that we were willing to walk away over (or at least had them think we were willing to walk away over it). We decided that it wasn’t worth $1.4k each to potentially lose the deal so we conceded the $4.2k adjustments at closing.
Lesson: if you’re going to push back on price you need to be willing to walk away if you don’t get what you want.
David did a great job for his client. If we ever sell a SaaS business, we’d definitely look to him and/or FE as representation.
5. Asset Purchase Agreement
After getting beaten like rented mules on the purchase price, David sent us an Asset Purchase Agreement. It’s a legally binding contract to purchase the Codetree assets from Derrick’s LLC. There were a few minor clauses that we wanted tweaked (clarifying Derrick’s non-compete, making sure we had enough time to evaluate the assets, confirming that we could talk about the deal publicly in articles like this), but we sorted them out in a day over email.
6. Closing
We funded an Escrow.com account with the agreed-upon amount. On closing day, once the funds in Escrow had been verified, Derrick sent over passwords to Codetree and all the services it uses. We started the “inspection period” in Escrow, which was set to three days. We had three days to verify the assets were delivered as promised. At the end of three days, if we hadn’t raised a red flag with Escrow.com, they would release the funds to Derrick. The assets were great, and funds were released after three days.
We were officially the new owners of Codetree.