Founding a Startup Isn’t Easy, but the Experience Is Priceless

Starting with very little money

Starting a company sounds exciting right up until you price the first server. We raised our initial money from friends and family, which is a particular kind of pressure. You’re not spending a fund’s money. You’re spending money from people who will see you at dinner. Every dollar had a face attached.

So we bootstrapped. There was no engineering budget to speak of, no department for each responsibility, and nobody to escalate to. If something needed doing, someone had to work out how to do it, and most days that someone was me. I’ve told the chronological version of the story elsewhere. This is the part about what it felt like, and what it left behind.

Being almost every department in the company

My job title said CTO. My actual job, on any given day, was whichever department the company was missing.

Some mornings I was the field technician, in a cold data center racking servers, routers and switches, running cable and working out why a port that was fine yesterday wasn’t fine today. Then the network engineer, configuring routing, talking to carriers, chasing a connectivity problem that only showed up under load. Then the Linux sysadmin, patching the servers I had just racked and keeping them running on fewer of them than anyone would recommend.

By the afternoon I was the developer, building the platform on open-source VoIP and writing the billing system, the backend, the APIs and the front end on top. I was also the architect, deciding what had to scale now and what could wait, and living with the shortcuts I’d chosen last month. The next day I’d be the UX designer, trying to understand why a customer couldn’t find the button I was sure was obvious, and then the product manager, choosing between the feature a customer wanted and the one that would keep the infrastructure standing.

In between there was the business: vendors, service providers, customer support, and the spreadsheet where I learned what each server cost against what customers paid. When a customer couldn’t make a call, the person who answered, the person who checked the router, the person who read the logs and the person who had written the code in the logs were all me. There’s a certain clarity to that. Nobody else to blame, and nobody else to ask.

Learning everything as fast as possible

You cannot wait to become an expert when the thing is down. Some problems I learned about in the morning and had in production by the afternoon, because the alternative was customers who couldn’t use the service. That never stops being uncomfortable. You learn to research quickly, decide with incomplete information, watch what happens, and fix what you got wrong.

The by-product was a versatility no single role would have given me. I learned to troubleshoot from a cable to a packet to a database row to a line of code, because the problem rarely announced which layer it lived in. I learned how a technical decision showed up on an invoice, and how the parts of a business depend on each other in ways no org chart draws. Most of how I think about engineering leadership started there.

The first revenue is a different kind of excitement

Building a product is one challenge. Getting someone to pay for it is another one entirely. You can believe for months that you’ve built something valuable. The first time a customer hands over money for it, the belief stops being yours alone. No launch since has felt quite like that.

It also doesn’t end anything. After the first paying customer you need the second, then the hundredth. You need to improve the product, control expenses, keep the infrastructure up, support the people paying you, and get all of it to where the business sustains itself. Revenue changed how I thought about engineering. A technical decision stopped being about elegance or performance alone. It affected operating cost, whether customers stayed, and whether the company could keep going. Our users were in South America, Asia and Africa, many in communities the big carriers didn’t serve well, and a dropped call wasn’t an abstraction to them.

Profitable doesn’t mean finished

Profitability felt like a finish line and turned out to be a checkpoint. More customers brought more expectations. More traffic brought more infrastructure, and eventually a move out of the data center I had cabled by hand and into the cloud, so users could be served from a region near them at lower cost. Growth brought organizational problems rather than technical ones, and what had worked when the company was small stopped working as it grew.

The founder’s job changes there, whether or not the founder notices. It stops being doing everything yourself and becomes building the systems, processes and team that run without you in the room. That was harder for me than racking servers ever was, and it’s what I think about most when I mentor engineers who are becoming leads.

Not every startup makes its founders wealthy

Startup stories tend to be about the funding round, the acquisition and the founder who never has to work again. That isn’t most founders. Some companies succeed financially. Some survive for years without making their founders rich. Some fail after enormous effort by good people. Building a company is not a reliable path to wealth, and anyone who tells you otherwise is selling a course.

The experience itself was worth more than I understood at the time. A company teaches you how technology, customers, money, operations and people connect, in a way a single job inside one department rarely can. It teaches you to carry uncertainty, work with less than you need, and take responsibility for the whole operation rather than your corner of it. It changed how I think, and that didn’t leave when I did.

What it changed in me as an engineering leader

Because I’ve been the network engineer, the sysadmin, the developer, the designer, the product manager and the person reading the invoices, I understand what each of those teams means when they tell me something is hard. I’ve also learned, usually by paying for it, that engineering decisions have financial consequences, that technology exists to solve a customer’s problem rather than to be admired, and that the most sophisticated solution is often wrong for the company you actually have. Limited resources force you to prioritize, and that discipline is worth keeping when the resources arrive. The architecture lessons that survived and what the VoIP platform taught me about distributed systems have their own posts.

The one I hold onto most: a good leader doesn’t need to know everything, but they need to understand how the pieces fit together. A sustainable business matters more than impressive technology. I learned both by being the entire org chart for a while.

Short answers