Startups

Lessons learned from starting a company and winding it down

In my last piece, I announced the launch of the product that my cofounder and I had been working on since the beginning of the year. Due to a confluence of circumstances, we decided to wind it down. Now that the dust has settled, I'd like to share my thoughts on the experience from the human, business, and technical sides.

I chose a solid human in the form of Matt Michie to join me on this venture. He and I are cut from the same cloth in many ways both as people but also as technologists. He also brought significant experience in building companies that I completely lacked which helped us get bootstrapped in a way that would be fair and relatively future proof. In particular, even though we were a tiny company with nothing but an idea and the ability to code, we set up a Delaware C-Corp with a four year vesting schedule for the shares. If we hadn't decided to wind down operations, this would have mattered a lot versus immediate 100% vesting. For example, if either Matt or I had continued on with Steelcut and if we had instant vesting, then the member who left would have an equal stake with the member who stayed and continued to build the company. This would have been wildly unfair to the person who continued so Matt was wise in building that structure into our C-Corp. We used Stripe Atlas which is actually pretty neat, not only to help us build this structure but also for things like guiding us through the process to file 83b forms with the IRS. If you build a startup, get with your accountant to help you file that form. Not doing so can cause a huge tax burden on illiquid shares down the line. Altas was also helpful in dissolving the company. They basically have a "Dissolve" button that takes you step by step through the process of filing the forms with the state of incorporation and paying whatever taxes and fees you owe. We will still need to file 2024 taxes for the company early next year but we already have the forms filled out from the data in Quickbooks. Everything is pretty straightforward on that front since we didn't have any revenue. In the end, I found that structure to be perfectly fine. It cost about $500 to get started with Atlas and about $900 to dissolve the company using the provider they recommended. Matt and I both lent the company $2,500 and even after the startup and shutdown expenses, we'll get a bit of that back. We owe this in large part to Matt's legendary AWS skills. Our AWS spend was on the order of $2/day in the beginning and only about $4/day at the end. Other expenses included buying the domains (Gandi.net), Quickbooks Online, hiring a bookkeeper to get us bootstrapped in Quickbooks, Github Organization and Copilot, Claude.ai, Google Workspace, and a registered agent to receive mail and give us an official address. Our burn rate was under $100/month.

When you start a business, people come out of the woodwork to help you. My dear friend David Cantu was a constant inspiration and source of guidance. Through him, I met Chad Cohen who is a veteran CFO who gave me great advice and connected us with some of his business contacts. (Check out his startup, Scala Advisors if you're in the market for a fractional CFO or other financial guidance for your startup.) I met with some of his contacts who offered a ton of useful guidance and insights. It's humbling how much help we got.

Working closely and intensely with another person was also humbling but also beautiful and educational. Matt and I live far from each other. In traffic it takes either of us an hour and a half to drive to the other's home to cowork which we tried to do weekly. We both believe that regular in person communication is better than text chat so we endeavored to have any deeper discussions in person. Happily, we were in complete agreement most of the time. In the early days, we even tried to rent coworking space but couldn't find anything suitable in a location convenient for us both. That said, we're both Gen-Xers but are early digital natives so online communication worked for most of what we needed to talk about. Most of our communication was in the form of Github pull requests and the ensuing code review.

Speaking of Github, I'm so impressed by how far it has come since the last time I used it seriously. I could not believe how good their Workflows are for running CI/CD tasks. Of course, you can use it for simple stuff like running your unit tests. You can also spin up containers to run your whole app to do end to end testing. It's incredible to be able to run such complex workflows that take significant amounts of CPU and RAM. I expect this sort of thing at a company above a certain size but it felt like we had big company development infrastructure for $88/year. Really impressive stuff.

More impressive than the automation tools from Github is Copilot. This is their AI coding assistant and it is actually scarily useful. They even support Vim as a first class supported editor which I wasn't expecting. I'm an inveterate Vim user so being able to continue with my comfortable working environment and getting LLM coding assistance was pretty incredible. At first, I felt like Copilot gave me 150% productivity but in the end, I think both Matt and I were able to produce the output of two small teams of four or five fulltime developers, particularly in problem spaces we are not yet experts. For example, I'm competent with SQL but Copilot + Claude gave me the boost to pretend to be an almost expert in the space. We managed our database migrations by writing idempotent SQL scripts. There's no way I would have been able to do that without LLM assistance or taking an interrupt to go read a hefty book on Postgres. The same goes for front end development. I am mostly a backend/low level developer by training and experience but LLMs put us right there with the best front end developers. Blip’s front end was a little rough around the edges but it would have been a lot rougher without LLMs giving us code that mostly adhered to best practices and, just as importantly, would run with only minimal modification. We live in a golden age of software development. Rather than worry about whether LLMs will take our jobs, I am excited for what amazing things little companies like ours will produce in the future. You no longer need to be a well funded startup or a big company to produce significant amounts of high quality software quickly.

I really like the Go programming language. My main expertise is with C++. C++ is like a beautiful kitchen knife. You can do anything with it but you risk getting cut if you get careless. Go is like a food processor. They pared down the language to the essentials. It has a minimalistic grammar and a very opinionated way of handling error conditions and formatting. But like a food processor, it is wicked efficient in its problem space and it saves you from the heartache of getting hurt by supporting you in ways C++ can't. Because they've stripped it down to the smallest it can be, it compiles incredibly quickly. Even at 7300 lines, Blip compiled in seconds with wgo which helped us iterate really quickly. Go also compiles the entire runtime and all of your code into a single statically linked binary which makes deployment extremely simple. Compare that to deploying something written in Python or NodeJS and you'll see the advantage.

I will also use HTMX again. In the first four months of development, we actually tried to build Blip in React/NodeJS/Typescript. What a nightmare that was. Our code ballooned to something past 10,000 lines and it still felt like we were only at the `hello world` stage of development. Matt mentioned that he had heard of HTMX but hadn't used it so I wrote an exploratory spike using HTMX and got us almost to feature parity in two weeks. What a breath of fresh air it is to write simple, declarative code and have it work the first time. After experiencing what the HTMX folks describe as 'hypermedia systems', I'm baffled that people still write web apps in React. You can write anything in HTMX + AlpineJS that you can write in React in less time, with fewer bugs, with a simpler runtime, in any language of your choosing, and, in the case of Go, with vastly fewer dependencies.

If you’ve worked with NodeJS, the above will be funny to you.

Onward!

I'm taking all of the lessons learned from writing Blip and am parlaying them into a new venture. It's probably more rare that a first startup takes off than it is for a founder to have to make a few runs up the mountain before building a product that people love and use. This time around, I expect things to go faster. Matt and I blazed a lot of trail and learned a ton. We are both fluent in several new tools. We went from zero to one with Blip. Going from one to N with the next thing will have a lower activation energy and a higher chance of success. I know Matt will be successful as he focuses his energy on his next adventure. I believe I will be also.