When Great Ideas Make No Money: Hard Lessons from Building TMCBAE

Remember that late-night coding session when you couldn't stop because an idea had completely consumed you? The room grows dark, coffee grows cold, but your fingers keep dancing across the keyboard because something inside you knows this idea needs to exist in the world. Logic and business sense be damned: you're building this thing.

I lived in that state for months while creating TMCBAE (This Meeting Could Be An Email), and the journey taught me lessons I never expected to learn.

The Siren Call of Building Without Validation

As developers, we're taught early and often about the importance of product validation. Talk to users. Test your hypothesis. Find product-market fit before investing months of development. It's Indie Hacking 101.

And yet, armed with over a decade of professional experience, I threw all that wisdom out the window when I built TMCBAE – a Tinder-style app for canceling unnecessary meetings.

Why? Because I just really, really wanted to build it.

The mystery here isn't why the app didn't become commercially successful—that part was predictable. The real enigma is why experienced developers like myself sometimes deliberately ignore everything we know about successful product development and build things anyway.

The Curious Case of a "Tinder for Canceling Meetings"

The concept was simple but audacious: create an app where team members could swipe right on meetings they felt could be improved or eliminated, and when enough people matched on the same meeting, they'd collectively vote on better alternatives.

Even as I started building, the red flags were unmistakable:

Users couldn't get value from it alone, they needed teammates to join
Not just any teammates, but specifically colleagues with overlapping meetings
The app required both critical mass and organizational cultural alignment
The cultural shift required for widespread adoption was massive

These weren't minor hurdles, they were Mount Everest-sized adoption barriers. I knew this.

Yet I kept building.

The Technical Marathon: From Calendar API to Multi-Team Support

What followed was months of intense work on several key technical challenges:

Google Calendar Integration

Understanding how to integrate with Google Calendar's API was the first major hurdle. I spent considerable time learning the ins and outs of the API, fetching all the data needed to provide a great swiping experience.

Going through Google's OAuth review process to get access to the calendar scopes I needed was far more work than I expected. The review process was rigorous, requiring detailed explanations of how user data would be handled.

Once approved, I faced numerous edge cases in the calendar data:

Recurring meetings with complex patterns
Various meeting types that needed to be handled differently
Ensuring the right events appeared for swiping

Building the Core Functionality

Beyond the calendar integration, I needed to build:

A matching system to identify when enough team members wanted to change a meeting
A post-match voting system so people could participate in deciding how to transform "meetings that could be an email"
Subscription handling (with RevenueCat making this part more manageable)
Authentication flows
An in-app account deletion feature required by Apple

The Multi-Team Pivot

After initial beta testing, I discovered that multi-team support would be a game-changer for users. This meant implementing:

A team management system
One-to-many subscription approach
Ensuring meetings were correctly associated with the right teams

This addition significantly increased the scope, but seemed essential to deliver real value.

The Design Transformation

At this point, my friends who initially feared I was going crazy for pursuing this "Tinder for cancelling meetings" idea started to give me some praise. After all, it represented a substantial amount of work.

This is when Bruno Quadros, an old friend of mine and a great Product Designer, decided to put some time into redesigning the app and creating a great app icon. His work transformed the look and feel completely, making the app incredibly polished. This meant more development time before launching, but the visual upgrade was worth it.

Launch Day: Dreams Meet Reality

When TMCBAE finally launched, I was extremely happy to see my vision come to life. Some beta testing teams were interested in expanding their use, which was encouraging.

The timing seemed perfect: many companies were trying to be more efficient by reducing meetings in the aftermath of pandemic-induced remote work. The meetings madness was draining team efficiency, and people were looking for solutions.

Even Shopify had launched an extension to show how much their meetings were costing a few months earlier, encouraging employees to reduce unnecessary meetings. This trend seemed to validate the need for a tool like TMCBAE.

Some users found the app super cool and a great conversation starter to help teams reduce meetings without being rude, while also providing alternatives to canceled meetings.

However, I discovered something unexpected: some people actively want meetings. They enjoy the sense of control meetings provide and fear missing important conversations. There's a real attachment to synchronous communication, even when async processes might be more efficient.

I encountered extreme resistance to adoption, even though many people silently believed that fewer meetings could lead to better work.

So Did It Fail? Yes and No

From a financial perspective, TMCBAE was a spectacular failure. A work-intensive app that made virtually no money.

But was it really a failure?

I knew I wasn't following the golden rules of successful indie development. I understood it was a crazy idea with significant adoption friction. My goal wasn't primarily financial, it was to develop my first app with AI assistance and to address a topic I cared deeply about: reducing unnecessary meetings.

By those measures, it accomplished its purpose:

I got back to building my own apps in my spare time
I learned a tremendous amount about using AI to write code (without AI, I wouldn't have been able to ship everything I wanted to btw)
It gave me material for this very blog post, sharing lessons on how not to build your ideas. It is worth it a share, isn't it? :P

The Technical Growth Accelerator

Beyond the product itself, TMCBAE served as an intensive technical growth opportunity, forcing me to tackle:

Modern iOS development patterns
Complex API integrations
Puzzling match-making system
Subscription management
Team-based permission systems

These skills have proven valuable in subsequent projects, making the time investment worthwhile beyond the app itself.

The Paradoxical Wisdom of Building "Impractical" Things

Perhaps the most important lesson from TMCBAE isn't about product validation or market fit, but about the value of building things that matter to you personally, even when conventional wisdom suggests otherwise.

Sometimes the greatest learning comes not from following best practices, but from intentionally breaking the rules to see what happens. Sometimes you build not to succeed commercially, but to succeed personally, to grow, to create, to express.

Would I recommend other developers follow my approach? Probably not. The traditional advice about validation exists for good reason.

What I can say with certainty is that there's tremendous value in every shipped project, regardless of its commercial outcome. Each deployed app, each solved problem, each technical challenge overcome becomes part of your developer DNA, shaping how you'll approach every project that follows.

What rules are you following that might be worth questioning? What idea won't leave you alone, despite all practical considerations? Maybe that's exactly the project that will teach you what you most need to learn.

After all, sometimes you can just build stuff.