chrisfrantz

PLG is hard. Very few companies can actually do it well. It demands an excellent product bar, compounding growth and both of those teams actually work with each other instead of against.

Series A starts the treadmill. Now you have compounding growth requirements and you can’t afford to retool product when things slow down.

So you shut down onboarding because conversion rates are always better when users are being handheld and that doesn’t break product.

That logic stacks as you scale and the pressure from VC’s mount.

FWIW, I run a competing company in the space and we skipped the Series A specifically because we have gone down this path before. That doesn’t mean we have a better product by default but we don’t have those same pressures and we can just retool things when needed. Almost 5 years in and we don’t even offer annual plans unless someone really twists our arm, our time is focused on product vs revenue growth.

That is a hard line to walk if you’re on the VC climb.

Full article is there but to avoid triggering Gmail’s spam filters: either disable link tracking on YouTube share links, or use the full YouTube link instead.

Chrome, latest stable

Love that this exists now, thank you and nice read.

FWIW, didn't have any luck with the generator at the bottom, could be user error.

This is where I believe we are headed as well. Frontier models "curate" and provide guardrails, very fast and competent agents do the work at incredibly high throughput. Once frontier hits cracks the "taste" barrier and context is wide enough, even this level of delivery + intelligence will be sufficient to implement the work.

We reached some amount of early product-market fit and the “starter” stack that served us well early on: Vercel functions, Supabase Postgres, and a mix of queue services, started hitting limits. Function runtimes capped at 15 min, cron jobs had to be public, queues kept sun-setting, and the database had no automatic fail-over. We were spending more hours nursing infra than building features.

Over the next six months we rebuilt on plain AWS: EKS for the Next.js app, Aurora Postgres in-VPC, SQS for jobs, all managed with Terraform. A Cloudflare Worker mirrored an increasing slice of live traffic to Kubernetes until everything looked solid, then a DNS flip made it the source of truth.

Supabase data flowed into Aurora via logical replication; once lag was near zero we swapped the connection string and retired the old stack without users noticing. Costs are predictable now and we control most knobs.

We put this post together as a bit of a retro and to help if you're evaluating a similar path for your company.

We released an update to our pricing at Loops and along with increasing free limits, we made transactional email sending available at no additional cost on any paid plan.

We removed our previous plan tier of $1 per 2,000 sends.

Example: You have 4,000 users and you send an automated onboarding email along with an occasional product update every month or two.

Your product also generates daily rollup emails, along with product notifications, and other standard transactional emails, maybe 100,000 emails a month total.

That's now available at the same price, just $49.

Say next month you gain another 500 users and you send 200,000 emails. That's still just $49 a month.

Our goal is to help you send all your emails from one platform for a single price point and this gets us one step closer.

We recently did some work improving our email deliverability to large institutions that use Rspamd as part of their corporate firewall, this is our write-up on that experience.

A couple years in, we’re still building Loops (loops.so), email for software companies.

Congrats Dima and team, it's been cool watching you build this over the last couple of years.