With a signed LOI in hand, due diligence started quickly. Initial diligence was over a multi-hour zoom call where the seller answered several questions and walked through all the major accounts associated with the product. This included billing and customer databases (Stripe), infrastructure (AWS, Heroku) and operations software (Email, Netlify etc.). There were a few critical components to the diligence process that acted as checkpoints for moving forward or call the deal off.
Do a code walkthrough - I am not a ruby expert, but I am more than qualified to evaluate a codebase. If you don’t come from a technical background, find someone who stands in your corner during this step (feel free to contact me if you find yourself in such a position: dan@launchfirstagency.com). If possible, ask for data flow diagrams up front before a code walkthrough so you get a sense of how the thing you are buying actually works.Â
Test it out yourself - no seriously. It is shocking reading through some other PE blogs that pour over financial numbers and marketing opportunities, but ignore the UX fundamentals of the product they are buying. Use the product end to end several times and hit with a hammer as hard as possible -- its ok if it breaks, bugs happen. Keep a running log of fixes, ranked by priority, that need to be taken care of post closing. If you run into any huge issues, insist the seller fix those before moving forward or take the estimated cost of repair out of your deal price. This is again an area where you may need domain expertise. Â
Walk through the books on a live screen share - Don’t take screenshots or excel sheets for proof. Walkthrough customer accounts in their payment portal (Stripe, Chargebee, etc.) and get exact numbers, you will want to use these to model out LTV, CAC and margins later on.Â
Walk through an end to end deployment of all pieces of infrastructure - Look for errors or bottlenecks in this process - smooth deployment and operations of a tech stack are a godsend when you are in a bind and can pay huge dividends later. Inversely, if they are manually copy pasting files into a server that has all its ports exposed, you may want to seriously reconsider the purchase. DevOps is an expensive and time consuming part of a software business. All the same, it is wildly important.
Look for consistent operating processes - There is much more to software products than shipping code. Look for places in current processes where the remote may fall into the couch cushions. Have the seller document these thoroughly and do not forget to review before closing. You want to make sure you know how to run the damn business you are buying.
When you get into the diligence process you need to place the burden of proof on the seller. Do not be afraid to walk away from the deal if something doesn't smell right. The best deals are sometimes the ones you don't make.
Save the peripheral stuff for last.Â
Reviewing Hexadecimal’s Microsoft ad account wasn’t a primary piece of diligence. However it did provide evidence of potential performance of marketing channels for the product. I always take data like this with a grain of salt as advertising can be a bit of an art, even with the plethora of data and analytics available today.Â
At the end of this, you are really looking for a few red flags: Financial, IP (trademarks, infringements etc), structural, operational and security. Because it is an asset purchase, there isn’t much need to worry about employees or labor issues. (The most expensive overhead walks on two legs). If there are employees, you need to get copies of their job descriptions, determine who is worth keeping, and then figure out a way to compensate them that locks them into working there for a minimum time period. Finally, there should be PIIA agreements already in place. If not, this should throw up a red flag. You may need to have retroactive agreements put into place (consult an attorney if you bump into this situation). In either case, as part of closing, you will want everyone to re-sign their legal commitments to protect all IP and not compete directly with your business.
What’s in the final contract
Given the size of the deal, I opted to not use a lawyer and instead use LawDepot to create a templated purchase agreement. I don’t recommend doing this if you are spending a substantial amount of money. After finishing the contract, and adding a few pieces to the Reps & Warranties section (see below), I had a family member who is an attorney review the document to make sure I wasn’t making any gross errors.Â
There are a few major parts to the final Purchase Agreement that I want to point out:
Purchase Price - Â This section breaks down, in detail the allocations of purchase price to specific assets. For Hexadecimal, this included items such as code, customer goodwill and marketing assets. We included an exhaustive list of accounts and collateral in Exhibit A (this took the form of a long notion board each with detailed descriptions of the item being transferred). Below is how the pricing breakdown appears in our Purchase Agreement:
Representations & Warranties - These are effectively legal promises made by buyer and seller in a Purchase Agreement. Things typically included are representations that the underlying IP/code are actually owned by the seller, and they are legally allowed to sell said IP (i.e. they didn’t steal this product from someone else). Beyond the standard representations in the template I added a few additional items that had the seller represent they were the sole owner of all assets (no ex-cofounder was gonna come find me post closing) and that all marketing materials were original and solely owned by the company.
Non-solicitation and non-competition - This language explicitly states that the seller cannot solicit (try to pitch) current customers of the product. The non-solicitation section for a larger acquisition also typically applies to sellers not being allowed to solicit employees to come work for them at different company. In our case, there are no employees, so all we care about is preventing the seller from soliciting customers. Our non-compete period is one year from closing and is clearly outlined in the agreement as seen below:Â
No assumption of liabilities - The agreement contains a section dedicated to clarifying that the buyer is not taking on any liabilities (debt or other obligations) and that the seller indemnifies the buyer entirely of such claims. This is one upside of an asset purchase. In an asset purchase you can cherry pick what you remove from a company and typically you pick to not take on that company's liabilities if you can avoid it.
Payments and disbursements - This clearly outlines the process for escrow and payment release. In our case, we ended up not following the agreement to the T but instead broke our payment into two tranches to simplify the closing process.
Closing conditions - There is a section for both buyer and seller that indicate the conditions needed to be met to proceed with closing. Closing is considered complete on the final transfer of assets or a certain threshold of assets. Once conditions are met, it is expected that payment was released based on the payments and disbursements section of the contract.
There were several other important sections such as severability, notices, confidentiality and governing territory (e.g. what court system will decide if there are issues arising from this agreement). Lastly, a signature for both parties.Â
With such a tiny transaction, the Purchase Agreement ran only 17 pages long (compared to a much larger acquisition agreement that will typically run into the hundreds or thousands of pages). The Purchase Agreement was sent and signed without any redlines from the seller. After inking my own John Hancock, we were on our way toward closing in the next seven days.
Closing
With diligence finalized and a contract signed, it was not a challenge of figuring out how to pay the owner of Hexadecimal. Initially we looked at using escrow.com, but given his current residency in contrast to where his business bank accounts were maintained, the platform would not work. Thankfully, after having spent several hours together and building rapport, the owner was OK with the idea of invoicing me via Payoneer.Â
We opted to split payment into two tranches. The first would be sent after initial IP was transferred. This included GitHub access, AWS access, marketing page access (on Netlify) and password access to all major peripheral accounts. The second payment was released once Stripe customers were transferred into the new parent account I had created.Â
We ran closing over two separate Zoom calls. After the two calls, there was some back and forth to update some configurations to use the new Stripe account and change ownership keys. Once we had verified the new Stripe account and the platform migration was complete, I released the second payment.Â
Looking forward
I was very fortunate to have established a great working relationship with the former owner. He has been a great help in troubleshooting some small issues since the closing and continues to do work on the platform at an hourly rate (yes, we already burned through those initial hours of work he put into the contract).Â
Now that the platform is fully operational and migrated into the possession of Launch First Agency, I have three main goals for the next 18 months:
Grow from ~$155 MRR to $10,000 MRR.
Expand product offering to get to feature parity with all major platforms
Introduce a new features I am not quite ready to unveil that will set this platform apart
Over the coming months I will be documenting the journey to $10k MRR and cover attempts to grow including:
Paid advertising
SEO
Community Building
Content Marketing
Sponsorship
Partnerships
And More!
Now comes the fun part... :)