What I Learned as CTO of a Startup That Didn't Scale

In 2015, I co-founded LoveLiveMusic, a music event aggregation platform. I was CTO, which in a two-person startup means you're also the frontend developer, backend developer, DevOps engineer, database administrator, UX designer, and the person debugging why Elasticsearch won't start at midnight on a Sunday.

We built everything from scratch. A Laravel API, an Elasticsearch-powered search engine, a Mithril.js frontend with an Express.js server, VPS infrastructure managed by hand. The platform aggregated live music events and let users search by genre, location, date, and venue. We reached about 100 active users.

Then the project ended. Not with a dramatic failure — no investor fallout, no technical meltdown. It just didn't grow beyond what two people could sustain. We moved on.

That experience taught me more about engineering than any enterprise project I've worked on since. Not because of the technology — because of what it forced me to confront about how I work.

The Emotional Attachment Problem

When you build everything yourself, you develop an emotional relationship with the code. I'd spent weeks perfecting the Elasticsearch query layer. The aggregation pipeline was elegant. The relevance scoring handled edge cases that probably affected three users. I was proud of it.

The problem was that pride became an obstacle. When usage data showed that most users didn't even use the advanced search — they just browsed by date and location — I resisted simplifying it. I'd built something sophisticated, and I didn't want to throw it away. The code felt like an extension of me.

This is a trap that experienced engineers fall into more often than juniors. Junior developers don't have enough invested to feel precious about their code. Senior engineers who've spent years honing their craft can mistake well-crafted code for valuable code. They're not the same thing. Well-crafted code that nobody uses is waste.

The lesson I took from LoveLiveMusic was blunt: your code is not your identity. If the data says a feature isn't used, delete it. If a simpler approach serves users better, use it — even if it's less technically interesting. Emotional detachment from your own code isn't cold or careless. It's professional.

Learning to Be Data-Driven

Before LoveLiveMusic, I made technical decisions based on intuition and best practices. "This is the right architecture because the patterns say so." "Users will want this because it makes sense." "We need this abstraction because we might need to swap the database later."

Running a startup with 100 users destroyed those assumptions. When you have real users — even a small number — you have real data. And real data is humbling.

We added a recommendation engine because we assumed users wanted personalized event suggestions. The data showed they didn't use it. They wanted a fast, simple list of what's happening this weekend within 10km. We spent three weeks building a feature that mattered less than improving the date picker.

That experience rewired how I think about engineering decisions. Now, every time I'm about to invest significant effort in something, I ask: what does the data say? Not what does my intuition say, not what does the architecture diagram suggest, not what would be the most technically elegant approach. What does the data actually tell us about how people use this?

This mindset — being genuinely data-driven rather than opinion-driven — turns out to be one of the most valued skills in professional engineering. In enterprise projects, the engineers who can point to metrics, usage patterns, and measurable outcomes when proposing solutions consistently make better decisions. And they're much easier to align with product and business teams, because they speak the same language: evidence.

Shipping Fast Over Shipping Perfect

As a solo CTO, I had to manage everything. And "everything" meant constant prioritization. Do I fix the CSS bug on mobile, or do I build the email notification system? Do I refactor the API layer to be cleaner, or do I add the venue detail page that users keep asking for?

Early on, I chose the refactors. I chose the elegant solution. I chose to make the codebase "right" before adding features. The result was a technically clean product that was missing features users actually wanted.

The pivot moment came when I realized that users don't see your code. They see the product. A slightly messy codebase that ships the venue page this week is worth more than a perfectly architected codebase that ships it next month. The venue page drives engagement. The refactor drives my personal satisfaction.

This doesn't mean writing bad code. It means being pragmatic about where to invest quality. The critical path — the parts users interact with, the parts that handle data integrity, the parts that are hard to change later — deserves careful engineering. The rest? Ship it, measure it, improve it if the data says it matters.

I started applying a simple test: if this code is wrong, what's the blast radius? If a CSS misalignment on one browser affects 5% of users and the fix takes two hours, it can wait. If the search index returns incorrect results, that's the core product — fix it now, fix it well.

Applying Startup Lessons at Scale

In 2020, I co-founded Musicbox, a desktop application built with Electron.js and Vue.js 3. This time, I collaborated with engineers from Google, Dropbox, and YouTube. The ambition was bigger, the team was more experienced, and we reached 200 active users in three months.

What changed wasn't the technology — it was how I approached the work. I carried every lesson from LoveLiveMusic into Musicbox. We tracked user behavior from day one. We shipped features weekly, measured adoption, and killed what didn't work without sentimentality. We made architecture decisions based on what we needed now, not what we might need in six months.

The collaboration with experienced engineers from major tech companies was validating. They worked the same way. Data-driven. Pragmatic. Willing to ship something imperfect and iterate. The difference between them and my younger self wasn't talent — it was discipline. The discipline to let go of clever solutions in favor of effective ones.

What I Carry Into Enterprise Work

Every enterprise project I've worked on since has benefited from those startup years. Here's what translates directly:

Speed of decision-making. In a startup, slow decisions kill you. In enterprise, slow decisions just waste money — which is its own kind of killing. I push for decisions to be made with 80% of the information rather than waiting for 100%. You can course-correct. You can't get time back.

Pragmatic architecture. I don't build for hypothetical scale anymore. I build for the scale we have, with clear paths to evolve if needed. The number of times I've seen enterprise teams build for "millions of users" when they have thousands is too high.

Asking "what does the data say?" This is the question that cuts through most technical debates. You'd be surprised how often an architectural disagreement dissolves when someone pulls up actual usage metrics. It's not about who's right — it's about what the users are actually doing.

Willingness to delete. Code that isn't serving users is technical debt, even if it's well-written. The best pull requests remove more than they add. I learned to stop treating deletion as loss and start treating it as clarity.

The Meta-Lesson

LoveLiveMusic didn't scale. But the engineer who built it did.

The startup taught me that being a good engineer isn't about writing elegant code or mastering the latest framework. It's about solving real problems for real people, measuring whether your solution actually works, and having the honesty to change course when it doesn't.

Those lessons — pragmatism, data-driven decisions, emotional detachment, shipping speed — aren't startup-specific. They're engineering maturity. I just happened to learn them by building something that reached 100 users instead of 100 million.

If you're considering a startup, even a small one, I'd encourage it. Not because it might succeed — statistically, it probably won't. But because the constraints of a startup strip away every comfortable illusion about what good engineering actually means. And what you learn in that process will make you better at everything that comes after.