While I was leading multi-million-dollar system implementations by day, I was building my own systems at night. Not professionally. Not for money. Often not even well. But I never stopped building.

This is the story of why that mattered — and why it matters even more now.

________________________________________

The Recruiter Who Built His Way Into Tech

The beginning is almost embarrassingly nerdy: I was bored on a Sunday, reading a database manual.

I was a DJ with two lists — one for albums, one for songs. That manual introduced “relational databases,” connecting two separate lists so they could talk to each other.

That concept rewired my brain.

I built my first application in Paradox to manage my music library.

At my recruiting job, I was drowning in résumés and interview schedules. Everything lived in my head or on scattered papers. So I built the company’s first HRIS system. It tracked every résumé, every interview, every outcome. It made my life dramatically better and gave everyone visibility into the hiring pipeline without waiting for my status reports.

The technology team noticed. I became a junior programmer. That lasted 18 months. Then I got an MBA and became a business consultant. I haven’t coded professionally since.

But I never stopped building.

________________________________________

The Weekend Warrior’s Laboratory

Here’s what my clients never knew: every system I helped them implement, I was trying to understand from the inside out.

I built a complete movie and TV database tracking my 1,500-title collection — cast, crew, features, specs, and twenty years of viewing history. That context helped me grasp participations and residuals when consulting at Disney.

Before Spotify existed, I built a music-streaming system. Hosted MP3 files on my own server and streamed them to my phone. That library now holds 5,000 albums. When I led projects at Warner Music and Universal, I already understood how songs, albums, and artists connect — and why metadata structures matter.

Before Netflix streaming, I used VLC to stream video content from my server. I thought I was just making my movies accessible anywhere — but I was really learning about streaming architecture and content delivery.

I built finance tracking in Excel because it was easier than building a database for that.

Why did this matter for my day job? Because I wasn’t building to become a developer. I was building because I’m genuinely interested in music and movies — and it turned out my work and my interests aligned. The knowledge transfer was organic, not calculated.

________________________________________

The Bridge Between Business and Technical

Building made me bilingual. I understood what developers were facing because I’d faced similar problems myself. I could tell when a challenge was genuinely complex and when we were unintentionally adding friction.

It also let me suggest implementable solutions. When clients described problems, I could sketch technical approaches that weren’t just business requirements — they were architectures developers could actually use.

I spoke both languages fluently because I’d lived in both worlds for decades.

________________________________________

The Wall I Hit

Eventually my self-taught skills hit limits since I had limited free time. Native Android apps? Failed. Alexa skills? Failed. Secure Chrome extensions? Not even worth trying.

The gap between what I wanted to understand and what I could actually build kept widening.

________________________________________

Then Everything Changed

In the last 18 months, I’ve built more applications than in the previous 20 years. Not because I suddenly became a better developer — because AI removed the technical barriers that stopped me before.

• Music Library: natural-language search lets me query conversationally (“Play female New Wave from the ’80s”). The Alexa skill I failed to build for years now works. Android Auto integration brings my 5,000-album library into my car.
• Family Legacy: a chatbot system that stores my father’s history and my grandfather’s writings — decades of material I can now explore conversationally.
• Password Manager: a properly encrypted Chrome extension that integrates with websites.
• Investment Portfolio: my entire portfolio plus fundamentals, sentiment, and insider-trading data — analyzed by AI inside the app.

These aren’t prototypes. They’re tools I use daily.

________________________________________

Building Without Barriers

These are apps I built for myself. But here’s what AI changed fundamentally: I can validate what’s possible through hands-on experience.

When I explore possibilities with AI, I see what’s achievable and where the real constraints are. Sometimes AI thinks it can do something and can’t — that’s valuable information too.

This makes me better at my actual job:

• Validate concepts in hours. Instead of a 40-page requirements doc, I can build a prototype and ask, “Does this solve the problem?”
• Understand what’s genuinely hard. If something takes two hours, it’s simple. If AI and I wrestle for days, it’s complex — and I set expectations accordingly.
• Communicate effectively with developers. I can show a working example and discuss what’s needed for enterprise scale. I understand what they’re facing because I’ve wrestled with similar problems myself.

________________________________________

What This Means for You

The best business technologists don’t just understand business or technology. They understand business through technology. Reading about content-management systems is different from building one. Discussing API integration is different from actually connecting to one. Writing requirements for mobile apps is different from trying to build one and discovering what’s actually hard.

AI just made that kind of hands-on learning accessible to everyone. You don’t need to be a developer. You don’t need formal training.

But you can build functional tools that teach you what your requirements really mean — what’s complex versus straightforward, and why developers sometimes push back.

Building things — even imperfectly — gives you an advantage. Not because you’re smarter, but because you’ve hit the walls others are still theorizing about.

________________________________________

The Real Transformation

The Sunday I learned about relational databases, I realized connecting two lists could change everything. Today the lesson is simpler: you don’t need to be a developer to build anymore. You just need curiosity — and AI. The value isn’t in the code. It’s in the understanding that comes from trying to make something work.

When you build something — even imperfectly — you learn what questions to ask, what really matters, and what’s genuinely hard versus what just sounds complex. That understanding makes you better at your actual job — not as a developer, but as a business professional who truly gets what you’re asking technical teams to create.

________________________________________

What Will You Build?

If you’ve ever thought “I wish this system worked differently” or “Why can’t we just…” — this is your moment. Not to replace developers, but to understand what you’re asking them to build. To validate ideas before committing enterprise resources. To bridge the gap between business vision and technical reality.

The question isn’t “Can I learn to code?” It’s “What do I want to understand deeply enough to build?” 

Start building — even imperfectly. Especially imperfectly.

That’s where the learning happens.

________________________________________

Ross French is a Project/Portfolio Manager and Business Analyst with over 20 years of experience leading complex initiatives across Media & Entertainment, Consumer Products, and other industries. Based in Burbank, CA, he continues to explore how hands-on experimentation helps business professionals better understand the systems they help build.