Push notifications for indie developers and solo founders

When you're solo, attention is the scarcest resource you have. You can't sit in front of a metrics dashboard, and you shouldn't want to. The right setup is the opposite: your screen stays quiet until something happens that you'd genuinely stop and look at, and then your phone tells you — even locked, even away from your desk.

The trap is over-notifying. A phone that buzzes forty times a day trains you to ignore it, and then you miss the one that mattered. So this isn't a list of everything you could push. It's the short list worth pushing, and the ruthless honesty about what belongs in a daily digest instead.

Every snippet below POSTs to a single notification URL — Lert's https://lert.dev/p/your-id — which you get by installing the app and copying it. No key, no SDK. Swap in your own and they run as-is.

1. A new sale

The one every founder wants. Nothing beats a real "cha-ching" on your lock screen the first time a stranger pays you. Wire it to your payment provider's webhook — Stripe, Lemon Squeezy, Paddle — or fire it straight from your checkout success handler.

if (event.type === "checkout.session.completed") {
  const s = event.data.object;
  await fetch(process.env.LERT_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      title: "💰 New sale · $" + (s.amount_total / 100),
      body: s.customer_details.email
    })
  });
}

Put the amount in the title so the lock screen tells you everything without opening anything. Full walkthrough in new sale notifications.

2. A new signup

Early on, every signup is a signal worth savouring — and a reason to maybe send a personal welcome while the iron's hot. Later, when signups outpace your attention, this is the first candidate to demote to a daily count. Know which phase you're in.

import requests, os

def on_signup(user):
    requests.post(os.environ["LERT_URL"], json={
        "title": "🎉 New signup",
        "body": f"{user.email} · plan: {user.plan}"
    })

See the Python guide for the full pattern.

3. An error spike

Not every error — that's how you get paged into numbness. The signal is a spike: errors crossing a threshold in a short window. Do the counting in your error handler or a small scheduled check, and only fire when the rate is abnormal.

# count errors in the last 5 min; only buzz past a threshold
if errors_last_5m > 20:
    requests.post(LERT_URL, json={
        "title": "⚠️ Error spike",
        "body": f"{errors_last_5m} errors in 5 min — check logs"
    })

This is the one that saves you from finding out about an outage via an angry customer email. Related: server monitoring alerts.

4. A finished deploy

A deploy takes long enough to lose your attention but not long enough to start something else — the worst duration. Let your pipeline tell you when production is live, or when a build broke, and stop babysitting the terminal. One line in CI does it.

- name: Notify phone
  if: always()
  run: |
    STATUS=${{ job.status }}
    curl -X POST "$LERT_URL" \
      -d "{\"title\":\"Deploy $STATUS\",\"body\":\"${{ github.repository }}\"}"

The dedicated write-up is deploy notifications, and there's a curl guide if you want the raw request.

5. A churn (cancellation)

Sales feel great; cancellations teach you more. A churn notification is a prompt to reach out while you still can — ask why, maybe save the account, at minimum learn something. It's the same webhook you already set up for sales, just a different event type.

if (event.type === "customer.subscription.deleted") {
  await fetch(process.env.LERT_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      title: "👋 Cancellation",
      body: event.data.object.customer + " churned — reach out?"
    })
  });
}

Wiring it without building infrastructure

Notice what none of these snippets needed: no push certificates, no APNs/FCM plumbing, no notification microservice, no queue, no database table of device tokens. That machinery exists to send pushes to thousands of other people's phones. You're sending to one — yours. The whole apparatus collapses into a URL you POST to.

That's the unlock for a solo dev: the events live wherever they naturally happen — a webhook handler, an error path, a CI step, a cron job — and each just adds one fetch or curl. No new system to run, nothing else to monitor, nothing to wake you at 3am because the alerting stack fell over.

The best monitoring setup for a company of one is the one you can stand up in ten minutes and never think about again. Complexity you maintain alone is a liability, not a feature.

Where to go from here

Start with just the sale and the deploy — the two with the highest signal-to-effort ratio — and live with them for a week. Add the error spike once you've picked a sane threshold. Only add signups and churn if you'll actually act on them. If you later want your AI tooling to ping you too, that's the same URL exposed as a tool; see AI agent notifications and what an MCP server is.

Five events, five one-liners, zero infrastructure. That's the entire notification strategy a solo founder needs — and the discipline to keep it to five is the hard part, not the code.