What Two Months in a Near-Shipping Startup Taught Me
Reflections on working as the sole frontend engineer in a six-person startup team, learning maintainable code, Git workflows, and pragmatic tradeoffs.
I don't know how to start this one without sounding dramatic so I'll just say it: those two months changed how I think about writing code.
How It Happened
Someone spotted my work in web dev and asked if I wanted in. The team was six people, seniors from my college, and they were building something real. Like actually building it, not a project for a class, not a prototype that lives on someone's local machine. Something that was supposed to ship.
I said yes before I fully processed what I was agreeing to.
I was the only frontend engineer. I was also, without question, the least experienced person on the team. Walking into that dynamic at the start of your second semester is a specific kind of uncomfortable. Not bad uncomfortable, just the kind where you're constantly aware that the gap between you and everyone else is visible.
The Technical Stuff
I learned to write maintainable code in an environment where maintainable actually mattered. When you're doing solo projects you can get away with a lot. You know where everything is, you remember why you made that weird decision, nobody else has to touch it. In a team, that all falls apart immediately.
Git in a team environment is just different. Merge conflicts are real. Branch strategy matters. Writing commit messages that mean something matters. I had to get comfortable with all of this fast because there wasn't a softer introduction option.
I got real practice with the things you read about in frontend guides but don't actually implement until something breaks: lazy-loading because a component was too heavy, routing because multiple people were working on different pages simultaneously, rendering decisions that affected actual performance.
The biggest thing technically was learning to make pragmatic tradeoffs. The ideal solution and the solution that ships are often not the same. I had opinions about how things should be done. Sometimes those opinions were right. Sometimes shipping on time was more important than being right. Knowing the difference is a skill I didn't have before this.
Debugging under time pressure is also its own thing. You don't get to methodically eliminate possibilities when there's a deadline. You get faster at forming hypotheses and testing them. You get comfortable saying "this is probably the issue" instead of "this is definitely the issue."
The Other Stuff
Watching experienced people approach problems is underrated as a learning mechanism. It's not just what decisions they make, it's how quickly they make them, what they even consider worth deciding about, and what they just do without thinking.
I got comfortable saying "I don't know this, but I'll figure it out." That sounds small but it isn't. There's a version of imposter syndrome where you try to never admit you don't know something. That version is exhausting and makes you slower. Getting over it and just asking was one of the more useful things that happened.
Managing time across multiple priorities is something you can understand conceptually but only really learn by actually failing at it once or twice. I failed at it once or twice.
The startup-specific things I picked up are harder to name but they're real. What effective communication in a small team looks like versus what ineffective communication looks like. How priorities actually get set versus how people talk about priorities being set. What it feels like when momentum is real versus when it's performative.
When It Ended
The initiative wound down after about two months. Priorities shifted for the founders, which is a thing that happens. The MVP didn't ship.
I won't pretend that didn't sting a little. You build something with people, you get close to done, and then it stops. That's a different feeling from a project you abandon yourself.
But I keep coming back to what actually happened in those two months. I wrote code that other people read and worked with. I shipped features. I had to explain my decisions. I had to defend them sometimes and back down from them other times. I worked with people who were better than me at almost everything and tried to close that gap as fast as I could.
No solo project replicates that. You can build impressive things alone. You can't simulate what it's like to be the least experienced person in a room full of people who are doing this seriously.
I'd do it again. The version of me who comes out of two months like that is worth it, even when it doesn't ship.