5 Mistakes Solo Developers Keep Making — Things I Only Learned After Living Through Them
Constraints come before features. If the direction is wrong, the more you build, the further you stray.
Looking back, it’s a little embarrassing — I made the same mistakes project after project. That moment where you finish writing the code and only then realize “oh, this was never going to work” — if you’re a solo developer, you’ve probably been there. No team meetings, no reviewers, just you sprinting alone until you hit a wall.
Here are five painful lessons I picked up across multiple projects. Each one looks like an isolated incident, but once you see the meta-pattern at the end, it becomes clear they were all the same mistake in disguise.
Mistake 1 — Building a stock app only to get blocked by regulations after it was done
I built a stock portfolio app (Jaram). I’d implemented quite a bit — backend API integration, real-time price feeds, buy/sell simulation. Then I was reading through the KIS (Korea Investment & Securities) terms of service carefully and one line stopped me cold:
“Fintech companies may not place orders or make inquiries on behalf of another person’s account.”
Once you factor in the quasi-investment advisory regulations, the entire service structure I had in mind was legally in a gray area. If I had seen that one line before designing anything, the whole direction would have been different. Stopping after a lot of code has already piled up is so much harder than starting over from a blank slate.
What I learned: Regulations and legal constraints need to be checked before you build features. Features can always be added later, but your business structure isn’t something you can easily change.
Mistake 2 — Building e-commerce features for what turned out to be a gallery
On the Hansaiam Art Museum project, I jumped straight into “what features do we need” from the very start. Artwork sales, payment integration, shipping management… I had a pretty detailed picture in my head as a developer.
But when I actually sat down and talked with the artist, what they wanted was something different.
“Showing the work matters more than selling it.”
It was a gallery. Not a place to sell — a place to show. The e-commerce features I’d built were pointed in the wrong direction from day one. We ended up cutting the class collaboration cards and narrowing the contact section down to “artwork inquiries only.” If I’d asked “what is this service, really?” first, none of that detour would have happened.
What I learned: “Identity” comes before “features.” Until you’ve confirmed what the user (or client) actually wants, any feature you build might be headed the wrong direction.
Mistake 3 — The misconception that splitting businesses saves on taxes
I thought separating my development income (Yulsoft, contract work) from my service income (Slowloop Lab) would reduce my tax bill. Two businesses, two income streams, right? So I actually went and set up separate business registrations.
Then I actually understood how the comprehensive income tax system works — and found out that if you have multiple sole proprietorships, the income gets combined at year end anyway. I took action before I understood the structure.
What I learned: Understanding the structure comes before taking action. Especially in areas like tax and law, “just try it and fix it later” doesn’t really work. The cost of undoing something is far greater than the cost of doing it in the first place.
Mistake 4 — Filling CLAUDE.md with 20 rules and watching compliance drop
While using Claude Code, I kept adding rules to the project instruction file (CLAUDE.md). Coding style, commit format, file structure, documentation conventions… they were all good rules. But once the count crossed 20, something strange started happening: the rules were there, and they weren’t being followed.
Turns out context dilution is a real thing. When there are too many rules, the LLM loads all of them — including irrelevant ones — every session, and the weight of the rules that actually matter gets diluted. If all 20 rules are equally important, it ends up the same as nothing being important.
I went into more detail on this in claude-code-4레버-방법론, but the core fix is splitting rules by global/project/issue scope, and making sure issue-specific sections get removed once they’re done.
What I learned: Diluting identity — whether through features or rules — leads to the same place. Cutting things down is part of the design.
Mistake 5 — Missing important work inside a 791KB session
One session was 791KB. That’s what happens when you handle multiple tasks in a single session. When I went to process it later, the session title (the first message) said “myWiki design,” so I summarized the myWiki design work and called it done.
But there was also a completed product-pipeline skill creation task buried inside that same session. The long, text-only stretches near the end of a session — the ones with no code, just back-and-forth — tend to have the highest signal density. That’s exactly where I missed it.
Agent context gaps and second brain integration covers how I addressed this structurally.
What I learned: The title doesn’t guarantee the contents. For large sessions, you have to actually scan for completed work markers yourself.
The Meta-Pattern — What All Five Mistakes Have in Common
When I laid them all out, they were all the same mistake.
- Constraints first — I should have checked regulations, legal limits, and user intent before building features
- Workaround ≠ getting through — Working around a problem means you’ll hit it harder later
- No dilution — Anything that blurs identity — features or rules alike — ends up getting cut eventually
- Understand the structure first — “Why are we doing this” needs to come before the doing
- Check scope when processing — Look at the actual content, not just the title or surface appearance
As a solo developer, you have to make all of these calls alone. That’s why the same mistakes happen more easily. If there had been a team, someone would have asked “is that even legal?”
Before you start your next project, check the regulations, legal constraints, and the core user identity first. Features can always be added later — but if the direction is wrong, the more you build, the further you end up from where you want to be.
Method: 4 Levers for Getting the Most out of Claude Code · Deep dive: product-pipeline skill · Deep dive: Agent context gaps and second brain integration · See also: Stock app AI agent development know-how · See also: Home server stock app deployment war stories