What Happened When I Realised I’m Not the Only Developer on Earth - Pt 4

By 2012, after the lingerie business ended, I was living off savings that were rapidly running out. The reward charts business had been pulled from the platform years earlier. I'd been using fan art in my designs, thinking it was acceptable like it was on DeviantArt. It wasn't. Years of work, gone overnight because I didn't understand the rules.

I had two kids depending on me, and seven years of self-taught coding experience that apparently meant nothing to employers. Turns out "I automated my lingerie business" doesn't look great on a CV. I'd spent years building businesses, but I didn't have the one thing the job market wanted. Qualifications.

The decision

But here's what I knew that they didn't. Automation was my superpower. It was the skill that had freed me from repetitive work, the tool that gave me back my time. That's what I wanted to formalise. Not just to get hired, but to prove what I already knew I could do.

In 2012, when my youngest son started school, I had to make a choice. I could try to start another business from scratch with no money, or I could finally get the formal training that might open doors. I chose the diploma.

That decision led to my first real development role. For years, I'd been building solo while raising my kids. Now I was joining a team for the first time. Working with other engineers taught me things I hadn't encountered building alone. Adapting to systems I didn't build. Learning when to push for better architecture and when to ship what works. Balancing my instinct to optimise everything with the reality that sometimes good enough ships faster than perfect. Those constraints made me a better engineer.

What I learned

Looking back, each venture taught me something I didn't expect. But the real patterns only emerged later.

• Big dreams are useless without proof
• The internet could generate income if used properly
• Solving real problems creates value
• Skills are currency
• Growth without stability collapses
• Smaller, more accessible versions often outperform big ones
• Code could multiply output, reclaim time, and create a freedom that physical businesses never could
• The best solutions come from combining different perspectives, not just my own instincts

The pattern I missed

But what I couldn't see back then was how each venture taught me something valuable. My most successful businesses, the reward charts and the lingerie, both started the same way. I built them to solve my own problems first. The reward chart was for my son's routine. The lingerie was because I actually wanted it for myself and couldn't find what I wanted. I wasn't chasing markets or trends. I was solving real problems I actually had.

Then something else happened. In both cases, other people saw what I'd built and asked if I could make one for them too. I didn't have to convince anyone they needed it. The demand found me because the solution was genuine. And in both cases, I discovered underserved niches within those markets. Parents wanted personalised charts with their child's name. Plus-size women desperately wanted beautiful lingerie in 5XL that nobody else offered.

The businesses that worked weren't the ones where I walked into an office with a stapled document and a dream. They were the ones where I built something real, tested it on myself first, listened when people asked for more, and responded to needs that everyone else ignored.

How this shapes my engineering today

All of this shaped my belief, "If you put your mind to it, you can accomplish anything". It's my favourite quote from Back to the Future, and it's proven true over and over. Not because everything I tried worked, but because everything that didn't work taught me something that made the next attempt better.

Of course, I laugh when I think about that Fluffy Duck moment now. The fluffy duck didn't vanish though.

That lesson still drives every system I engineer today. Every tool, every platform, every line of code. I'm still solving my own problems, still building leverage, still looking for ways to give people back their time. The businesses changed. The approach never did.

These early failures taught me to think in systems, to build proof before asking for belief, and to find leverage wherever possible. That mindset shows up in every technical decision I make now, from component architecture to automation workflows to how I approach problem-solving with teams.

Lesson: The best engineering mindset comes from building things that fail, learning why they failed, and applying those lessons to what you build next. Experience compounds.