Self-Taught to Full-Stack: What Building in Public Taught Me
Self-Taught to Full-Stack: What 2 Years of Building Taught Me
Not long ago I was a finance manager at a Toyota dealership. I'd been tinkering with code since the early 2000s, but it was always a side thing. Something I did for fun. Not something I thought I could do professionally.
Then I decided to build NeedThisDone.com from scratch, and everything changed. You can see what I've built for the full picture.
The Background Nobody Expects
My resume doesn't look like a typical developer's. Five years as an Army combat medic. Seven years selling cars and structuring finance deals at Toyota. A few years at Full Sail University helping military students navigate the GI Bill.
When I tell people in tech my background, I get one of two reactions: either "that's so cool" or a look that says "why would anyone hire you?"
Both reactions miss the point. The military taught me to stay calm under pressure, follow protocols, and take responsibility. Toyota taught me to explain complicated things to non-technical people and follow through on commitments. Those skills turned out to be exactly what software development needs.
What Actually Worked
Building Something Real
Tutorials are fine for learning syntax. But I didn't really start learning until I decided to build a production application.
NeedThisDone.com wasn't a toy project. It had real requirements: user authentication, payment processing, an admin dashboard, email notifications, a chatbot. Every feature forced me to learn something I didn't know yet.
The key insight: I learned React by building a checkout flow, not by building a counter app. I learned database design by modeling real customer data, not by following a schema tutorial.
Writing Tests From Day One
This one surprised me. I expected testing to slow me down. Instead, it did the opposite.
Writing tests first forced me to think about what my code should actually do before writing it. It caught bugs before they reached production. And it gave me the confidence to refactor code when I realized my first approach was wrong.
I'm not going to pretend I loved writing tests from the start. But after the third time a test caught a bug that would have broken production, I was convinced.
Reading Production Code
Tutorials show you the happy path. Production code shows you what happens when things go wrong.
I learned more about error handling from reading how Supabase and Next.js handle edge cases than from any tutorial. I learned about rate limiting by looking at how real APIs protect themselves.
Getting One Real Client
The Acadio engagement changed everything. Going from "I built a project" to "a company hired me to solve their problems" is a completely different signal.
I started as a contractor doing API work. Then I built a PDF-to-HTML conversion pipeline. Then they started coming to me with questions that weren't in my job description. Within a few months I went from contractor to Technical Operations Specialist.
That progression proved something tutorials and side projects never could: I can solve real business problems under real constraints.
What I Wish I'd Done Differently
Started with TypeScript
I learned JavaScript first and added TypeScript later. This was backwards. TypeScript would have caught half the bugs I spent hours debugging. If you're starting out, just start with TypeScript.
Focused on Fewer Technologies
Early on, I was bouncing between React, Vue, Python, Go, and whatever else looked interesting. I would have progressed faster if I'd picked one stack (Next.js + TypeScript + PostgreSQL) and gone deep instead of wide.
Built in Public Earlier
I spent time building in private because I was embarrassed about my code. When I finally started sharing what I was building, I got feedback that made my work better and connections that led to opportunities.
Nobody cares if your code is perfect. They care if you're building real things and learning visibly.
If you're a veteran considering tech: your experience is an asset. Connect with me — I'm always happy to talk.
The Hard Parts Nobody Talks About
Zero Traction for Months
I launched NeedThisDone.com and... nothing happened. No customers. No traffic. No inquiries.
This is normal, and nobody tells you that. Building the product is maybe 30% of the work. The other 70% is getting people to find it and trust you enough to pay for it.
Imposter Syndrome is Real
Every time I talked to someone with a CS degree, I felt like a fraud. Every time I looked at a senior developer's code, I thought "I'll never be that good."
Two things helped: First, I stopped comparing my beginning to someone else's middle. Second, I started measuring progress against my past self instead of against other people.
The Income Gap
Going from a stable finance manager salary to freelance developer income was terrifying. I'm not going to romanticize the lean months.
My advice: don't quit your job until you have either savings to cover 6 months of expenses or a client willing to pay you. Ideally both.
Where I Am Now
A few months and 1,300+ commits later, I have a production platform that handles real payments, a client track record, and a skill set that keeps growing.
I'm not where I want to be yet. But I'm so far from where I started that the gap is hard to believe.
The self-taught path isn't easy. It's lonely, it's slow, and there's no curriculum telling you what to learn next. But if you have the discipline to build real things and the patience to keep going when nobody's watching, it works.
It just takes longer than you think it should.
If you're on a similar path and want to talk, reach out — I'm happy to share what I've learned.
Need Help Getting Things Done?
Whether it's a project you've been putting off or ongoing support you need, we're here to help.