My Bespoke Snowflake CRM v0.0.1
What I'm learning — and why I broke buy before you build to wire a one-user CRM to how I actually think. This might be a really really bad idea.
6 min read
Build log
This is something I could call a bad idea that I should never have done — but it has worked really, really well.
I preach buy before you build. I spent weeks fighting Beehiiv anyway, trying to force the creative process for building a website, organizing data, and learning how a newsletter should be built through the sieve — through the confined gauntlet of Beehiiv’s AI, which was great but not great, or doing it manually, which just took hours of figuring out how it should be done Beehiiv style. When I applied my utility rate to the pricing page, I was using less than 10% of what I paid for. That’s a problem — and it’s what cracked a strongly held belief.
Stack map: Snowflake CRM tech stack → — Supabase, Postmark, PostHog, Inngest, Cursor. Booking: Vibecoding Calendly? Really? →
The suit that fits everyone
SaaS tools are designed for everyone. It’s kind of like buying a suit that fits everyone but no one well — and you have to buy a belt and cinch it in at the waist to make it work. Or if you’re a woman, it’s buying a dress and being told here’s a big wide belt, make it work. It never works, but it was the best way for so long.
I looked around at Beehiiv, Kit (ConvertKit), and Substack. About a year ago when I got started, I absolutely thought Beehiiv made sense — good analytics, good ads. But if I’m only using five to eight percent of the features, I looked at what I was already paying for: ImprovMX for eight bucks a month and fifteen dollars a month for mail delivery through Postmark. Maybe I should think about undoing buy before you build.
What I found is that if I can pull information down and harness a suite of MCPs, I can speed things up immensely. My first pass: Cursor, an MCP bench wired into my tools, and throughput — not great throughput, but throughput — because I really want to learn how to build a better newsletter that has engagements and lead magnets and can drive statistics.
What I was trying to learn
All the newsletter recommendations, all the patterns: choose one, two, or three content pillars, write on them consistently, tie them together into a narrative. I started looking at Justin Welsh’s The Weekend Essayist or The Weekend Entrepreneur, thinking about how am I going to get myself confined.
I’d spent the last year writing. I’d grown my newsletter to about a thousand people, but I wasn’t getting that sweet spot engagement where the analytics numbers were flowing back and I was getting signals. I wasn’t using forms. I wasn’t using custom tags. I wasn’t using custom data. Even though I had people paying for it, I felt very detached from what I was building. The time from idea to execution I’d measure in hours or days, and ideas felt stagnant.
My big change was when I realized: what would the actual cost be for building my own version of Beehiiv? It’s not lost on me that this is the exact opposite of what a low-code CTO or low-code team should be doing. But I took a risk. I screenshotted the Beehiiv features I actually used, built a roadmap, and started to look at what the total token-cost build would be.
No air gap — why I didn’t stop at Beehiiv
In a leap of absolute stupidity — even though I was only paying fourteen dollars a month for Calendly — I decided that if I was going to rebuild Beehiiv, I might as well pull my brand through as far as I possibly can.
I wanted my CRM to not have an air gap. I wanted people to use my booking page, my newsletter, my emails, my domains — all in one stack. If I had an idea, my MCP could implement it across my entire instance: manage subdomains, manage domains, manage email delivery. Separate domains with separate signatures, all tied together and feeding information back to my Gmail account.
Four days of about three hours of vibe coding a day got the architecture in place. Another month integrated my processes and Astro — four sub-apps for booking, content, gated content, and automation. The four Beehiiv features I actually needed: deliverability, automation, dynamic templates, and analytics. Automation after a lead-magnet signup was the one I thought would be almost impossible to replace.
The hard part wasn’t Beehiiv
The only sticking point was when I decided to reverse engineer Calendly. Same process: screenshots, markup, knock out or black out what I didn’t want — things that seemed like great ideas at the time but I never used, like a Stripe integration for payment.
I configured multiple public and private calendars and a public landing page. I screenshotted the features I liked, but made sure it integrated directly back into my CRM. Tags or slugs on different calendars drive different automations. PostHog and first-party cookies let me understand how people move across my domains.
Full write-up: Vibecoding Calendly? Really? →
What I’m learning now
I can now sit down, use my fourteen-step content engine to interview myself, build out an idea, cross-reference it, reference past writings, reference past networking or conversations, pull in my transcripts, and send out and schedule an email. I have a content calendar that ties directly into my thinking. Gmail conversations flow into conversations in my CRM.
I got a CRM so tightly integrated with my own personal process that it actually would not work for someone else. It feels like software so bespoke that there’s literally one user in the world who would value it — because I’m the only person who thinks in quite that unique, snowflakey kind of way.
The crazy thing is Supabase supports multi-user. My system has only one user — me. I hard-code my UUID because there’s no reason for me to support multiple users. Egocentric permissioning: there’s only one, there’s only one ever. One UUID hard-coded into a secret within the edge functions and that’s it. That is a surprisingly huge win — multi-user, multi-tenant systems come with phenomenal overhead on auth and access control.
Would I recommend this?
I don’t know if this is a good idea for anybody else to use. But the patterns I was seeing in SaaS products — having to force my ideas and my workflow into code to use a one-size-fits-all solution across stacks — meant I always had a gap between what I wanted my CRM to do and what it could actually do.
If you’re staring at the same spreadsheet — utility rate under ten percent, Postmark and ImprovMX already on the card — don’t copy my stack. Copy the question: what’s your utility rate, and what’s the gap costing you in stagnant ideas?
Tools and features: Snowflake CRM tech stack → · Vibecoding Calendly? Really? →