Pete, the indie hacker

Snapshot

A day in their life

Wakes up, checks Stripe before coffee. Scrolls X, replies to a customer, ships a feature their coding agent mostly wrote, deploys straight to production at 11pm because there is no one to ask. There is no staging environment worth the name, no runbook, and no monitoring beyond the platform dashboard they forget to open. When something breaks, the discovery mechanism is a customer email, a refund request, or a dip on the revenue graph. The worst incidents are the quiet ones: a cron job that stopped three weeks ago, a queue silently retrying forever.

Stack and tools

Tool	The job it does
TypeScript	The whole product in one language, end to end
Cloudflare	Workers, Pages, D1, R2, KV, Queues: often the entire product
Vercel	The other common home; deploys straight from the repo
Fly.io / Render	A container or a cron when something will not fit a Worker
Supabase	Postgres, auth, and storage in one signup
PlanetScale / Turso	The database once it needs to be serious, or SQLite at the edge
Upstash	Redis and queues, paid by the request
GitHub	Everything; deploy config lives next to the code
Claude Code / Cursor	Writes most of the code; they review less of it than they admit
OpenAI	The API behind whatever the product's AI feature is this month
Stripe	Revenue, checked before coffee
Resend	Transactional email in ten minutes
Clerk	Auth they refuse to build themselves
PostHog / Plausible	Just enough analytics to see the graph dip
Notion	The doc that functions as the company
Axiom / Better Stack	Free-tier logs and an uptime check; anything heavier is enterprise prices for enterprise problems

Goals and motivations

• Keep the products alive and the revenue graph up with minimum operational attention.
• Wake up to resolved problems, not alerts. They do not want a monitoring practice; they want the outcome of one.
• Look more professional than a one-person shop: fast incident response makes a solo product feel like a company.
• Stay in flow. Anything that demands configuration, threshold tuning, or dashboard-watching is a tax on shipping.

Where they hang out

They follow individual builders and founding engineers, not brands; founder-posted content outperforms company accounts with them by a wide margin. In person, rarely: a local indie hacker meetup, maybe MicroConf once. The internet is the venue.

How to reach them

What fails: cold email and LinkedIn anything (they live on X), gated whitepapers and "book a demo" (a demo request is a bounce), and enterprise social proof (they want a solo founder's testimonial, not a bank's).

What they resonate with

• "Nobody should be on-call in 2026" lands perfectly, because for them on-call is not a rotation, it is a life sentence.
• Small, sharp tools made by small, opinionated teams. Linear, Raycast, Fly.io, Plausible aesthetics: dense, fast, no fluff.
• Pay-for-value pricing with a real free tier. Flat price plus usage they can see. They deeply distrust per-seat and per-host pricing.
• Underdog and craftsmanship narratives. A founder who ships in public and answers their email personally.
• Radical transparency: public roadmaps, honest postmortems, changelogs with personality.

What turns them off: AI hype language without evidence, "contact sales", per-seat pricing for a team of one, tools that need a week of setup, anything that emails too much.

Hobbies and personality

• Their side projects are the hobby; building is what they do to relax, which is also the problem.
• Typical off-screen interests: cycling or bouldering, specialty coffee, mechanical keyboards, gaming (factory and strategy games disproportionately), home automation and a modest self-hosting habit.
• Personality: optimistic, scrappy, impatient, allergic to process. High agency, low tolerance for friction. Makes buying decisions in minutes, alone, usually at night.
• Financially self-reliant and proud of it; the flip side is cost anxiety about every recurring charge.

Journey through the product

The whole journey happens in one sitting, alone, usually at night. The first detected issue is the fork in the road: it either gets screenshotted or the tab gets closed.

They live mostly outside the console afterward: the weekly digest, an issue-detected email, autofix pull requests appearing in GitHub, the occasional production question asked from the editor over MCP. The upgrade is never a decision meeting; it is the morning after the free tier held back a second real incident, or a bad week drained the credit pool while things were on fire.

Feature affinities

• The topology map and the first detected issue: first value, and the thing they show others.
• Autofix pull requests: a fix waiting for review, mergeable from a phone.
• Autonomous rollback on their deployment platform, once trust is earned; it is the closest thing to "the site heals itself".
• The weekly digest as their entire operations review.
• Setup through the coding agent they already use; zero new tools to learn.

Objections and friction

• Cloud token permissions feel scary: they are being asked to hand over keys to their livelihood. Read-only by default, minimal scopes, and plain-English explanations of every permission are what get them through the connect screen.
• Cost anxiety: credits are abstract until the usage page makes them concrete. The $80 step needs a story like "this caught the thing that would have cost me a weekend".
• Zero noise tolerance: one false alarm is forgiven, two and the emails get filtered, three and they churn silently.

What success looks like

• A problem was detected, investigated, and a correct fix PR was waiting before they knew anything was wrong. They tweet about it, which is also the growth loop.
• The weekly digest becomes the only operations ritual they have, and it is enough.

In their own words

• "I don't want observability. I want to not think about this."
• "If connecting takes more than ten minutes, I'm out."
• "Show me the permissions you're asking for and why, in English."
• "$80 is a lot until the night it isn't."