Recently, when I’m having trouble sleeping, I look for software to fuzz test.

Earlier this week, I thought back to Fady Othman’s post “Meta Bug Bounty — Fuzzing ’netconsd’ for fun and profit.” It’s a good tutorial about fuzzing code exhaustively.

Like most fuzzing blog posts, I found the work a bit difficult to reproduce because it requires the reader to figure out how to replicate the author’s environment and toolchain.

In April of this year, I sold TinyPilot, the bootstrapped hardware company I founded and ran for four years.

I wrote a post in May that told the story of the sale, but I’d like to share more about the practical lessons I learned from the experience.

In this post, I’m sharing what went well, what I want to improve in the future, and what surprised me about selling my business.

Table of contents

• Details of the sale
• What I’m glad I did
  • Invested heavily in documentation
  • Created a transition checklist
  • Worked with a broker I trusted
  • Avoided seller financing
  • Assumed I’d get nothing after closing
  • Recognized the limits of my influence on the business post-close
  • Revised the broker agreement so that the broker gets paid when I get paid
  • Discussed contentious issues without lawyers first
  • Used dedicated accounts for the business
• What I’ll do differently in the future
  • Offer incentives for a cash buyer
  • Discuss key contract terms earlier in the process
  • Begin working with a lawyer earlier
  • Create an unofficial “small stuff agreement” with the buyer
  • Announce the sale to my team later
  • Don’t catastrophize every setback
  • Reveal vendors earlier, but put tighter restrictions in the LOI
  • Eliminate inventory from the broker’s commission
  • Assume from the start that nothing written is private
  • Define what happens to money flows around the time of closing
  • In the transition agreement, value calendar days more than work hours
  • Disconnect non-transferable accounts from business email before closing
  • Take even fewer dependencies on Google
• What surprised me
  • Due diligence is unbounded, high-stress work
  • As you prepare to sell, everything costs 4x as much
  • You don’t strictly need a broker to sell
  • If the non-compete is too restrictive, you’re screwed
  • If there’s no cap on liability, you’re screwed
  • Buyers have incentive to keep the seller happy
• Resources that helped me prepare

Details of the sale

• Sale price: $598,000 (2.4x annual earnings)
• Broker commission: $88,900
• Legal fees: $18,297
• My profit from the sale: $490,803
• Payment terms: Full cash payment at closing (no earnout, no seller financing)
• Seller obligations: 30 days of free consulting (max of 80 hours total)
• Lifetime profit from business (including final sale): $920k over four years

What I’m glad I did

Invested heavily in documentation

Before I started my first business six years ago, I read the book Built to Sell by John Warrilow. It encourages founders to build businesses that run smoothly without the founder actively managing day-to-day activities. An effective company should have a set of well-defined processes and a team that knows how to execute them.

Last week, I stumbled upon a reddit post announcing that the author, Charles Marohn, was giving a free talk near my town the next morning. Marohn is the author of Strong Towns, one of my favorite books of the last few years. So, my wife and I attended the talk and enjoyed it.

The talk is based on ideas from Marohn’s new book, Escaping the Housing Trap, which I haven’t read yet, so these notes are from memory.

A few weeks ago, NVIDIA released Nemotron, a large language model that they derived from Meta’s Llama 3.1 70B.

NVIDIA claimed at release that Nemotron outperformed GPT-4o and Claude 3.5 Sonnet on certain benchmarks. That was exciting news, as my experience with self-hostable AI models is that they trail commercial models by about a year in terms of accuracy and quality.

I decided to test out Nemotron with a few simple coding tasks to see how it compared to commercial models like Claude 3.5 Sonnet.

Fuzz testing is a technique for automatically uncovering bugs in software. The problem is that it’s a pain to set up. Read any fuzz testing tutorial, and the first task is an hour of building tools from source and chasing down dependencies upon dependencies.

I recently found that Nix eliminates a lot of the gruntwork from fuzz testing. I created a Nix configuration that kicks off a fuzz testing workflow with a single command. The only dependencies are Nix and git.