Woah. Was I Actually Vibe Coding Way Back in 2014? Reflections on DIY tech projects

In 2014, I had one HTML class under my belt and a problem I wanted to solve. Creative freelancers in Charleston, SC couldn't find local work. Businesses couldn't find local creatives. Everyone seemed stuck on Craigslist or competing against globally sourced freelance marketplace platforms that undercut the local rates for folks trying to make a living.

So I i decided to start something myself. At that time, the project became Creators' Clubhouse: a curated digital "cork board" for Charleston's creative community to find work. The idea was simple: navigating Craigslist for creative work felt like a treasure hunt without a map, and the "professional" job boards pooled freelancers from around the world, driving prices to the floor and making local talent invisible. The Creators’ Clubhouse cork board let local businesses post creative opportunities and local creatives find them, all within the local community and my hometown of Charleson, SC. Simple concept. But when I started to build it, the execution was anything but.

The First Real Decision

At that time I knew enough HTML and CSS from one college course and how to open Chrome's DevTools menu. That was it. No backend experience, no database knowledge, no understanding of how web applications actually work. But the product i had in mind needed user accounts, listings, payments, messaging, and search. Building all of that from scratch with zero experience would have taken years.

So I made the first real product decision of my career: I forked Sharetribe, an open-source marketplace platform built on Ruby on Rails that I found on GitHub. It came with the infrastructure I needed. 62 data models, payment processing through Braintree, full-text search, user messaging, listing management, and an admin panel. 2,300+ files. 551 database migrations. A real production codebase. But here's the thing. I didn't know Ruby. I didn't know Rails. I didn't know what a database migration was. But I had a working marketplace platform I could customize instead of an empty code editor and a dream.

Mind you, this was 2014. VS code had just basically launched. Github wasn't yet owned by Microsoft. Everyone was talking about cocopods and hadoop. Times were different.

Learning by Modifying a Real Codebase

There's a version of learning to code where you follow tutorials and build todo apps and just progressively get better at coding. Maybe that's the sane path. Then there's the version where you just fork a random production Rails application with 62 models and just sort of figure out how to make it do what you need. So here's the question: Was I vibe coding way back then in 2014??? Bolding and naviely just going for it!

I learned what an ORM does by reading Sharetribe's model files and figuring out how listings related to users, categories, and transactions. I learned how controllers work by tracing what happens when someone clicks "post a listing." I learned how deployment pipelines work by pushing to Heroku and watching things break over and over and over. I learned about npm modules and packages and weird ruby things.

At that time customizing the self-hosted version of Sharetribe for Charleston's creative community meant understanding its entire system well enough to change it without breaking it. I had to figure out which templates controlled the homepage. Which config files set up the community. How the payment flow connected buyers to sellers. Every change I made required understanding three layers of code I didn't write and seeing how it cascaded through the system.

The Build vs. Buy Instinct

Naturally, learning by doing turned out to be a better education than paying someone to build it for me would have been. Forking this random Sharetribe repo was itself a build-vs-buy decision, even if I didn't have the vocabulary for it yet. Authentication, payments, search, messaging. None of those were what made Creators' Clubhouse valuable. The local curation and community focus were. I didn't need to build a payment system from scratch. I needed to build the thing that made Charleston creatives show up and find what they needed to find and the businesses that posted a listing finding good talent.

That instinct, knowing which parts of a system are part of your differentiation and which parts are commodity infrastructure, turned out to be more valuable than any single technical skill I picked up. It's the same instinct that guided every tool choice I made a decade later vibecoding BizSpotNY: using Supabase instead of building auth from scratch, use Stripe instead of rolling my own payments, use Vercel instead of managing servers. (Turns out this is actually vibe coding in 2026 terms).

The tools change. The decision framework doesn't.

What Happened to Creators' Clubhouse?

Creators' Clubhouse ran for a while. It had users, real listings, and a community that showed up. But it didn't sustain. The classic small-market marketplace problem: not enough supply and demand on either side to keep the flywheel spinning without constant effort. I was the sales team, the engineering team, the support team, and the community manager. That doesn't scale.

It shut down. And honestly, the failure taught me more than the building did. I learned that a working product isn't the same as a viable business. I learned that distribution can be harder than engineering. I learned that the go-to-market matters as much as the architecture. Architecure is strategy in some respects.

Gratitude for Trusting the Process & Where It Led Me

Creators' Clubhouse didn't become a long-term company. But it became a foundation. Taking a complex codebase and making it do something. Understanding how systems connect. Debugging problems I didn't create or untangling the ones I did. Talking to users about what they actually need. That combination of technical depth and community instinct is what led me to be involved in the field of developer relations.

Over the years that followed, through a variety of roles, I've now worked across AWS, Google, Adobe, Major League Hacking and other platforms where the job was helping developers build things. The reason I could do that job was because I had been one of those developers, figuring it out with no safety net, shipping something real with whatever tools I could learn fast enough.

The technical instincts carried forward in unexpected ways. Understanding data models from Sharetribe's 62 tables became relevant when AI/ML tools started requiring the same thinking about how data is structured, related, and queried. Understanding deployment pipelines became relevant when teams needed to ship ML models to production. The domain changed. The underlying skills didn't.

What a Over a Decade of "Vibe-Building" Taught Me

So yeah. suffice to say I feel like maybe I've been vibe coding since before the term existed. In 2014, it was me just forking a Rails app I couldn't even read and pushing it to Heroku until it worked. In 2026, it's prompting Claude Code and deploying to Vercel. The tools are completely different. The instinct is the same: get something live and figure it out from there.

Twelve years of that cycle, across every stack and framework shift, has taught me what sticks and what doesn't. The specific languages and platforms come and go. What compounds is the problem-solving. How to read a codebase you didn't write. How to debug something when you don't fully understand the system yet. How to decide what to build and what to borrow. When to ship and when to keep iterating.

I didn't wait until I understood Rails to fork Sharetribe. I didn't wait until I understood Astro to start BizSpotNY. I shipped, it broke, I learned. That cycle is the education. Everything else is just tooling.