I was lucky to get a job with a company that actually helps its community. We give a percentage of our revenue to local charities, nonprofits, and causes around us. The software I build gets to support that. It puts new clothes on kids. It helps people with housing. So the tech needs to work — regardless of how flashy or new it is.
I spent the first two years of my programming career on a large team as a junior individual contributor. Then I came here. I spent the next five as the only developer at this same company — small and growing back then. I just hired my first junior engineer, and my time as a solo dev is over for now. Here is what I learned in those five years.
Coming off being a small contributor on a large team into a place where everyone looked to me to solve our software needs was intensely overwhelming. Still arguably new to the field, I was handed a blank slate to play in — a ton of fun and a ton of pressure. When I walked in, the company was three years old, running off an old Wix site, dependent on a stack of third-party apps to operate. They did that out of survival, and it was brilliantly done. But I was given the task of helping future-proof the operation. That was a task I wouldn't grow into for a few more years.
To be honest, diving into solo dev for a new and growing company was good for me. I learned fast because I had to. The company had to move fast to keep growing, which meant I had to move fast and break a lot of the rules I'd learned at the previous company. I had to learn how to deploy, how to test, how to design, how to maintain. I had to learn what users actually wanted and expected, and learn to be okay when what they wanted wasn't what I wanted. I had to learn how to take a stakeholder's "wouldn't it be cool if the website did this" and turn it into lines of code. I had to ditch my love of brand-new tech and build on stable tech. I couldn't just write each new thing in the newest language or framework like I did in bootcamp or when learning. I had to research what was most used, stable, and maintained. I read blogs, listened to podcasts, did whatever I could to stay ahead of what was going on — searching for anything that could put our company ahead.
It was stressful, but I learned a lot. I'm a jack of all trades, master of none. And that's because it's what the company needed. I wasn't making trendy apps. I was making apps that worked so we could make money. Tech that works matters. Using the newest JavaScript framework didn't matter. What mattered was that the ordering form loaded every time a customer opened it.
Give yourself permission to change your mind
Accept that you were wrong, adjust course, and don't dwell on the mistake. Focus on the new path.
We had 23 pages, identical in structure, each showing different content. I thought I had to make them each a separate page instead of using a dynamic slug system, because I thought it was better for SEO. After the hundredth time I had to change 23 files to update one little piece, I finally realized Google doesn't care how the data gets there — only that when they hit a route, the right thing comes back. I was wrong. The mistake wasted time and money.
I can dwell on that, or I can adjust course. I learned to have a short-term memory with failure, and a long-term memory with lessons learned.
Learn the business
That was the easy lesson. The next one took years.
If you understand the business you work for — the industry, how the company operates — you will make better software. You become more than a programmer. You become a leader.
My company designs, manufactures, and sells custom sports uniforms. For the first couple of years I couldn't tell you anything about how the company ran. I didn't think I needed to.
Then I started sitting down with every department — marketing, sales, operations — and just asking "hey, what do you do in a normal day?" Two complaints came up everywhere. We have all these cool tools, but I can never remember where to find them. And company communication needs to improve. Decisions need to float out better. These were growing pains. Good problems to have at a company that was scaling.
I built one platform to solve both. A custom employee portal that centralized company announcements and what I now call our "company toolkit" — a single place where any tool, dashboard, or feature lives. Something I wouldn't have thought to build sitting at my desk. It came out of small conversations I had in an effort to learn more about the different roles at the company.
Learn the business.
Lose the ego
I spent time building tools I thought our users would love. They never used them. I assumed it was because they didn't understand how, or because they were stuck in their ways. Then I learned a valuable lesson: if the users don't want to use the tool, the tool sucks.
That's a blanket statement, dramatic on purpose, and not always true. But if software is good and solves a real problem, people will use it. You won't have to force them. They'll use it because it actually makes their job or their life easier or better.
I had to lose my ego. If people don't use what you made — or don't like it — you have a choice. You can assume they're wrong and move on to the next thing. Or you can ask them what would make it better. If you have access to the user, ask. They'll tell you. As a solo dev, you have a real opportunity to just build what people want to use.
What it cost
I've made solo work sound mostly good. It wasn't all good.
It was lonely. No one at the company understood what I was doing. It was sometimes hard to feel valuable. I had no second set of eyes. No one to challenge me. I had to learn to challenge myself — and that's a hard thing to do.
When things went wrong, it was on me. When things go wrong now, it's still on me. I answer for it. I have to fix it. Which means I'm on call 24/7.
What's next
I recently hired our second developer. I'm no longer a solo dev. The lessons from that time are already shaping how I show up as a leader. But they don't transfer cleanly. Permission to change your mind, learn the business, lose the ego — all of them apply differently when there's a team in the room.
Five years alone taught me how to be reliable. Now I have to learn how to be replaceable.