I'm Not Vibe-Coding the Next Salesforce

The pitch for AI-assisted coding tools usually leans on the dream of the one-person unicorn. Solo founders shipping the next Notion, the next Stripe, the next [insert SaaS giant here]. Lovable, Bolt, Base44, Replit; they all flirt with this fantasy in their marketing.

That's not what's interesting to me, nor does it seem realistic, because building the actual app is only one small part of running a successful SaaS business.

What I've actually used vibe-coding for, over the past few months, is much smaller and much more useful: spinning up niche apps purpose-built for my own workflows. Each one solves a specific problem in how I run work.flowers. None of them are products I plan to ever sell. Most replaced an off-the-shelf tool I was already paying for, or a clunky workaround I'd rigged together in Zapier or Notion. Several now run for free on Cloudflare's free tier, after a quick migration off Lovable's hosting.

The reason I believe strongly in this approach is the insight that most operations problems aren't a missing platform. They're a missing 10% of an existing platform, plus 80% of features you'll never use, plus a $50-a-month bill. Vibe-coding lets you build the 10%, skip the 80%, and stop paying the bill.

Here are five apps I built. Each one replacing something I was paying for or putting up with.

For most of work.flowers' first year, I tracked client projects in Linear and had no good way to share progress with the clients themselves. The off-the-shelf option I tried was Lindie, a Linear-based client portal that cost about $50 a month. It worked, sort of, but it lacked key features I wanted, like custom-domain support and the ability to let clients respond to a comment by simply replying to an email notification. I tried syncing Linear data into Notion via Zapier (clunky, and it burned through Zapier tasks), then Zapier Interfaces (now called Zapier Forms, not designed for complex apps and no comment support). Neither worked.

Over a weekend in late November, I rebuilt the whole thing on Lovable. It now lives at clients.work.flowers.

The portal pulls issues, comments, and project data from Linear in near-real-time via Supabase Edge Functions. Clients sign in with a magic link or Google OAuth and see only the boards they have access to. They can comment on issues and create new tickets via a form. When they're tagged in a comment, they get a Resend-powered email notification and can reply directly to the email; that triggers a webhook back into Linear and posts the reply as a Linear comment.

The visibility trick I'm proudest of: internal team comments stay invisible to clients by default. If I want a comment to surface in the portal, I tag it with #portal. That single convention means I can keep the same Linear workspace for everything, with no separate "client-facing" project that needs constant syncing.

Cost to run: $0 a month (Lovable-managed hosting, Resend free tier). Cost it replaced: $50 a month.

The work.flowers homepage has a rotating carousel of client logos. For a year, that single feature was the only reason I was paying Elfsight $50 a year. Fifty dollars isn't objectively a lot, but it felt like a lot for such a simple feature.

A weekend with Claude Code produced widgets.work.flowers. It's a tiny admin app where I upload logos, set an order, and generate an embed code snippet that drops onto the homepage. The carousel itself is a few lines of CSS and JavaScript.

Total time invested: an hour or so. Total run cost: $0.

I won't pretend it's a product. It's $50 a year of recurring annoyance, removed.

Our CRM lives in Notion. I wanted the same contacts in my phone and laptop address books, so when a client texts me on WhatsApp or calls my mobile I see their name and company instead of an unknown number.

Nothing on the market does this well. Most contact-sync tools assume your CRM is HubSpot or Salesforce. The closest options were either expensive, clunky, or required leaving Notion as the source of truth.

I built it on Lovable, and it now lives at peoplesync.work.flowers. You sign in with Google, connect a Notion workspace and a Google account with Contacts access (each via its own OAuth flow, because the Google People API needs its own scope), pick the database you want to sync, and map its properties to standard Google Contact fields. From there, it syncs every 5 minutes, and you can sync on demand from the dashboard. Contacts deleted from Notion are cleaned up automatically on the Google side, and any duplicates that creep in can be merged from the UI.

I started on Lovable's hosting, then with a bit of help from Claude Code I migrated the whole thing to Cloudflare Pages with a standalone Supabase backend. The migration matters because it was using a lot of Lovable Cloud credits, and I didn’t want to have to start paying for a separate bucket of those credits, while Cloudflare Pages' and Supabase’s free tiers comfortably handle the volumes. Same app, same features, no recurring bill.

This is the niche-app sweet spot. "Sync Notion to Google Contacts" is too small a problem for any SaaS company to build a serious product around. For me, it's a daily quality-of-life upgrade.

As I wrote about last week, I've been using Claude Design heavily since it launched, including for creating project proposals. One quirk of how it works is that each deck is essentially a static HTML file, which you can export to other formats and share internally with other members of your Claude workspace, but with no native feature (yet) for sharing with external guests.

For client proposals, I wanted something nicer. A clean URL like decks.work.flowers/client-name, gated behind email magic link or Google sign-in, with access controlled per deck.

So I built it. decks.work.flowers is a simple gating layer. I export the HTML from Claude Design, drop it into a folder in a private GitHub repo, and a Supabase Edge Function serves it behind auth. Clients I share a deck with get added to that deck's allowlist; everyone else hits an "access denied" page.

The motivation here was different from the others. Rather than replacing a SaaS subscription, I was enabling a workflow I couldn't get any other way: client-facing decks served from my own domain, branded properly, with access I control per audience. Gamma and similar tools offer some of this, but they require you to build the deck inside their editor. I want to keep building decks in Claude Design and just host them how I want.

This one isn't work-related, but I'm including it because the building experience taught me the most.

I read a lot, and I keep highlights in Readwise. I wanted a visualisation of my highlights over time, filterable by source (book, article, podcast, tweet) and by tag. Readwise published an agent skill on GitHub and a CLI for pulling highlights data, so I started by building a local-only version with Claude Code, just to see if the data shape made sense.

Once it did, I migrated it to Lovable to host the live version with automatic refreshes and a few extra features (filtering, source-type breakdowns, search). It now lives at highlights.chiuten.co.

The app itself is unremarkable. "Make a personal data visualisation that updates daily" used to require either a paid SaaS tool with the wrong data model, or genuine engineering effort. Now it's a Saturday afternoon.

A few things stand out across all five projects.

The bill goes from recurring to zero. Lindie at $50 a month plus Elfsight at $60 a year is roughly $660 a year. That's not life-changing, but it's not nothing for a solo consultancy, and the trend matters more than the absolute figure. Each of these apps now has either no running cost (Cloudflare Pages free tier, Supabase free tier) or sits inside a single Lovable subscription I was already paying for to experiment.

The fit is exact. Off-the-shelf tools force you to adapt your workflow to their assumptions. Lindie wanted me to organise issues their way. Elfsight wanted me to manage logos in their dashboard. The Notion-to-Google-Contacts sync space wanted me to use HubSpot. Building the apps myself meant I could match my actual workflow: the #portal hashtag in Linear, the embed snippet in Bullet, the field-mapping in Notion that nobody else's product would ever support.

I understand the system end-to-end. When something breaks, I can fix it. When I want a new feature, I add it. There's no support ticket, no roadmap to lobby, no waiting for a third party to prioritise my edge case. This is also the part that requires real care: if you're building software that touches client data, "I sort of understand what's happening under the hood" isn't acceptable. I've been deliberately picking projects where the data is mine, the failure modes are obvious, and the security model is simple. None of these apps processes client PII.

The boundary between "use" and "build" dissolves. My default question when evaluating SaaS has changed. It used to be "which tool does this best?" Now it's "is this small enough that I should just build it?" For most niche workflow problems, the answer turns out to be yes.

The LinkedIn version of this story is always rosier than reality, so:

Vibe-coded apps are easy to build and easy to abandon. If you're not careful, you end up with a graveyard of half-finished tools you've forgotten the password to. I keep my list of running apps short and audit them quarterly.

Security and privacy are not solved by Claude Code being good at TypeScript. Anyone can vibe-code an app in an hour and have no idea what's actually happening with the data inside it. For anything touching client data, I run extra checks: read every dependency, audit every Edge Function, and assume nothing about defaults.

The migration off vendor-locked hosting (Lovable, Bolt, Replit) is worth doing for anything you intend to keep. Lovable is a wonderful place to prototype, but I don't want to be paying their hosting fee in two years for an app I built in two days. Cloudflare Pages plus Supabase is my default destination for anything that survives the prototyping phase.

The fantasy of vibe-coding the next Salesforce is mostly that: a fantasy. The daily value of these tools, in my experience, is much more boring and much more useful. Niche apps. Audience of one (or a small team). Free to run. Replacing recurring SaaS bills you didn't realise added up.

If you've got a $50-a-month tool you mostly hate, or a workflow that no off-the-shelf tool quite supports, that's the place to start. The investment is a weekend. The payback is permanent.

If you'd like help thinking through which workflows in your business are actually candidates for this, let's chat.

Book a discovery call Get in Touch