2019 in Review: The Year I Quit, Built, and Started Over

I don’t usually do year-in-review posts. They tend to read like LinkedIn humble-brags. But 2019 genuinely changed the trajectory of what I’m doing, and I want to write it down while the details are still sharp. I left my job at a fintech startup, joined an intense founder program, started a company, and learned that building something from zero is a different skill from scaling something that already exists.

Leaving the fintech startup

I spent a good stretch at a fintech startup. Good team. Interesting problems. We built systems that handled enormous volumes of financial data with tight latency requirements. I learned a lot about what it means to run infrastructure that can’t go down. When money is involved, a 99.95% uptime target stops being an academic exercise and starts being your weekend.

But by early 2019, I knew I wanted to build something of my own. Not because the fintech startup was the wrong place. It was the right place for the stage I was in. The itch was something else: I wanted to own the problem, not just the solution.

So I left.

Joining a founder program

I joined a founder program’s cohort this year. The expectation is that you find a co-founder and build a company. In weeks.

It’s as intense as it sounds.

The previous year I’d gone through a startup accelerator , which was a great experience but structured differently. The accelerator gives you resources and mentorship around an existing idea. The program strips you back to zero. You walk in with credentials and walk out with either a company or a very clear understanding of why you didn’t start one.

What the program teaches you fast: your technical skills are table stakes. The hard part is finding someone whose strengths complement yours, whose risk tolerance matches, and who you can argue with productively at 11pm on a Tuesday. The co-founder search is brutal. You’re essentially speed-dating for the most important professional relationship of your life.

Founding a company

Out of the program, I founded a cloud infrastructure company on my own. The thesis was straightforward: cloud infrastructure is absurdly complex, and most teams are paying for complexity they don’t need. I wanted to build tooling that made cloud operations simpler without dumbing them down.

This wasn’t an abstract idea for me. I’d spent years in Go, contributing to open-source projects and building cloud-native systems. I’d watched teams at the startups where I’d worked struggle with the same problems. Kubernetes was maturing, sure. But “maturing” in practice meant the operational tax was becoming clearer, not smaller. Managed control planes helped, but day-2 operations (upgrades, policy, incident response) were still eating engineering time that should have gone to product work.

The company was born from that frustration. I wasn’t trying to replace Kubernetes or any specific tool. I was trying to reduce the cognitive load of operating in the cloud.

Starting a company from scratch is humbling, even the second time. At the fintech startup, I inherited systems, processes, a team. At the new company, I had a laptop and a pitch deck that needed rewriting every week. The feedback loops are different. The loneliness is real. And the decisions hit different when it’s your name on the incorporation documents.

What I Learned This Year

Building from zero versus building on top of something are fundamentally different skills. I had founded a startup before, but the years since had gone into building technology inside other companies. Building the company itself is not the same thing, and I had to relearn it.

The industry’s complexity problem is real and getting worse. I watched the cloud-native ecosystem grow more powerful and more impenetrable simultaneously. TypeScript was becoming the default for frontend at scale. Go was dominating infrastructure tooling. Rust was expanding beyond systems niches. Good trends, all of them. But the surface area of “things you need to know to ship a product” kept expanding.

Simplicity is a harder sell than it should be. The “monolith first” argument went mainstream in 2019. People started publicly defending boring technology choices. But in practice, teams still reached for distributed architectures before they needed them. Resume-driven development is a powerful force.

The best founders I met in the program weren’t the smartest people in the room. They were the most honest about what they didn’t know. That’s a different skill than intelligence, and it’s harder to fake.

What I Noticed in the Industry

A few things I noticed from the outside looking in, which shaped how I thought about the company:

Service meshes gained real production usage but proved heavy. The value was clear for large distributed systems: mutual TLS, canary deployments, consistent observability. For everyone else, it was another layer to debug.

Edge computing found its feet. CDN providers turned their points of presence into compute platforms, and real workloads started running there: personalization, auth at the perimeter, feature flagging close to the user. For most teams it’s still premature optimization , but the stateless CDN cases are real.

GitOps moved from blog posts to actual deployment models. Git as the single source of truth for environments. Pull-based deployments. Declarative infrastructure. This was the kind of operational maturity the industry needed.

Security conversations got more concrete. Zero trust shifted from strategy decks to implementation work. High-profile cloud incidents, above all the Capital One breach disclosed in July, drove home that configuration risk is as real as application risk. IAM policies are code, and they deserve the same rigor.

Remote work kept becoming more normal, at least for engineering teams.

What I’m Carrying Into 2020

I’m ending 2019 as a founder again. A year ago I was at a fintech company. Now I’m trying to build something from nothing, with the conviction that cloud infrastructure can be simpler and the awareness that conviction alone doesn’t ship products.

The things that stayed hard: operating Kubernetes well, managing dependency sprawl, treating security as engineering rather than compliance theater, and tying cloud costs back to architecture decisions. These are the problems I’m now trying to solve professionally, which means I get to be frustrated by them in a whole new way.

2019 wasn’t a comfortable year. It was a good one. There’s a difference.