How we almost acquired another company and why we didn’t.
Last week, we were going through due diligence to acquire another startup — an ancillary product to our core solution.
This isn’t a normal scenario for a lean 8-person startup generating $55k/mo, so how did we get here?
How did we get here?
Earlier this month, a company, I had been tracking since inception, sent out an email announcing that they were sunsetting their product — a simple solution for freelancers to invoice their clients.
The product was in line with our vision of building the operating system for marketing agencies, so I immediately shot the founder a reply:
What’s your plan for the [product name redacted for pirvacy] product/code?
The founder quickly responded:
We are letting it sit dormant… no plans.
Seeing the opportunity, I sent over a proposal; something along the lines of, “if you’re interested, we’ll keep the code alive and compensate you for it. Are you interested?”
He said they were.
The obvious next step was making sure we were in the same ballpark of price, so I sent over an informal offer and the ball was rolling.
Over the next couple of weeks, we dug into the product, researched the payment processor space, and surveyed our customers for interest.
Being such a small team, we need a product that would take minimal effort to stand up and integrate into our existing ecosystem.
We had to fully understand the legal implications of handling money and the different methods for processing payments: ACH, debit, credit.
And lastly, it was critical that our customers actually wanted a solution like this and, more importantly, were willing to pay for it.
Learning the codebase
It was important for us to understand the code, how it would integrate with our existing system, and the amount of effort it would take to maintain it moving forward.
We also wanted to see that the previous contributors who built the system were passionate about their work — they were. check.
The next step, in no particular order, was understanding the following questions:
- What other services would we need to integrate with (Stripe, Dwolla, etc…)?
- What were the operating costs of the system?
- What did test coverage look like?
- What language was it built in? How difficult would it be to migrate it to the language we built our core product in?
- Did they have monitoring in place?
- Would they be willing to join the team and help maintain the product?
- What was the throughput capacity and scalability of the current system? Which part would break first?
Their team was extremely helpful and diligent in ensuring we had all of these questions answered and we completed a thorough code review.
Understanding the payment processing space
The next step was understanding the nuances, red-tape, and legal requirements around the payment processing space.
What are the different methods for transferring money between two parties and the associated fees of different 3rd-party providers (Plaid, Dwolla, Stripe)? Can we take a cut of the transaction, and if so, how do we need to structure our contracts to ensure we don’t need to register the business as a financial institution?
How long does it take for the money to actually transfer? What if the sender cancels the transaction mid-way through, but we already sent the money to the final recipient… how much of a risk are we willing to take?
The founders of the other company kindly shared their knowledge of the space, and we tapped on a couple of experts to shed some light from their perspective.
Once we felt like we had a good understanding of the implications of becoming a payment processor, we surveyed our customers.
Do our customers even want this?
What’s the point in building or buying a product if no one is going to use it.
We sent a survey to all of our customers with 2 main goals:
1. How happy are you with our current product — social media marketing for agencies?
2. How do you bill your clients today and would you be interested in a white-labeled, integrated solution?
On the surface, the survey results were promising — roughly 52% of our total customers wanted this new, proposed solution and 63% of our “champions” wanted this solution.
Of the folks that were interested, what are they using today to bill their clients?
Ignoring the ‘Unknown’ response, a large number of our customers currently use Quickbooks to invoice their clients. But, of the folks that said they were interested in our proposed solution, only a portion of them are using Quickbooks. In other words, it appears that our customers on Quickbooks are largely satisfied with the solution.
We began to ask ourselves, if Quickbooks is already solving the problem, does it really make sense to re-invent the wheel? Well, maybe, but it’s going to take a solution that is 10x better.
Why we decided to pass on the acquisition
While we were impressed with the product and felt like we had a good grasp on the payment processing space, there were still a few concerns we couldn’t get over.
- The product would need to be 10x better than Quickbooks to supplant existing solutions and capture a considerable share of the market. We don’t have the resources to divert away from our core product to build a 10x better solution, yet.
- There isn’t much money to be made with a small volume of transactions. During our due diligence of the space, we discovered that consumers expect ACH transfers to be free, and we also discovered that payment systems (Stripe, for example) charge a high transaction fee (2.5%+) for credit card processing. This means the only payment form that would lead to a decent margin is debit cards. After doing more research, a small number of businesses or consumers pay with debit cards.
- Our core product needs more work, and we don’t want to shift resources away from it. The first portion of our customer survey was gauging customer satisfaction. We asked the question, “how would you feel if you could no longer use Cloud Campaign?” An astounding 56-percent said they would be Very Disappointed. But, almost 15-percent of our customers said they would not be disappointed clearly showing that we have more work to do before we can start to focus on other products.
Coincidentally, during this process, I was reading Rand Fishkin’s Lost and Founder. One of his larger regrets when building Moz was losing focus by trying to build too many products rather than focusing on making their one product best-in-class. The timing couldn’t have been better. Deep down inside, I knew this was the right answer, but the excitement of taking a new product to market quicker was blinding.
Now equipped with the data from our customer survey, we are doubling down on our core product focused on making social media management more scalable for marketing agencies.