Scaling Sales with Engineering

Background

When three friends and myself founded Double M Studios, we first launched in a basement Olney, MD. We were a lean operation with one recording room. The business operated as your traditional service-based business: clients would reserve a slot for a pre-defined price and we’d render services. To promote business growth, we’d run typical marketing campaigns: 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. It’s your classic supply/demand economics.

This works for many businesses: Superstores, airlines, retail stores. But “scaling up” meant a significant increase to OpEx. That felt like bloat and quickly identified this as horizontal growth, but my eyes were set on vertical growth rather than horizontal.

The question was how can this be done?

That mustard seed grew into a change in strategy with a long road of unlearning, re-educating, and deconstructing our systems and processes. From reading a couple dozen business books, a few stuck out the most to me and with this newfound knowledge, I put it to work.

I spent 6 months interviewing our customers in groups by amount spent and frequency of visits. I wanted to test my hypothesis:

I distilled my notes, validated the idea, and built the new offering: A subscription model with three tiers, drawing inspiration from SaaS. 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. There were major gaps in what I knew, what I learned, and what was required but I was determined to figure it out.

In this reflection, I’m discussing how I approached building the software required to make this possible and leaving the intricacies of demand generation & business development for a separate installment (read here when available).

Both sides, business + technical, pushed and pulled me down several rabbit holes and my conviction to solve the problem I created served as my forcing function of personal and professional growth.

Let’s dive in

The Problem

We ran the business on:

The cracks showed quickly and I spent all of my time functionally in RevOps + Marketing. Here’s a small laundry list of things I dealt with for the first four years:

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:

My Period of Inflection

This wasn’t one lightbulb moment — it was an accumulation of “How can this be better?”:

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 AWS

The result?

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 reminded me about React and the idea of “decoupled/headless web apps” 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. I had a lot of catching up to do to wrap my head around it.

I 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. Beyond that, it was my creation and I was intimately familiar with each component.

The new stack:

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:

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:

Lessons Learned

Future Roadmap

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.