Forem: Giga Kovaliovi

I replaced my boilerplate's setup wizard with a prompt

Giga Kovaliovi — Tue, 21 Apr 2026 13:18:33 +0000

When someone clones a SaaS boilerplate, they spend the next 3 hours clicking through provider dashboards, dropping env vars into .env, and debugging why pnpm dev can't connect to their database. Every boilerplate I've used or shipped has tried to automate this away. They all failed in the same way.

Here's what failed for me in the past:

CLI wizards (pnpm setup). You answer 40 questions. Great on the first run. But half the answers require you to leave the terminal, open a browser, navigate a dashboard, copy something, come back, and paste. The CLI has no way to show you the Clerk sidebar. It just asks. If you paste the wrong thing, it blows up three steps later.

Setup videos. Great marketing, useless for actual setup because Clerk's UI looked different 6 months ago and Stripe's is different again.

.env.example with comments. You read them. You get confused. You Google. You find a 2023 Stack Overflow that doesn't match the 2025 UI. You give up.

The thing all three approaches miss is that setup has two kinds of steps:

Running a command — deterministic, perfect for automation
Clicking through a provider dashboard — non-deterministic, needs a human plus a guide
What works, in my experience, is the second kind of step getting someone sitting next to you saying "click API Keys, then Secret, paste it here." That's not a wizard. That's a coach.

So I made the coach a prompt you paste into Claude Code.

The prompt
I just cloned this SaaS boilerplate into the current directory and I've never set up a dev environment. My operating system is [Mac / Linux / Windows]. Walk me through everything one step at a time, pausing after each:

Check whether pnpm is installed. If not, run npm install -g pnpm and wait for me to confirm.
Read AGENTS.md so you understand the repo.
Run cp .env.example .env.
Ask me whether I received a license key. If yes, paste it into .env.
Walk me through filling in .env one provider at a time — Clerk, then Supabase, then Anthropic. For each, tell me exactly what to click and which values to paste where. Pause after each.
Run pnpm install, pnpm setup:db, pnpm dev.
Guide me to localhost:5173, sign up, and generate one AI response. Rules: one command or dashboard at a time; show file edits as diffs before applying; if I paste an error, diagnose before retrying. Paste that into Claude Code, Cursor, or Codex CLI inside a cloned repo and the AI does the rest. 30–45 minutes later you have a running SaaS.

What the AI is actually doing
It reads AGENTS.md (a repo-specific guide I ship) and knows the file layout, build commands, and which providers are wired. When it asks you to go to Clerk's dashboard, it knows to then write VITE_CLERK_PUBLISHABLE_KEY, CLERK_PUBLISHABLE_KEY, and CLERK_SECRET_KEY (three fields, two of which are the same value — the kind of detail a CLI wizard gets wrong). When you paste what you think is a secret key and it's actually a publishable key, the AI catches it from the prefix (sk_ vs pk_) and asks you to re-paste.

It handles errors you paste back verbatim ("pnpm: command not found means…"). It handles dashboard UI changes, because it reads what's on screen (in your explanation) rather than relying on a 6-month-old screenshot.

What I learned
Paste-a-prompt beats click-a-wizard because the AI sees the whole repo as context and can show you diffs of changes before applying them.
"One thing at a time" is the single most important rule in the prompt. The AI will otherwise try to parallelize and lose you.
Env var updates shown as visible diffs (not silent writes) build trust.
This only works because AI coding tools became mainstream in 2025. A year ago I'd have written a CLI wizard and it would've been worse.
Try it
The boilerplate is at akamaru.dev. Open the README's "vibe-code path" section, paste the prompt into Claude Code / Cursor / Codex, and you should have a running SaaS in 30–45 minutes.

The interesting part for me wasn't the Clerk + Paddle + Supabase + Anthropic wiring — every boilerplate has some version of that. It was realizing that first-time-user experience is now a thing you delegate to an LLM instead of hand-crafting a wizard for.

Has anyone else moved their onboarding flow into a prompt? I'd love to hear how it went.

Your on-call engineer just got paged. Here's what happens to the postmortem.

Giga Kovaliovi — Fri, 10 Apr 2026 11:11:53 +0000

The problem nobody wants to admit

It's 3:47am. The alert fires. You and two engineers spend 90 minutes triaging a database connection pool exhaustion. The service recovers at 5:11am.

By 9am, your Slack has three messages: "Can someone write up the postmortem?" Nobody does. By Friday it's a ticket in the backlog. By next week, it's gone.

This isn't a discipline problem. It's a friction problem. Postmortems are painful to write — especially after a night incident where you're running on adrenaline and three cups of coffee.

What Opsrift actually does

Opsrift connects to your monitoring and alerting stack — PagerDuty, OpsGenie, Datadog, or Grafana — pulls the incident data, and generates a complete structured postmortem in under 60 seconds. Not a blank template — a filled document with:

Incident timeline (auto-built from your alert source events)
Root cause section (framed as "AI hypothesis — verify before publishing")
Impact summary with MTTA/MTTR calculated automatically
Action items pushed to Jira in one click
Confluence publish in ADF format — one click
Slack notification on publish

Six tools total: Postmortem Generator, Shift Handover Generator, Runbook Generator, Incident Assistant, Status Page Generator, and Incident Forecast. All pull from the same 9 integrations.

Incident Assistant — the tool we actually use most

During a live incident, paste your alert or import it from PagerDuty/OpsGenie/Datadog. You get:

Plain-English summary of what the alert means
3–5 likely causes ranked by probability
Specific investigation steps with commands
Relevant Confluence runbooks if connected
Escalation guidance

Not replacing your judgment. Saving you 15 minutes of tab-switching at the worst possible moment.

Incident Forecast — the tool that's easy to miss

After enough incidents accumulate, patterns emerge. Which services fire most often? Which time windows are highest risk? Which action items never get closed?

Incident Forecast surfaces these signals proactively — so your team can prioritize reliability work before the next P1 fires, not after.

Who it's built for

SRE and DevOps teams running PagerDuty, OpsGenie, Datadog, or Grafana in a 24/7 environment
NOC teams who need shift handovers that contain the right context
iGaming and FinTech ops where documentation speed directly affects SLA compliance

Try it free

7-day free trial — all 6 tools, all 9 integrations, no commitment. Start with the Incident Assistant if you're mid-incident.

→ opsrift.com

I built an AI tool for incident investigation (looking for honest feedback)

Giga Kovaliovi — Fri, 27 Mar 2026 12:42:45 +0000

Hey everyone 👋

Over the past couple of weeks, I’ve been building a side project called Opsrift.

It started from a pretty simple frustration:postmortems, handovers, and incident documentation take way too much time — and most of it is repetitive.

But while building it, I realized something more interesting:

The real problem isn’t writing postmortems.It’s understanding what actually happened during an incident.

So I ended up going a bit further than just a generator.

What Opsrift does right now

The platform is focused on incident workflows — mostly for people working in SRE, support, or operations.

Right now it includes:

Postmortem generator

Takes incident data and generates structured postmortems in seconds.

Handover generator

Useful for shift-based teams — turns messy updates into clean handovers.

Runbook generator

Creates structured runbooks based on incident patterns or inputs.

Incident Investigator (main focus)

This is the part I’m most interested in:

Pulls data from tools like Jira, PagerDuty, and Opsgenie

Correlates it with deployments from GitHub

Tries to reconstruct what actually happened (timeline, possible causes, etc.)

The goal is to reduce the time spent jumping between tools during investigations.

Status page

Basic external communication for incidents.

Integrations

Current integrations:

Jira

PagerDuty

Opsgenie

GitHub

Slack

Confluence

Still early — some of these are rough.

What it’s NOT (yet)

I want to be upfront:

It’s not a replacement for your incident management tools

It’s not perfect at root cause analysis

It’s not “production-grade” in every edge case

Right now it’s closer to:

an AI layer on top of your existing tools to speed up investigation and documentation

Known issues

To save you time:

GitHub login ❌ (bugged right now)

Slack login ❌ (also bugged)

👉 You can still use:

Google login

Email/password signup

Fixing these next.

What I’m trying to figure out

This is where I’d really appreciate help.

I’m trying to validate a few things:

Does the Incident Investigator actually help or is it just “nice to have”?

Are the outputs accurate enough to be trusted?

Would you use something like this in real workflows?

What’s missing for it to be genuinely useful?

Where I want to take this

Longer term, I’m thinking about moving beyond just generating outputs and more into:

detecting patterns across incidents

identifying unstable services

highlighting teams with high escalation rates

correlating deployments with incidents automatically

Basically:

turning incident data into something you can actually act on

If you want to try it

👉 https://opsrift.com

No pressure — even quick feedback is super helpful.

Final note

I’ve worked in NOC/SOC and incident-heavy environments, so this is very much a “scratch your own itch” project.

That said, I’m aware tools like this can easily become:

too generic

inaccurate

or just another dashboard nobody uses

So I’d rather get honest feedback early.

Even if it’s:

“this doesn’t solve anything for me”

That’s useful.

Thanks in advance 🙌