Building solutions: GTM engineering
Background
When Double M Studios first launched in Olney, MD, we were a lean operation with one recording room. The business operated as a typical service-based business: clients would reserve a slot for a pre-defined price. We’d run promotions to boost sales: discounts for larger reservation slots, buy-one-get-one promos, etc.
Making more money meant trading more services and time for money subject to what the market was willing to pay; classic supply/demand economics.
This works for many businesses: Superstores, airlines, retail stores. Scaling up meant a significant increase to OpEx. But my eyes set on vertical growth rather than horizontal.
That mustard seed grew into a change in strategy with a long road of unlearning, re-educating, and deconstructing our systems and processes.
I spent 6 months interviewing our customers in groups by amount spent and frequency of visits. I wanted to test my hypothesis:
If we were to offer a recurring membership with tiered benefits, then who’d be interested, what are they willing to pay, and - if offered early access, when would they want to enroll?
I distilled my notes, validated the idea, and built the new offering. With promise notes from our customers, I gave our team the hope of what growth could look like.
We went all in and began executing on the strategy. By 2023, we moved to a larger space in Rockville with three rooms. Capital was allocated toward renovations and the team was bright-eyed for the explosion we expected to see.
But I missed a critical part of my hypothesis: We needed to create the market first. On top of that, the software in place wasn’t built to deliver what was expected.
In this reflection, I’m discussing the software and leaving the intracacies of demand generation & business development for a separate installment (read here when available).
The Problem
We ran the business on:
- A static website deployed on GitHub Pages with CloudFlare in front. Had to keep the costs at exactly zero. Any incurred subscription fee came out of my own bank account.
- Acuity Scheduling for bookings and memberships.
- No real authentication
- Data siloed inside Acuity with limited access (API locked behind a $70/mo tier, we were on $35/mo).
The cracks showed quickly (here’s the a small laundry list of things I dealt with for the first four years):
- Duplicate and messy records (e.g., “Joe .” vs. “Joe e” with the same phone number). I built fuzzy-match automations in Airtable to keep data clean, but it was fragile and exhausting.
- Reporting was on me. I built Airtable Interfaces to combine online and offline data; Think revenue, membership status, CLV, Eventbrite ticket data and customer satisfaction surveys. But everything relied on manual CSV exports from every data source — more overhead for me.
- Customers struggled with signups. I iterated various Loom walkthroughs, and still fielded hundreds of support tickets. Because music artists often book late at night, it clashed with my early schedule. So they’d have to wait, and I felt like it was poor customer support on my end. I was the only one who knew our tools inside and out, which made me the bottleneck in various ways.

- Billing and chargeback exploits cost us nearly five-figures in lost revenue before I caught it. That was a gut punch.
- Payments were messy. CashApp forwards meant engineers saw every client payment email — something I hated from both a privacy and professionalism standpoint.
- And the big one: we wanted to scale memberships (a new playbook I wanted to run), but the system simply wasn’t built for it.
I tried to make the best of it. With Zapier and Make.com, I had to parse the automated Acuity emails in our email to capture the data I needed to push it into Airtable; A very janky ELT pipeline but it got the job done.
I found a way to automate membership tracking — even created my own “Likelihood to Renew” metric based on booking frequency, event attendance, and survey ratings. It worked… but it was duct tape.

What I wanted was simple:
- Real identity and authentication.
- Seamless recurring payments (Apple Pay, Google Pay, CashApp via Stripe).
- Automatic membership tracking.
- A proper database for reporting and dashboards.
- One web app that handled it all.
My Period of Inflection
This wasn’t one lightbulb moment — it was an accumulation:
- Customers churning because of a clunky experience.
- Me drowning in support tickets.
- Losing revenue from billing & chargeback exploits.
- Trying to scale into Rockville while still exporting CSVs every month.
- A growing desire to lean into my technical skills instead of duct-taping SaaS tools together.
- Conversations with customers that validated my ideas for a better booking flow.
Over time, all of this made one thing clear: we needed to build our own system.
The Solution — Round One: Outsourcing (Failure)
At the top of 2023, I hired an Upwork team for $6k. They spent over 12 months building a Django app deployed on Vercel
The result?
- Ugly, clunky UI and DX
- Weeks-long delays on changes.
- A product that never launched.
That failure hurt — both financially and emotionally. I owned this failure because I didn’t know what I wanted as far as modern frameworks, deployment, and tooling goes. So I would have never been able to direct the outsourced team properly.
My friend told me about React and the idea of “dynamic” websites in 2018 but I was more focused on digital marketing at that point. I had a background in basic web dev skills: html, css, php, and vanilla js. Many modern concepts were unfamiliar to me and had a lot of catching up to do.
I had just completed my AWS Cloud Practitioner certification and thought deploying on there would be the best option.
I learned one crucial lesson: don’t outsource the architecture of your core system. Own it.

The Solution — Round Two: Building It Myself
Rather than spending months learning the basics of Next.js and even longer learning more advance topics, I took a shortcut.
By 2025, AI-assisted coding had exploded. Tools like Cursor & v0 gave me the confidence and leverage to build the system myself because I could fill in the knowledge gaps I had with modern frameworks.
Over four months, my productivity exploded, and I completed what a outsourcing failed to deliver me in a year.
The new stack:
- A dynamic, headless website built on Next.js and deployed in Vercel
- Clerk for authentication + subscription management.
- Cal.com (self-hosted) for bookings.
- Stripe for payments (with Apple Pay, Google Pay, CashApp).
- Supabase for database + logging.
- Railway for hosting our node.js server

It’s so clean and I’m proud to show it off because I know it can handle our growth efforts.
Launch & Impact
We officially launched on August 1, 2025 after a month of internal testing. Here’s how I rolled it out:
- Shut down hourly sessions in Acuity and redirected everyone to the new system.
- Let ~20 monthly Acuity memberships expire naturally in August (auto-renewals off).
- By September, all customers were fully on our platform.
The first two weeks weren’t smooth. Session history wasn’t displaying, and booked sessions weren’t properly deducting hours in Clerk. I fixed the schema and sync logic quickly, and from there the system stabilized.
What we gained:
- A true auth-first booking system with Google sign-in.
- No more duplicate accounts or data hygiene nightmares.
- Seamless recurring payments, private to staff.
- A single source of truth for sessions, memberships, and revenue.
- A huge reduction in my support load.
- A much smoother CX.

Lessons Learned
- Scrappy automations are useful, but they don’t scale. They taught me discipline and creativity, but also why strong foundations matter.
- Build vs. Buy is personal. Losing money to an outsourced team solidified my belief that core systems need to be owned in-house.
- Data integrity is king. Everything flows from clean, reliable data. Clerk gave us the auth-first architecture Acuity never could.
- AI-assisted dev is a multiplier. With Cursor and v0, I delivered in months what once felt out of reach.
- Shipping is only step one. Owning the migration, fixing bugs, and stabilizing post-launch mattered as much as the build itself.
Future Roadmap
- Dashboards for the team. Surface revenue, usage, and churn data directly in our web app so staff don’t need to touch Airtable.
- Discord bot for internal customers. I believe in meeting users where they already are. Since my team is also my customer, I built a bot that lets our engineers and artist development team members check active/churned memberships, renewal details, and session activity (booked, canceled, rescheduled) without leaving Discord.
- Perfect revenue before expansion. Focus on scaling memberships and less time on support tickets.
- GTM system as a product. I’ve already been approached by another studio about using our system. Long-term, I plan to package this platform for other creative businesses.
- Refined payments + reporting. Stripe already handles Apple Pay, Google Pay, and CashApp, but I plan to keep improving how payments tie into reporting and forecasting.
- AI insights (later). Eventually, I want to layer in AI to predict churn and surface upsell opportunities, but only after the foundations pass stress-tests.
Closing
This wasn’t just about building a booking system. It was about transforming how we scale Double M Studios: from duct-taped automations and revenue leaks to a scalable GTM system that I built and now own.
It’s the foundation for both our future as a studio — and potentially a product other studios can run on too.
In short, this forced me to have high agency and iteration velocity to get it done. I got to be at the intersection of everything I love: Technology, Psychology, and Systems Design/Thinking.
I believe these three core domains drive how every scenario should end up for internal and external clients to both benefit.