It's a fair question. Why would a data consulting company, one that lives and breathes data stacks, pipelines, and analytics, spend time building a calendar synchronization tool? On the surface, gcalsync.io seems like a detour, a side quest from our main mission.
But it's not.
The story of gcalsync.io is about more than just solving a scheduling headache. It's about scratching your own itch, embracing a product mindset, and understanding that the lessons learned from a "small" project can have a massive impact on our core business. It's about how a side quest can, in fact, make us better consultants.
The Problem: A Consultant's Calendar Chaos
If you're a consultant or freelancer, you know the pain. You have your personal Google Calendar, your company calendar (@blueprintdata.xyz in our case), and then client-specific accounts. Client A gives you an email, Client B another. Suddenly, your life is fragmented across half a dozen calendars.
You try to keep them in sync manually, but you miss things. You get double booked. You’re looking at your personal calendar on your phone and have no idea if you’re actually free because you forgot about a meeting on a client's calendar. It’s chaos.
For a long time, I wrestled with this using a custom Google Apps Script. It was a decent workaround, but it was brittle and a pain to configure for every new email account. Every new client meant another round of tedious setup.
The "aha!" moment came when my Blueprint co-founder, Manu, complained about the exact same issue. He asked about my scripts, and I knew they weren't the answer. There was a clear, shared need for something simple, elegant, and quick.
The Solution: Simple, Straightforward, and Effective
That's how gcalsync.io was born. The concept is simple: when a client blocks time on their company calendar, it automatically replicates to your personal and other work calendars.
Crucially, you control the level of detail. Client B can see you’re busy, but they don’t need to see you have a "Project X Deep Dive" with Client A. It maintains privacy while ensuring your availability is always up-to-date across all your accounts. It gets the job done. No more, no less.
We knew there were other, more complex solutions out there. But we didn't need a Swiss Army knife. We needed a scalpel. Something simple, straightforward, and cheap that solves one problem really well.
The Journey: Building a SaaS From Scratch
We managed to get the first version working in about four days. This quick turnaround was possible because we stuck to a core philosophy: leverage what you know, but leave some room to explore.
Our stack was straightforward:
- Next.js for the frontend and "backend" API.
- Supabase for the database and authentication.
- Resend for handling emails.
- Polar for payments.
- Fly.io for hosting, Cloudflare for DNS, and Doppler for secrets management.
But building the core functionality was just the tip of the iceberg. The real learning experience was everything else that goes into launching a SaaS product: wrestling with domains, setting up cron jobs (cron-job.org is a lifesaver), handling secrets, navigating the Google API verification process, and figuring out SEO.
Payments were a journey in itself. We had never integrated a payment system before, so we experimented with Stripe and Lemon Squeezy before landing on Polar. This hands-on experience was invaluable.
The Real Value: An Education in Product Building
We got some early users through friends and a few posts on X (Twitter). Their feedback was gold. One of the first feature requests came from a friend who uses multiple Chrome profiles. This led to implementing a cross-browser login solution (something we hadn't initially considered).
To be clear, we don't expect gcalsync.io to make us millions. The real value is the education. It's the process of building, launching, and listening.
Conclusion: How a Side Quest Makes Us Better Data Consultants
This brings us back to the original question. Why do this?
Because as consultants, our job is to understand our clients' problems deeply. This project was a masterclass in that. We experienced the full lifecycle of a problem, from personal pain point to shipped solution.
We now have a much deeper empathy for the challenges our clients face when building their own products. We’ve learned which problems are recurrent and which ones can be "productized." This experience means that if—or when—we decide to build a full-fledged, data-oriented product, we won’t be starting from scratch. We’ve already made some of the mistakes and learned some of the lessons along the way.
This "side quest" wasn't a distraction. It was an investment in our own skills, mindset, and future. And it’s made us better at what we do every day.