The Pre-Build Interrogation Prompt is a companion resource to my article “Are You Sure You’re Actually Vibe Coding?”

Read the article first because this prompt only makes sense once you understand the difference between vibe coding, slop coding, spec-assisted building, and spec-driven development.

What The Pre-Build Interrogation Prompt Is

This prompt helps you apply that framework before a coding agent touches your project.

Use it when you you’re not yet sure whether the AI should start coding. Instead of asking the agent to implement immediately, you ask it to interrogate the idea first.

Use it before:

• Building a new feature

• Refactoring an existing flow

• Changing auth, payments, permissions, or data handling

• Asking an agent to edit multiple files

• Turning a vibe-coded prototype into something users will actually touch

• Moving from exploration into a more structured build mode

The prompt makes the agent inspect the existing project context, identify unclear requirements, surface hidden assumptions, map user roles and permissions, flag data model impact, find edge cases, assess security and privacy risks, estimate blast radius, define shippability criteria, and recommend tests before implementation.

In plain English: it stops the AI from confidently building the wrong thing.

The Pre-Build Interrogation Prompt

Copy and paste the prompt below into your coding agent before asking it to build, refactor, or change code.

Read more

Read this article first. This code is the companion resource.

Get The Code (Drop it on your site in 5 minutes)

Running live on productwithattitude.com since May 2026. This is the exact code, packaged.

The subscribe button that runs from your reader. Then converts them when they catch it.

The easiest and cheapest way to build this is to copy my code, and change three things:

1. the button text

2. the destination URL

3. the number of times the button dodges before it gives up (just remember that a button that runs forever is not fun anymore).

What’s Inside

runaway-button-kit/
├── README.md                          (you are here)
├── LICENSE.md                         single-site commercial license
├── src/
│   ├── runaway-button.html            clean HTML markup
│   ├── runaway-button.css             tokenized CSS, re-skin in 6 variables
│   └── runaway-button.js              vanilla JS, no dependencies
├── examples/
│   ├── dropin-single-file.html        one file, paste-and-ship
│   └── RunawayButton.jsx              React / Next.js component
├── docs/
│   ├── GA4-EVENT-SPEC.md              event names, params, Key Event setup
│   └── CUSTOMIZATION.md               re-skin, copy variants, behavior knobs
└── preview/
    └── index.html                     open in browser to see it work

Download Code Files

Read more

Read this article first. This code is the companion resource.

This is the exact prompt I used to ship the runaway button running at the on productwithattitude.com.

The Runaway Subscribe Button Prompt

Paste this into Claude, Claude Code, Cursor, Lovable, or any AI coding tool. Fill in the four [BRACKETED] placeholders. Out comes a working drop-in subscribe section with GA4 events, accessibility, and a button that dodges your cursor for exactly as long as you tell it to.

Read more

Thousands of builders wrapped a frontier model in their own UI, added a logo, and started selling subscriptions.

With vibe coding, all of that can happen in a day.

If you’re one of these builders, Article 3(3) of the EU AI Act made you the provider that day.

OpenAI, Anthropic, or Google still remain responsible for the general-purpose AI model they created. But you became responsible for the product you built on top of that model. And if your use case touched Annex III, you inherited every high-risk obligation in the regulation.

That’s the provider trap.

Builders, indie founders, and vibe coders are shipping fast, scaling faster, and stepping into the provider trap before they know it exists.

The way out is what I started calling compliance-native building.

What’s Inside

• What compliance-native building means.

• Why it beats compliance-by-design.

• The provider trap, broken down with the exact chat-wrapper scenario.

• A decision tree for am I in scope and at what risk tier.

• The dates that already passed, the date that matters, and the proposal that might move it.

• Penalties translated for founders.

• A 30-minute checklist for builders.

Compliance-Native Building, Defined

We had cloud-native. Then AI-native.

So when I needed a name for building regulation into the product itself, compliance-native made sense.

• Cloud-native made software scalable.

• AI-native made intelligence part of the product.

• Compliance-native makes regulation part of the build.

Compliance-native building treats the EU AI Act as a system constraint, not a paperwork tax.

You don’t build the product, then add compliance on.
You build the product so compliance is the default behavior of the system.

What it isn’t

It’s not compliance-by-design. That phrase is the consultant pitch. It often means someone sells you a framework, a risk register, and a recurring meeting.

Useful for enterprises with legal teams. Useless if you’re a one-person startup with zero budget and your “legal department” is you and ChatGPT.

What it is

You bake five behaviors into the product. The behaviors are the compliance. You document them once. You log them by default.

1. Classify first.
   Before you write code, decide what kind of AI system you are building: prohibited under Article 5, high-risk under Annex III, or limited-risk under Article 50. Write it down. Keep it in the repo.

2. Document as code.
   Your technical documentation and conformity assessment should live where the product lives. Same repo, same version history, same review process as a pull request.

3. Transparency by default. Always.
   Users should know when they are interacting with AI. If they’re talking to AI, or seeing AI-generated content, the interface should say so plainly.
   When the output is synthetic, Article 50 makes disclosure mandatory.

4. Logging by default.

   For high-risk systems, every decision needs a record. Who asked. What model responded. What output was generated. What happened after. Article 12 makes automatic logging mandatory, so don’t leave it for “later.” Later is where compliance tasks go to become expensive.

5. Sandbox first.

   Before you test high-risk behavior on real customers, use the regulatory sandbox. Article 57 requires each Member State to have at least one by 2 August 2026, with free priority access for SMEs.

These five behaviors are the compliance-native stack. The rest is documentation.

Share this with your vibe coder friend.

Share

The Trap That Catches Most Builders

Read more

TL;DR

This is a vibe coding resource hub for AI builders who want to ship real products, not just impressive demos. It collects 18+ practitioner-tested guides across vibe coding, spec-driven development, PRDs, debugging, cybersecurity, prompt systems, code blocks, and tool selection across Claude, Cursor, Lovable, Gemini, Replit, and v0.dev. Start with the reading path that matches what you are trying to build. Free readers get the map. Paid members get the build materials: prompts, code blocks, PRD templates, failure logs, and project structures behind the guides.

Every vibe coding guide teaches you how to generate an app.

This hub teaches you how to build one you can debug, secure, explain, ship and stand behind.

Pretty screens are cheap now. Judgment is not.

This vibe coding resource hub collects the guides, tools, prompts, workflows, and safety practices you need to build software with AI coding agents using natural language.

It treats vibe coding as product discipline: choosing the right tool, writing better specs and PRDs, debugging AI-generated code, securing apps before production, and shipping features that survive contact with real users.

Who This Hub Is For

Do I need coding experience to use this hub?

No.

You don’t need coding experience or technical background to use this hub. Curiosity is enough.

I’ve watched members with zero technical background automate their workflows, build systems and ship apps that save them and their teams hours per week.

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome! Here’s what you might have missed:

• Claude Design Review & Prompts

• 12 AI Projects Built by the PwA Community

• The Tools I’ve Built (and What’s Coming Next)

SUBSCRIBE

Start here:
Pick Your Goal, Then Follow the Reading Path

Best Vibe Coding Resources by Builder Goal

Tool directories, courses, GitHub lists, and definition articles are useful. They also leave a lot of “okay, but what do I do now?” hanging in the air. This hub is a field guide for turning AI-assisted development from scattered advice into repeatable product-building practice.

Resource Type Comparison Table

Foundations: What Vibe Coding Is

What is vibe coding?

Vibe coding is prompt-led software development: a way of building software by describing desired outcomes to an AI coding assistant, then testing, revising, and reviewing the generated code through an iterative conversation.

Vibe coding makes software creation more accessible by replacing some manual coding with natural language prompting. Its strength is speed. Its weakness is reliability. The best results come when vibe coding is paired with testing, version control, security review, and human product judgment.

Read the full 2026 guide:

Where did the term “vibe coding” come from?

The term vibe coding was coined by Andrej Karpathy in early 2025 to describe a highly conversational way of building software with AI. Instead of manually writing every line of code, the user explains what they want, reviews the result, and keeps prompting until the software behaves as intended.

I want a complete, end‑to‑end guide to vibe coding

Read The Ultimate Vibe Coding Guide From Builders Who’ve Shipped.

It’s a 16-step practitioner playbook covering the full arc from concept to shipped product.

What is vibe coding as a product-building discipline?

Vibe coding is the practice of building software by describing your desired outcome in natural language and iterating with AI until the product is ready.

The hard part is judgment. Knowing what to accept, what to reject, and when the AI is confidently wrong.

I built a dedicated interview series around that craft layer: the quality bar, the architectural calls, and the decisions that separate a shipped product from a shipped demo.

As a product-building discipline, it combines AI-generated code with human judgment, architectural thinking, engineering principles, and deliberate review.

The beginner mistake is treating a working screen as a working product. A product also needs requirements, authentication, data rules, edge-case handling, debugging, security checks, and a user who can break it in ways the demo never did.

Do I need to know how to program to vibe code?

No.

Vibe coding lowers the barrier to software creation because we can build with natural language prompts instead of traditional syntax.

This makes it useful for non-programmers who want to create prototypes, internal tools, scripts, landing pages, or simple applications.

However, the less code you understand, the more important it becomes to test, review, and verify the output. Vibe coding can help you build faster. It does not automatically make the result safe, scalable, or correct.

How is vibe coding different from traditional programming?

Traditional programming is code-first software development. Vibe coding is prompt-led software development.

How does vibe coding work?

Vibe coding usually follows an iterative loop:

1. Describe the outcome you want.

2. Let the AI generate the first version.

3. Test the result.

4. Describe what is broken, missing, or wrong.

5. Ask the AI to revise the code.

6. Repeat until the product works well enough to ship, test, or discard.

The strongest vibe coding workflows are structured conversations with the AI, guided by product judgment, testing, and clear constraints.

Can vibe coding be used for professional apps?

Yes.

Vibe coding can be used to build prototypes, MVPs, internal tools, automations, landing pages, and commercial software.

For professional applications, vibe coding works best when paired with engineering review, version control, testing, security checks, and clear product requirements. Larger companies usually need additional controls because AI-generated code must fit existing systems, compliance rules, architecture standards, and release processes.

Is vibe coding a real job now?

Not really. The valuable skill is AI-assisted product building: translating messy needs into clear specs, reviewing AI outputs, debugging, securing, and shipping.

Methods: Vibe Coding vs Spec-Driven Development

Which AI‑assisted coding method is best for me?

If you’re not sure which method fits you best, or want to understand the terminology before choosing a workflow - this will help:

What’s the difference between vibe coding and spec-driven development?

Vibe coding and spec-driven development sit at opposite ends of AI-assisted software engineering: vibe coding optimizes for rapid prototyping through conversational iteration, while spec-driven development optimizes for maintainability, reproducibility, and governance through formal requirements that guide AI-generated code before implementation starts.

Technical Concepts

What Is Context Engineering?

Context engineering is the practice of giving an AI system the right information, constraints, examples, tools, memory, and rules before asking it to do the work.

What is Prompt Engineering?

Prompt engineering is the practice of writing clear instructions that help an AI system produce a better answer, output, or action.

What is AI Agent Management?

AI agent management is the practice of directing, supervising, testing, and controlling AI agents as they perform multi-step work.

What is an IDE?

An IDE, or Integrated Development Environment, is the software workspace where builders write, edit, run, debug, and manage code. In vibe coding, an IDE often becomes the place where a human and an AI coding assistant work together to build, test, and fix a project.

What Is A Sandboxed Virtual Machine?

In this article, I explain the concept of a sandboxed virtual machine: visually, without jargon, and for beginners.

Subscribe now

Tools:
Choosing the Right Vibe Coding Stack

What tools do people use for vibe coding?

Common vibe coding tools include AI coding assistants, AI-native development environments, and conversational coding agents. Some examples:

• Lovable

• Claude

• Replit

• Gemini

• Cursor

• v0.dev

I use these tools differently depending on whether I’m prototyping UI, debugging production issues, writing specs, testing architecture, or trying to figure out why the app is buggy.

Which vibe coding tool is best for me in 2026?

A good vibe coding tool should match the way you think, the product you are building, and the amount of control you need. Replit, Cursor, Claude, Lovable, Gemini, and v0.dev can all be useful. They are not useful for the same reasons.

Share

What is the best free vibe coding IDE?

Replit, Cursor, VS Code with AI extensions, and Google AI Studio or Gemini-based workflows can all work. The right choice depends on skill level, stack, deployment needs, and whether you want a browser workspace, local editor, or AI-first app builder.

What is the best database for vibe coding?

The best database depends on the app.

Supabase or Firebase can work well for many beginner full-stack apps, hosted Postgres gives more control, and sometimes the correct database is no database yet because the product doesn’t need persistence. Future you will appreciate that restraint.

Where should I deploy a vibe-coded project if I’m choosing between Netlify, Vercel, Railway, and Supabase?

Don’t pick the platform first. Pick based on what your project needs. I wrote a practical decision tree for exactly this here:

Build Better:
PRDs, Prompt Systems, UI Prompts, and Code Blocks

Where can I find proven prompts for UI elements when I’m vibe coding?

Read 100 Most Common UI Elements For Vibe Coders.

It’s a practical reference of 100 UI components vibe coders regularly design, prompt, and ship, organized by type and use case. It’s best for builders working on frontend features and product interfaces.

How can I write better PRDs when I’m vibe coding so they catch problems early?

Use the guide Vibe Coding, But Smarter: The PRD Prompt That Audits Itself

It gives you a PRD Builder Prompt with built‑in self‑auditing for hallucinations and failure modes, so your requirements catch problems before the code does.

It’s best for vibe coders defining and validating product requirements before building.

How do I write rules for AI that work across Replit, Cursor, Lovable and Gemini?

Read Rules-For-AI Generator: A Beginner-Friendly System.
In this article, I share a custom generator system that helps your coding agent with product judgement.

Where can I find ready‑made code blocks?

Source Code: The Runaway Subscribe Button

The exact code running on productwithattitude.com, packaged so you can drop it on any site in under five minutes.

Valentine’s App 2026: Full Source Code

Full React source for the 2026 Valentine’s scratch card app. Annotated for readability.

Ship Safely:
Debugging, Cybersecurity, and Production

Is vibe coding risky?

Yes, if we ship generated code without review, security checks, authentication sanity, database rules, and failure testing. The risk is that the code looks finished before the product has been inspected.

Is vibe coding a trap?

It becomes a trap when we confuse a working demo with a reliable product. The way out is spec-driven development, review, testing, and shipping discipline. Very boring. Very useful.

How do I secure vibe-coded apps?

How do I ship vibe-coded products to production safely? What are the biggest security risks in vibe-coded apps?

Shipping to production is a different discipline than prototyping. The things that break when real users show up (security vulnerabilities, auth failures, looping agents, environment-specific edge cases) don’t surface during demos.

Every guide below is built from real product failures, not hypotheticals:

• Vibe Coding x Cybersecurity: The 2026 Builder Survival Guide
  It covers the seven most common security vulnerabilities in vibe-coded products, with a decision matrix for responsible shipping. AI-generated code passes syntax checks and fails security ones. Read before you launch, not after.

• Is Your Replit Looping? This Will Help.

  Covers how to diagnose looping behavior, context failures, and runaway agents. Includes specific prompts to stop the loop and recover the session. Best if you’re stuck in a debug spiral right now.

Real-World Tool Experience: Replit, Claude, and Perplexity

Claude and Perplexity live in dedicated knowledge hubs. Replit gets two failure-driven guides based on real product problems.

As for Replit, start with these two guides that came out of real product failures:

• I Broke Replit So You Don’t Have To

• Is Your Replit Looping? This Will Help.

After You’ve Built

Feedback and beta testers

If you’re looking for beta testers or product feedback, feel free to DM me. I’ve already helped many builders find early testers, get useful feedback, and put their products in front of the right people. I can do the same for you. I read every message.

Showcase on Product with Attitude

Congrats on the build! Drop it in our Wednesday Build Board. That’s when community members share their latest projects. I feature the best ones in showcase articles like What AI Builders Are Shipping in the PwA Community Right Now.

Showcase on StackShelf

Add it to StackShelf.app. It’s an LLM-optimized showcase built for Substack creators. Your build becomes discoverable by AI search engines and the broader community.

Community chat

If you’re looking to connect with other builders, our Community Chat is the best place to start.

References and Further Reading

These are useful external resources. I’m including them because they help map the broader vibe coding ecosystem.

• DeepLearning.AI: Vibe Coding 101 with Replit. A strong Replit-based course for agentic development, with a useful reminder that vibe coding is not one-shot prompting. Great for Replit, less complete across Claude, Cursor, Lovable, Gemini, PRDs, security, and community shipping.

• Figma: 10 Vibe Coding Tools for Building Better Experiences. A useful tool comparison for product and design teams choosing among modern AI coding tools. It helps you compare, not necessarily ship responsibly.

• GitHub: awesome-vibe-coding. A broad open-source list of vibe coding references and tools.

• Vibe Coding Learn: Vibe Coding Resource Hub. A concise resource category page with beginner-friendly framing. Useful, but generic. It doesn’t carry the same practitioner-tested shipping context.

Subscribe So You Don’t Miss Updates

WHY SUBSCRIBE ・YOUR BENEFITS・ TOOLS I BUILT・CLAUDE HUB・PERPLEXITY HUB ・VIBE CODING HUB

Your AI agent just told you it can’t open http://localhost:3000. Your app is running. Your browser sees it. The agent doesn’t.

When you spin up a project on your laptop, it lives at localhost:3000. That works fine for you. It does not work for your AI agent. The agent is not on your laptop. It’s somewhere else entirely: a cloud VM, a sandboxed process, a remote container. Different machine. Different “local.”

That’s the whole bug. And it has three fixes.

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome!

I maintain a library of free, community-built skills and prompts shared by our members in Attitude Vault.

SUBSCRIBE

And if you want to learn prompt engineering properly, start here: The Ultimate Guide to Prompt Engineering.

Why Your AI Agent Is Blind to Localhost

The Non-Techie Explanation

The word localhost means “this computer.”

It’s like both you and your AI agent saying “my house.”

You mean your house. The AI means its house.

So when you open localhost:3000, you are looking at the app running on your laptop.

But when the AI agent tries to open localhost:3000, it looks inside its own computer instead.

The error looks like your app is broken. It often isn’t. Your server may be running perfectly on your machine. The problem is that the AI agent is looking for it from a different environment.

The Exact Prompt to Send Your Agent

The localhost Diagnostic Prompt

Read more

Picking the wrong one wastes time. Picking the right one takes five minutes.

Note: This doesn’t cover self-hosting, AWS, or platforms that bundle hosting with the IDE (like Replit). Those are different decisions.

I’ve included a decision tree below, along with a super useful cheat sheet.

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome! Here’s what you might have missed:

• Claude Design Review & Prompts

• Substack Writer Tools

SUBSCRIBE

What’s Inside

• Where to deploy a vibe coding project in 2026.

• Netlify, Vercel, Railway, and Supabase compared.

• What each one does, what it costs, when to combine them.

• A decision tree, a platform comparison, and four stack combos by project type.

Read more

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome! Here’s what you might have missed:

• I Built a Runaway Subscribe Button. It Brought 70 New Subscribers in 6 Days. Code + Challenge Inside.

• Claude Design Review & Prompts

SUBSCRIBE

The One Prompt You Need Before Touching Code

Vibe coding is fast.

That’s actually the best part about it - seeing your product assemble itself in front of your eyes is thrilling, full of promise and a bit intoxicating.

Kind of like margaritas.

No wonder we want to skip ahead to that part.

But!

Before you touch a single line of code, you need these three steps. Skip them, and you’re signing up for wasted credits and lost time:

• A Product Requirements Document - blueprint

• Rules for AI - guardrails

• System prompts - context

Today, I’m going to walk you through the first one.

Why Bother?

I know. It sounds boring.

But hear me out: specs are how we turn AI experiments into products worth keeping. Fifteen minutes with this prompt can be the difference between building something brilliant—or brilliantly useless.

What Even Is A PRD?

💡 A Product Requirements Document (PRD) is your blueprint for building a product. It outlines:

• What you’re building

• Why it matters

• Who it’s for

• How you’ll know it’s done

It takes the messy soup of user needs, business goals, and technical constraints and turns it into one neat little document.

What Should A PRD Contain?

Whole books have been written about PRDs, and there are countless ways to create a “proper” one - but at the very minimum, a PRD should cover these areas:

The Journey Behind This Prompt

The PRD Builder Prompt you’re looking at is version 16, shaped by 15 rounds of sharpening.

In my work as a PM, I’ve written enough PRDs to know this:

• if they’re too long, nobody reads them

• f they’re too vague, nobody respects them

So I took everything I learned about product management discipline - clarity, brevity, testability - and combined it with everything I’ve learned about vibe coding.

The result: specs that are clear, brief, testable, precise, structured, and adaptable.

I hardened this in real projects (including Stackshelf) and refined it each time an agent misread, mis-executed, or tripped on contradictions.

The current version (v16!) is lean enough that AI can parse it without choking, and structured enough to stop it from wandering off.

How to Use The PRD Builder Prompt

Use this prompt only when you’re building actual products, not for demo apps.

It’s an advanced project prompt that generates a complete, implementation-ready PRD, ready to hand off to AI agent without further clarification.

1. Create a new Project in ChatGPT: Go to Projects → New Project → name it ‘‘PRD Builder’’.

2. Paste the Builder Prompt: this sets ChatGPT up as your virtual PM.

3. Generate Your PRD: Start a new chat: “Generate a PRD for…” + add your idea, feature list, or constraints.

4. Iterate & Refine: Answer clarifying questions, it’s important. The quality of your PRD depends on your clarity.

💡 Pro tip: include your user flows (a simple map of how users move through your product).

PRD Builder Prompt

# 📝 Karo's PRD Builder + Quality Check + AI Gap Scanner (Enhanced Edition, 188 lines).
Feel free to reuse with credit (https://karozieminski.substack.com/).


## ROLE
You are a **Principal Product Manager** and **documentation architect** trained in:
- **Karo's product methodology** (structured, testable, AI-agent ready)
- **Product storytelling style** (context-first, narrative-driven, customer-centered)

Your job is to:
1. Produce **clear, complete, and actionable PRDs**.
2. Ensure **context-rich narrative** for stakeholders.
3. Audit for **gaps, risks, contradictions, and assumptions**.
4. Make it **AI-agent safe** for automated execution.

---

## OBJECTIVE
Given my product idea or feature request, generate a **polished, implementation-ready PRD** that:
- Meets Karo's **Structural standards**.
- Embeds **Narrative and context-first framing** *(see style example below)*.
- Contains **measurable success criteria** and **testable requirements**.
- Flags **gaps, risks, and open questions**.
- Is **self-contained** for human or AI execution.

**Definition of success:**  
> “A PRD that can be handed to any qualified engineer, designer, or AI agent, and be implemented without further clarification.”

---

## STYLE EXAMPLES

**Before:**  
> “Improve onboarding.”

**After (Karo's PRD):**  
> “Given a first-time user signing up via mobile, reduce the average time to complete onboarding from 3m 45s to under 2 minutes by simplifying the form from 8 fields to 4. This change addresses the 42% drop-off at step 3 reported in April analytics and aligns with Q2 OKR #2 (Boost activation rate to 70%).”

---

## INPUT FORMAT
I will provide:
- Short product/feature description *(1–3 sentences or bullet points)*
- Target audience *(persona, role, or segment)*
- Known constraints *(deadlines, integrations, compliance rules)*
- Any available research, quotes, or data *(links or pasted content)*

**Acceptable formats:** plain text, bullet lists, or tables.  
If critical info is missing, **do not guess**—ask for clarification.

---

## STRUCTURE (Karo's Best Practices)

**0. Version & Ownership**
- Document version/date
- PRD owner
- Reviewers 

**1. Executive One-Pager**
- TL;DR: 5 bullets max (problem, goals, scope, success metrics, launch date)
- Plain-language summary for execs & non-technical stakeholders

**2. Overview & Context**
- Problem statement (why now?)
- Strategic alignment (OKRs, market trends, user pain points)
- Competitive / landscape snapshot

**3. Customer Insights & Evidence**
- Direct quotes from customers *(≥1 primary, ≥1 secondary source)*
- Data, charts, or anecdotes making the problem visceral
- Links to surveys, interviews, or analytics

**4. Goals & Non-Goals**
- Primary objectives
- Explicit non-goals to prevent scope creep

**5. Alternatives Considered**
- Solutions explored but rejected
- Why they were rejected

**6. User Personas & Use Cases**
- Persona summaries *(or “Not available” if none—do not fabricate)*
- Main use cases & jobs-to-be-done
- Pain points addressed

**7. Requirements**
- **Functional Requirements:** Detailed, numbered, linked to goals
- **Non-Functional Requirements:** Performance, security, compliance, accessibility
- **Acceptance Criteria:** Gherkin-style (“Given / When / Then”)

**8. UX & Design Considerations**
- Wireframe placeholders or design references
- Edge case handling
- Accessibility checklist (WCAG compliance)

**9. Technical Notes**
- System architecture impact
- Dependencies (internal & external APIs, 3rd party integrations)
- Data schema implications
- Future-proofing considerations

**10. Metrics & Success Criteria**
- KPIs, target values, measurement methods
- Metric ownership (who tracks it)
- Instrumentation requirements

**11. Risks & Mitigations**
- Known risks
- Impact severity (High/Med/Low)
- Mitigation plans

**12. Rollout Plan**
- Release phases
- Feature flag strategy
- Communication plan (internal + external)

**13. Decision Log**
- Key decisions made, with date & owner
- Links to related docs

**14. Success Story Narrative**
- Future press release or “happy path” story post-launch

**15. Open Questions & Assumptions**
- Pending decisions
- Research needed
- Explicit assumption list

**16. Glossary**
- Define all acronyms, jargon, or niche terms

---

## STYLE & TONE
- Clear, concise, unambiguous
- Actionable & testable
- Data-backed narrative
- Storytelling that makes the problem real
- Acronyms defined on first use
- No duplication of content across sections

---

## VERIFICATION CHECKLIST (Karo's Quality Checks)
1. **Completeness** – every section filled, requirements numbered
2. **Clarity** – no ambiguous terms, acronyms defined
3. **Actionability** – all requirements testable
4. **Feasibility** – dependencies & technical notes complete
5. **Risk & Edge Cases** – documented & covered
6. **Alignment** – every requirement tied to a goal
7. **Assumption Audit** – unstated assumptions flagged
8. **Accessibility Compliance** – checklist completed
9. **Evidence Rigor** – primary + secondary sources used
10. **No Contradictions** – flag conflicts between sections

---

## AI DETECTABLE GAPS SCAN
After creating the PRD, check for:
- Hallucination risk (vague terms, multiple interpretations)
- Data reference risk (no sources cited)
- Implicit logic risk (hidden steps)
- Ambiguous actor risk (unclear ownership)
- Conditional logic risk (missing edge case handling)
- Contradictions between sections
- Output clarity (AI can parse and execute without guessing)

Return an **AI Gap Report**:
- Risk level (Low/Medium/High)
- Recommended clarifications

---

## OUTPUT FORMAT
1. **PRD Document** – Markdown with clickable TOC & numbered requirements  
2. **Quality Check Report** – ✅ / ⚠️ / ❌ table for each verification category (ref checklist numbers)  
3. **AI Gap Report** – Risk level + recommendations

---

## NEXT STEP
Ask **all clarifying questions first** before producing the PRD.  
If unclear, request more detail rather than making assumptions.

---

## MODES
- **Full Mode** – All sections included (default)
- **Lite Mode** – For small features (skip Personas, Decision Log, Alternatives unless relevant)

From Vibe coding To Spec-Driven Development

If you’ve read my work before, you might have noticed that it was never just ‘‘vibes ‘‘ (oof, I dislike that word soooo much).

From the start, my prompts came with audits, checks, and built-in safety rails - always versioned and documented. (Like this one: The Self-Improving Prompt System That Anyone Can Rock)

Looking back, I was already closer to GitHub’s idea of spec-driven development than pure vibe coding.

And that’s where I’m headed next. I’ll be sharing this journey with you - what works, what breaks, and what I discover along the way.

More Prompts, Skills, and Community-Built Resources

I maintain a library of free, community-built skills and prompts shared by our members in Attitude Vault.

SUBSCRIBE

And if you want to learn prompt engineering properly, start here: The Ultimate Guide to Prompt Engineering.

The cybersecurity critics of vibecoding are right about the risks.
They’re just wrong about the solution.
The answer isn’t “don’t vibecode at all.”
It’s “vibecode responsibly, with solid engineering foundations.”

If you’re new here, welcome! Here’s what you might’ve missed:
Vibecoding Tips: The Ultimate Collection
Claude Skills Are Taking the AI Community by Storm
10x Your Productivity with Perplexity Comet: 11 Use Cases from “Nice” to “Wow!”

Join us 🤗

The cybersecurity critiques of vibecoding are valid.
So instead of debating them, I partnered with an expert to map the absolute minimum you need to consider when coding with AI.

Today’s guide was authored by the brilliant , a Data Engineer specializing in cybersecurity. I met Farida here on Substack. She’s one of those rare writers you follow after one post, and for me, that post was this one: There’s No Real Money in AI Business, Just Rented Dreams and Delusional Valuations.

We’ve also included a bonus commentary from , a cybersecurity expert specializing in critical infrastructure.

Together, we’ll show you how to vibecode fast and securely, with practical examples, and a minimal security checklist you can actually follow.

Who This Guide Is For

You should read this if:

• You’ve read the Ultimate Collection of Vibecoding Tips.

• You use AI to generate code.

Enjoy!

Vibecoding Meets Cybersecurity: Notes from the Expert Who Fixes Your Code After You

I build data pipelines and analytics tools, often at speed, sometimes at 2 AM when inspiration strikes. I’ve also cleaned up security incidents that started with “I just needed to test something quickly.”

That tension between moving fast and staying secure isn’t theoretical for me, it’s the daily reality of building with data.

Vibecoding is often done based on intuition and speed rather than meticulous planning. You describe what you want, the AI generates working code, and within minutes you have a functioning app.

It’s powerful, addictive, and without guardrails - dangerous.

The question is how to vibecode without leaving vulnerabilities behind.

The Five Quiet Failures

Vibecoding doesn’t fail with sirens and red alerts. It fails quietly, in ways that don’t surface until a security review.

1. Prompt Leakage

⚠️ The problem: Accidentally sending production credentials to a third party.

🧐 Scenario 1:
You’re debugging a failed connection and paste this into ChatGPT:

Help me debug: 
Error: Connection failed
postgresql://analytics_user:zK7$mP2024@prod-db.company.com:5432/customers

Congratulations, you just sent production credentials to a third party.

🛠️ How to fix: Always scrub before sharing.
Scrubbing = removing sensitive information before you share data.

🧐 Scenario 2:
You’re trying to retrieve all the data for a customer from your database, but it doesn’t work.

❌ BAD: Pasting real data into AI chat
Why doesn’t this work? SELECT * FROM customers WHERE email=’john.doe@realcompany.com

✅ GOOD: Use synthetic data for debugging
Why doesn’t this work? SELECT * FROM customers WHERE email=’user1@example.com’

2. Over-Permissioned Prototypes

⚠️ The problem: AI generates code that works immediately by requesting broad permissions.

🧐 Scenario:
You’re trying to read the entire users table from the PostgreSQL database called customers for analysis, monitoring, or to display in your app.

import psycopg2

conn = psycopg2.connect(

“postgresql://admin:temp123@prod-db:5432/customers”

)

cursor = conn.cursor()

cursor.execute(”SELECT * FROM users”) # All columns, all rows

rows = cursor.fetchall()

cursor.close()

conn.close()

What’s wrong:

• Admin credentials in code

• Full table access when you only need recent records

• Production database accessed from development code

• No credential expiration or rotation mechanism

🛠️ How to fix:

📒 Real incident: A colleague’s Airflow DAG had database admin credentials “for testing.” When the DAG failed, those credentials appeared in our centralized logging system visible to everyone with log access.

3. The Prototype That Never Dies

⚠️ The problem: Internal tools are often left unsecured, creating serious vulnerabilities.

🧐 Scenario: You build a “quick internal dashboard” with no authentication. Three months later, it’s been bookmarked, shared in Slack, and someone’s accessing it from airport WiFi.

Reality check: “Internal only” is a wish, not a security control.

4. Unverified Dependencies

⚠️ The problem: Installing dependencies without checking if they’re safe or updated.

🧐 Scenario: AI suggests installing pandas, sqlalchemy, data-utils, query-helper. You install without checking. Three are legitimate. One was abandoned in 2020 with critical vulnerabilities.

🛠️ How to fix: Run a quick safety check:

pip show package-name # Check last update date and info

pip-audit # Scan installed packages for vulnerabilities

5. Hidden Credential Persistence

⚠️ The problem: Test tokens often outlive their purpose, quietly spreading across tools and repos until they become full-blown security leaks.

🧐 Scenario: Your test API token is now living in:

• Slack messages where you asked for help

• Log files from three months ago

• Clipboard manager history

• .bash_history

• Jupyter notebooks committed to Git

🛠️ How to fix: Set aggressive expiration times. If it’s for testing, one hour is plenty.

📒 Case Study: The Dashboard That Worked Too Well

A colleague vibecoded a support ticket dashboard using Claude. From idea to working prototype: two hours.

from flask import Flask, jsonify

import psycopg2

app = Flask(__name__)

@app.route(”/api/tickets”, methods=[’GET’])

def get_tickets():

conn = psycopg2.connect(”postgresql://readonly:pass123@db:5432/support”)

cursor = conn.cursor()

cursor.execute(”SELECT * FROM support_tickets”)

tickets = cursor.fetchall()

cursor.close()

conn.close()

return jsonify(tickets)

if __name__ == ‘__main__’:

app.run(host=’0.0.0.0’, port=5000) # Accessible from anywhere

Clean. Simple. Fast. The team loved it.

Within one week:

• 3,000+ tickets exposed: including customer credit cards and internal complaints

• No authentication: anyone with the URL could access it

• No access control: every user saw every ticket

• Hardcoded credentials in source code

• No audit trail: we couldn’t track who accessed what

How We Found Out:
Our security team discovered it during a routine audit. We were lucky. The potential GDPR violation could have resulted in fines of €20,000-€200,000 based on similar incidents.

🛠️ How to fix: Use better, more secure prompts. See A Minimal Flask API Template That Actually Protects You.

The Lesson

Speed amplifies assumptions. AI gave us exactly what we asked for: an endpoint that returns tickets. But it didn’t know:

• Tickets contain sensitive data

• Users should only see their assignments

• Access should be authenticated and logged

The fix took 30 minutes. The potential damage would have taken months to recover from.

Better Prompts = Better Security

The fastest way to secure vibecoding is better prompts.

Example 1:

❌ Vulnerable Prompt

“Create a Flask API that returns user data from PostgreSQL”


✅ Secure Prompt

“Create a Flask API that returns user data from PostgreSQL with:

- Environment variables for database credentials (using python-dotenv)

- Basic HTTP authentication with password verification

- Role-based access control (admin sees all users, regular users see only their data)

- Parameterized queries to prevent SQL injection

- Audit logging for all data access

- Return only necessary columns (id, email, created_at), not full records

- Proper connection closing to prevent resource leaks”

Example 2:

❌ Vulnerable Prompt

Write an Airflow DAG to sync user data daily.


✅ Secure Prompt

Write an Airflow DAG to sync user data daily with:

- PostgresHook for credential management (no hardcoded passwords)

- Incremental sync using last_modified timestamp (only records changed since last run)

- Read-only database connection with minimum required permissions

- Error handling with exponential backoff retry logic

- Data validation before insert (check for required fields, data types)

- Logging that doesn’t expose PII (log row counts, not actual data)

- Connection pooling with proper cleanup

Four Essential Security Tools

1. Pre-Commit Security Scanning

Tools:

• bandit - scans Python code for security issues like hardcoded passwords, SQL injection, and insecure random number generation.

• pip-audit - checks your installed packages against a database of known vulnerabilities.

Example use:

# Install security tools once

pip install bandit pip-audit sqlfluff

# Run before every commit

bandit -r . -x ./venv,./tests # Find hardcoded secrets, SQL injection patterns

pip-audit # Check for vulnerable dependencies

sqlfluff lint . # Validate SQL queries (if you have .sql files)

2. Credential Management

🛠️ Tools:

• .gitignore - this is a file that tells your project which files or folders should be left out when you save or share your work using Git.

👇 Example:

# .env file (MUST add to .gitignore!)

DATABASE_URL=postgresql://localhost:5432/dev_analytics

API_KEY=sk-test-development-only

ENVIRONMENT=development

# Your Python code

import os

from dotenv import load_dotenv

# Load environment variables from .env file

load_dotenv()

# Validate required secrets exist

required = [’DATABASE_URL’, ‘API_KEY’]

missing = [var for var in required if not os.getenv(var)]

if missing:

raise ValueError(f”Missing required environment variables: {missing}”)

# Access credentials safely

DATABASE_URL = os.getenv(”DATABASE_URL”)

API_KEY = os.getenv(”API_KEY”)

3. Synthetic Data for Testing

🛠️ Tools:

• faker - Faker is a tool that creates fake, but realistic-looking data for testing

👇 Example:

from faker import Faker

import pandas as pd

fake = Faker()

def create_test_data(rows=1000):

“”“Generate synthetic data - never use production data for testing”“”

return pd.DataFrame({

‘user_id’: range(1, rows + 1),

‘email’: [fake.email() for _ in range(rows)],

‘name’: [fake.name() for _ in range(rows)],

‘created_at’: [fake.date_time_this_year() for _ in range(rows)]

})

# Use for all development and debugging

test_df = create_test_data()

print(f”Created {len(test_df)} test records”)

4. Automated Pre-Commit Hook

From Karo: An automated Pre-Commit Hook is a small script that automatically runs checks every time you try to save your changes in a coding project.

Save your file in the right spot, as .git/hooks/pre-commit, and tell your computer it’s allowed to use it whenever you save your work (chmod +x .git/hooks/pre-commit).

#!/bin/bash

set -e # Exit on first error

echo “Running security checks...”

# Check for credentials in staged files

if git diff --cached | grep -E “password|api[_-]?key|secret|token” -i; then

echo “❌ Possible credentials detected in staged files!”

echo “Remove credentials and use environment variables instead.”

exit 1

fi

# Check for data files that shouldn’t be committed

if git diff --cached --name-only | grep -E “\.csv$|\.xlsx$|\.db$|\.sqlite$”; then

echo “⚠️ Data files detected. Continue? (y/n)”

read -n 1 -r

echo

[[ ! $REPLY =~ ^[Yy]$ ]] && exit 1

fi

# Verify security tools are installed

command -v pip-audit >/dev/null 2>&1 || {

echo “❌ pip-audit not installed. Run: pip install pip-audit”;

exit 1;

}

command -v bandit >/dev/null 2>&1 || {

echo “❌ bandit not installed. Run: pip install bandit”;

exit 1;

}

# Run security scans on Python files

if git diff --cached --name-only | grep -q “\.py$”; then

echo “Running pip-audit...”

pip-audit --quiet || exit 1

echo “Running bandit...”

bandit -r . -q -x ./venv,./tests || exit 1

fi

echo “✅ Security checks passed”

The Minimal Security Checklist

Note from Karo: If you’re not familiar with the term “commit”, this free guide will help.

1. Before Your First Commit

• Create .env with all credentials

• Add .env to .gitignore

• Verify git status (should NOT show .env)

• Replace any hardcoded credentials with os.getenv()

2. Before Every Commit

• Run: bandit -r . -x ./venv

• Run: pip-audit

• Search code for: password, api_key, secret, token

• Always review AI-generated database code to make sure it can’t be abused, and use safe techniques (like parameterized queries) to protect your data.

3. Before Sharing Internally

• Add authentication, even for “internal” tools

• Implement role-based access control

• Add audit logging for data access

• Test with synthetic data only

4. Before Production

• Security review by second person

• Apply least-privilege to all database roles

• Set up monitoring and alerting

• Remove all debug code and print statements

• Document what’s NOT secured yet

• Test credential rotation procedures

When to Vibecode (Decision Matrix)

Not every build is vibecode-friendly. Here’s how to know when to roll with it, and when to step back.

Some additions from Karo:

• Use AI coding tools for standard patterns and boilerplate, not for architectural decisions or innovation.

• Keep human oversight for any critical or novel tasks.

Resources Worth Bookmarking

• Security scanning

  • bandit – Scans Python code for common security flaws before they reach production.

    • 🎓 Official docs

  • pip-audit – Checks your project’s dependencies for known vulnerabilities and outdated packages.

    • 🎓 Official docs.

  • sqlfluff – Lints and formats SQL to catch risky queries or style issues early.

    • 🎓 Official Docs

• Credential management

  • python-dotenv – Loads environment variables from a .env file so you never hardcode credentials.

    • 🎓 Official Docs

• Testing data

  • faker – Generates realistic fake data for testing without exposing real user info.

    • 🎓 Official Docs

  • mimesis – Another synthetic data generator, with more localization and domain-specific options.

    • 🎓 Official Docs

• Pre-commit hooks

  • .git/hooks/pre-commit – Runs automated checks (like linting or tests) before you can commit, enforcing safety and consistency at the source.

  • 🎓 Official Docs

The gaps are probably your next security vulnerabilities. Fill them before someone else does.

Bonus: Skeptics, Builders, and Pragmatists: The Three Roles Every Product Team Needs

From Karo:

While researching this piece, I reached out to several experts. One of them, , asked to stay anonymous due to their work in critical infrastructure systems.

When we first talked, said something along the lines of, “I’m too skeptical for this piece.”

Perfect. That’s exactly who we needed.

If we’re going to learn anything real, we need this friction.

• Optimists show us what’s possible,

• Skeptics reveal the cracks that make it dangerous,

• Pragmatists bridge the gap between the two.

’s words below:

The Hidden Security Risk: Untested Functionality

There’s a more insidious risk that emerges from vibecoding’s accessibility: the absence of systematic testing creates a blind spot where functional bugs become security vulnerabilities.

Many vibecoding practitioners lack formal software engineering backgrounds and may not instinctively think in terms of test-driven development, code coverage, or quality assurance pipelines.

This gap is particularly dangerous because a subtle logical error (an off-by-one error in permission checking, or incorrect data validation that passes superficial inspection) can create exploitable weaknesses that are far harder to detect than obvious security anti-patterns.

Take medical applications as an example. The yoga injury app that provides incorrect treatment guidance isn’t just a UX problem, it can cause real harm.

In regulated industries, that harm carries legal liability equivalent to a data breach.

1. Addressing The Gaps Through Prompt Engineering

Prompting can bootstrap a testing culture even among those unfamiliar with these concepts:

Examples of what to ask the AI to explicitly request test generation alongside implementation.

# Example 1
Write unit tests covering edge cases, error conditions, and security-relevant boundaries.

# Example 2
Generate property-based tests for input validation.

# Example 3
Apply test-driven development approach: write failing tests first, then implement.

# Example 4
Include integration tests that verify security controls  actually prevent unauthorized access.

2. Addressing The Gaps Through Better Tooling

However, prompts alone aren’t sufficient. The ecosystem needs better tooling that makes testing unavoidable rather than optional.

This could involve:

• AI coding assistants that refuse to mark a feature “complete” without accompanying tests.

• AI coding assistants that automatically generate test stubs that developers must either implement or explicitly skip with justification.

For LLM-integrated applications, where behavioral predictability is inherently limited, the testing challenge intensifies.

You need not just unit tests but also validation frameworks that check for hallucinations, prompt injections, and unexpected model outputs.

The security community should advocate for treating test coverage as a security control itself. Confidence in your application’s correct behavior under all conditions is the foundation upon which all other security measures rest.

Final Thoughts

Before you accept AI-generated code, ask:

Before You Accept AI-Generated Code, Ask Yourself:

1. Who can access this?
Only authenticated, authorized users should have access. Never assume “internal” means secure.

2. Is there an audit trail?
There must always be a verifiable way to track who did what, when, and from where.

3. What data is exposed?
Expose only the minimum required information. Every extra column, log, or debug printout is a potential liability.

4. Where are the credentials?
They belong in environment variables, secret managers, or vaults: never in code, configs, or chat prompts.

5. What happens if this leaks?
Design for failure. Assume credentials will leak and make sure the blast radius is minimal: short-lived tokens, read-only roles, and clear rotation policies.

6. What’s untested?
Every untested function is a potential vulnerability. Tests aren’t just about correctness, they’re a security control.

7. Does it fail safely?
When things break (and they will), does the system fail closed or fail open?
Failing open is convenient - until it’s catastrophic.

The 30 minutes you invest in security now will save you 30 hours of incident response later.

Additional Resources

• Best Vibecoding Guides & Prompts

• Prompt Pack: 100 Most Common UI Elements For Vibecoders

• PRD Template and Self-Auditing Prompt

• GitHub Setup for Complete Beginners

You Might Also Enjoy

Vibecoding Our Way to a Breach by
Vibecoding + Cybersecurity: The Good, The Bad, and The Ugly by
Human in the Loop: Before it’s Too Late by
How Attackers Are Using TikTok Videos by
Tricking ChatGPT to Silently Steal User Emails by
AI in Cybersecurity: Benefits, Strategies & Future Trends by
Vibecoding Conundrums by
Secure Vibecoding: Level Up with Cursor Rules and the R.A.I.L.G.U.A.R.D. Framework by

Community Updates

👉 won Silver in the 2025 Moonbeam Children’s Book Awards for Best Writer/Illustrator!

🚀 StackShelf is buzzing with new launches:

• : free Gmail Signature Generator and an AI Prompt Manager extension

• : three free Machine Learning guides

• : Substack Accelerator Kit

• : Engineering Leadership coaching session

• : ‘“Fear Enough” book

• - free automations for Substack writers

Join hundreds of Premium Members and unlock everything you need to build with AI. From prompt packs and code blocks to learning paths, discounts and the community that makes it so special.

SUBSCRIBE 🤗

WHY SUBSCRIBE ・LEARNING PATHS・ PREMIUM RESOURCES・ TOOLS ・TESTIMONIALS ・LIFETIME MEMBERSHIP

TL;DR: Build production-ready apps with AI coding tools by following this practical roadmap: validate your idea early, design user flows first, choose the right stack, write clear prompts, use Git from day one, debug systematically, and keep learning fundamentals.

If you’re wondering how to get from your idea to a finished AI-powered product, this guide has you covered.
We map every step - from concept to live deployment - based on real projects we’ve shipped. We share a playbook that’s been tested, improved, and proven with real results.

Hey, I’m Karo 🤗

AI product manager, builder of StackShelf.app, and chronic optimizer of workflows. If you’re new here - welcome! Joining me is , a fellow builder and founder of CarouselBot. We met on Substack, where her energy is undeniable. From her writing, it’s clear: she’s a builder unafraid to question everything and constantly refine her workflows.

From Karen:

I discovered Substack through Karo’s incredible Product with Attitude Community, and somehow she became one of my first five subscribers. I’m in awe of her ability to bring people together while building her own projects and running a best-selling newsletter!

Table of Contents:
1. Start With the Right Mindset
2. Validate Before You Build
3. Map User Flows First
4. Choose Your Stack
5. Craft Solid Prompts
6. Write Your PRD
7. Create Rules for Your AI
8. Set Up Version Control
9. Organize Your Docs
10. Secure Your Sensitive Data
11. Backup Your Database
12. Build in Small Slices
13. Debug Systematically
14. Test Before Shipping
15. Control Your Costs
16. Keep Learning
Final Thoughts

1. Start With the Right Mindset

Building product-grade apps no longer requires knowing how to code. Modern AI tools are skilled enough to win coding competitions, and it’s fair to consider them a top-tier teammate.

Still, even top-tier AIs need direction - and that’s your role in the process. You wear every hat: designer, director, builder, product lead, and marketer.

Don’t skip the hard parts of product development. You’re still responsible for:

• Vision: What are you building and why?

• Design: How should users move through your app?

• Decisions: Which features matter? What can wait?

• Quality: Does it work? Is it secure?

Before you start coding: Have a concrete idea. Not just “a social app” but “a tool that lets Substack book clubs vote on their next read.” This will help you choose the right tools and write better instructions.

2. Validate Before You Build

How to validate fast:

• Talk to humans first: Get feedback before writing a single line of code.

  Join our community to test your ideas, show mockups, or run small experiments.

• Brainstorm with AI: This takes 1-2 hours and can save you weeks of wasted work. Ask questions like:

  • What user flows should I consider?

  • What are the edge cases?

  • What features should I start with?

Tip: Brainstorm with whichever AI you find easiest to use. I go with ChatGPT; Karen uses Claude.

3. Map User Flows First

Before asking AI to write any code, map out how users move through your app.

Use any tool: Miro, Figma, pen and paper - doesn’t matter. Just sketch:

• Login → Dashboard → Main Feature → Settings → Logout

• What happens when they click “Submit”?

• What appears on success? On error?

• Where do they go next?

Why this matters: Catching confusing paths on paper is 100x easier than fixing them in code later.

4. Choose Your Stack

There are so many AI-assisted coding tools available, that the only rational response is a kind of gentle, throbbing migraine. To make the choice easier, follow this rule of thumb:

We also want to show you that tool choice is flexible and there are multiple valid paths to a solid build. Our stacks aren’t the same, yet both lead to working, well-maintained releases:

From Karen:

Reading Karo’s list was educational, and comparing hers with mine shows that you can follow roughly the same process, and get good results, even while using an (almost) completely different toolset.

You’ll also notice that my list is a whole lot longer. That’s because Replit is an “all-in-one” creation tool that handles a lot of elements, like databases, domain management, and even hosting for production. Overall, I think Karo’s stack is by far the better bet for someone who just wants to ship their project and doesn’t want to get too deep into the technical details.

Although my toolset could work for anyone, it requires a bit more research upfront, and no small amount of patience. But it should be a good fit for anyone who’s really curious about what’s going on “under the hood” of their application.

Both approaches work. Two builders, two different stacks, both shipping real products. Pick what matches your learning style and timeline.

5. Craft Solid Prompts

AI is great at pattern recognition, but terrible at mind reading.

That’s why prompt crafting matters.

• Learn the different prompting techniques used in AI-assisted coding.

• Always provide context

  ❌ Registration form doesn't work.
  ✅ The user clicked ‘Submit’ on the registration form, but nothing happened, there was no redirect, no confirmation, no user-facing message. Here’s the error from the console: [paste error]

• Be specific about what to change:

  ❌ Fix the login page.
  ✅ In login.jsx, modify the email validation to accept plus signs (+) in email addresses. Don’t change any other files.

• Use negative instructions: Tell AI what NOT to do to prevent drift.

  ✅ Investigate only - what causes problem A to occur? Do not change any code, output a complete report.
  ✅ Avoid using library X.

• Treat your prompts like source code: name them, save them, version them. Over time you’ll develop a library of prompts that work well, and even a prompt graveyard so you can remember what didn’t work and why.

• Try prompts from other builders and make them your own: feel free to grab some well-tested prompts from here.

  

6. Write A PRD

The Product Requirements Document (PRD) is a clear document that describes:

• What you’re building: Core functionality + target user + problem solved

• Key features: Features you want right away + Features that can wait

• Technical requirements: What technologies or frameworks to use, what services to integrate, any performance or security needs

Pro tip: Ask AI to help you write and review your brief for gaps. Here’s how:
The PRD Prompt That Audits Itself For Hallucinations and Failure Modes

7. Create Rules for Your AI

You’ll see Rules for AI under different names: replit.md, agents.md, constitution.md - but the purpose is the same - to give your coding agent a playbook.

• What to do:

  • Tech stack decisions

  • Coding standards

  • Folder structure

  • Naming conventions

  • Design style

• What NOT to do:

  ⛔️ Don’t make any changes without understanding what files are affected
  ⛔️ Don’t modify the authentication system
  ⛔️ Don’t change the database schema without migration files

Pro Tip: Treat this file as a living document and update it as you learn what works for your project.

Why this matters: AI can “forget” decisions from earlier in your conversation. This document prevents you from constantly re-explaining preferences and stops AI from undoing your work.

Side note: I’ll publish a deep dive soon; if you need help now, leave a comment and I’ll share the draft.

8. Setup Version Control in GitHub

Think of GitHub as a giant online folder for your project where every change you make is saved, tracked, and easily shared. It’s like “Google Docs for code’’.

If you’re just starting out, my super simple free GitHub Guide for Beginners will get you set up fast.

Essential GitHub Habits

• Start on Day 1

  • Create a repository the moment you begin coding

  • Every change is tracked; you always have a safety net

• Create branches for features

  • Main branch = your working product

  • Feature branches = experiments and new work

  • Example names: feature/login, bugfix/password

• Merge branches only after testing

  • Always test and review code before merging changes into your main project. This catches bugs early and helps keep your project stable and maintainable.

• Commit often

  • Save after completing each small piece (a button, a fix)

  • Don’t wait until the end of the day.

👉 Need help? More details in this guide.

9. Organize Your Docs

Clear organization means less time searching, more time building.

• Know exactly where everything is:

  • the code files

  • the specs

  • your top prompts

• Use consistent naming:

  • for your folders

  • for your files

• Document learnings from your interactions with the agent:

10. Secure Your Sensitive Data

Two safe approaches:

• Option 1: Environment variables

  • If you’re working with a Python framework, you can store your sensitive information in an .env file saved to your project’s root directory.

  • Add it to .gitignore so it’s never uploaded

• Option 2: Built-in secrets management

  • If you’re using Replit, you can set up sensitive variables using its Secrets tool. Replit automatically encrypts this information, and secures it so it won’t be made visible in your app or its code.

Why this matters: Keys in code can be scraped, stolen, or accidentally shared. One leaked API key can cost you thousands in fraudulent usage.

11. Backup Your Database

We’ve all heard stories about agents going rogue and deleting databases. Your customer data, your product images - everything can disappear in a single click. But this can be easily prevented:

12. Build in Small Slices

Don’t: Ask AI to build an entire feature from database to UI in one go

Do: Break features into small, end-to-end slices

Example: Building a Login Feature:

❌ Large task (risky):
“Build the complete authentication system with login, registration, password reset, OAuth, and security”

✅ Small slices (safer):
“Create a basic login form with email and password”
“Add backend validation for the login form”
“Connect login form to database to verify credentials”
“Add error messages for wrong password”
“Test and deploy”

Why this works:

• AI makes fewer mistakes on smaller tasks

• You catch problems earlier

• Bonus: you also build your confidence with frequent wins

  

13. Debug Systematically

When you get stuck with a bug, don’t panic! Follow a process:

Step 1: Document the Bug

• Take notes that will help make bugs reproducible: What happened? When?

• You can use the Given-When-Then framework, or a different one, as long as you and your agent will be able to understand what happened.

  GIVEN: User is on the login page.
  WHEN: User clicks on login button.
  THEN: Button is not working.

Step 2: Fix One Bug at a Time

Don’t try to fix multiple issues simultaneously. Isolate, fix, test, move on.

Step 3: Watch for Silent Bugs

AI often adds “failover logic” that hides errors:

From Karen:

Sometimes, code you’ll get back from AI will include failover logic to ensure that, if one thing breaks, the whole system won’t crash. Failover code might run a function that’s not quite as good as the main one (e.g., keyword search instead of semantic search) or generate a vague error message.

While implementing failover logic is a great idea for production environments, so the user experience isn’t disrupted more than necessary, it can also make it harder to detect bugs. If you have failover code, you may want to comment it out during development, so you see a big, glaring error message instead of a feature that “sort of” works.

Step 4: Ask AI to Diagnose

Provide:

• Error logs

• What you expected vs. what happened

• Relevant code snippets

Step 5: The Three Strikes Rule

If AI can’t fix the bug after three attempts:

• Roll back to your last working version (thank you, Git!)

• Ask a different AI model to review the code

• Example: If you’re using Claude, switch to ChatGPT for a fresh perspective

Step 6: Expect Looping

Sometimes AI breaks one thing while fixing another: fix → break → fix → break.

Solution: Roll back and try more specific prompt. I shared one in this post: Is Your Replit Looping? This Will Help

Step 7: Ask for Help

Join builder communities!

I’ve had tremendous support on StackShelf; in emergencies and from people generously testing features. If it wasn’t for the moral support from , I’d spend my holidays crying into a pillow.

From Karen: If you post about your development projects on social media (and, yes, that includes Substack), invite your readers to help test them. Some of them will DM you! Your comments can also point you towards people who might want to be part of your project. If they leave a comment like, “Wow, I’d love a tool like that!” consider following up with a DM with a link to your tool and how they can provide feedback if they’re interested. This is how I found 91 (and counting!) people to beta test StackDigest...and I’m still implementing their feedback.

14. Test Before Shipping

Human Testing

• Internal testing: You and your team test every feature

• Beta testing: Recruit 5-10 real users to try it

• Focus on core flows: Can users complete the main tasks?

Agentic Testing

Some tools (like Replit Agent 3) can systematically test your code for:

• Silent failures

• Edge cases you didn’t consider

• Regressions (new code breaking old features)

Your role is to build in review cycles, monitor results, and never hesitate to cross-check with different models if outcomes seem off.

15. Control Your Costs

Use separate API keys per project:

• One broken request won’t drain your entire budget

• You can track costs per project

Edit minor things manually:

Don’t waste credits on:

• “Make this headline shorter”

• “Change the button color to blue”

Choose the right model for the task:

• Complex architecture decisions: Use the smartest model

• Simple bug fixes or styling: Use faster, cheaper models

Know your pricing model

• Some tools (like Claude Code) are cheaper with a subscription than API usage

  

16. Keep Learning

AI can help you build without knowing how to code, but understanding the basics makes you dramatically more effective.

From Karen: I like the idea of being able to understand how my app is working behind the scenes and fix it (or, at least, give good direction to AI), when things go wrong. And the more you know about the coding languages used in your project, the better you will understand what you are building.

Why learn coding fundamentals:

• You’ll write better prompts

• You’ll spot bugs faster

• You’ll understand AI suggestions better

• You’ll know when to override them

What to learn:

• For web apps: HTML, CSS, JavaScript basics

• General concepts: How databases work, API basics, authentication

How to learn:

• Ask AI to explain code it wrote for you

• Read documentation for tools you’re using

• Build custom learning paths for yourself with ChatGPT or Perplexity

• Follow tutorials for your specific stack

Final Thoughts

The most successful builders combine AI’s speed with engineering basics and human judgment:

• AI suggests, you decide

• AI implements, you verify

• AI optimizes, you maintain the vision

Start small, ship often, and keep learning. Every project makes you better at directing AI and better at understanding what you’re building.

said it best:

Ready to Start?

Pick one small project idea, work through this guide step by step, and ship something real. Then do it again, a little faster and better each time.

Additional Resources

• Claude Design Review & Prompts

• 100 Most Common UI Elements For Vibecoders

• Vibecoding x Cybersecurity: Survival Guide by the Expert Who Fixes Your Code After You

You Might Also Enjoy

Vibe by
Build a Website with Claude Code: Payments, Email, SEO & More by
Vibe engineering by
Vibe coding a genome by
A Security Vibe Check by
The Future of Vibe Coding by
The Past and Future of Vibe Coding by
From idea to prototype with AI by
Don’t vibe code your config: How I shot myself in the foot by

WHY SUBSCRIBE ・YOUR BENEFITS・ TOOLS I BUILT・CLAUDE HUB・PERPLEXITY HUB ・VIBE CODING HUB

SUBSCRIBE

A huge thank you to everyone who read, commented on, and shared my last post!

Subscribe now

At first, I didn’t even tell anyone I ‘‘vibecoded’’.

The name itself feels like a joke, easy to dismiss. I also prefer to unpack things on my own without being swayed by others’ opinions.

Now I can say this with confidence: vibecoding isn’t a joke. It lets you ship real, product-grade apps.

Not your company’s ERP system, sure.
But if you’re an enterprise PM, it’s the one skill you don’t want to ignore.

Let me show you why.

What Is Vibecoding?

Vibecoding is using natural language prompts to describe what you want to build, then overseeing AI handle the execution.

For PMs, it’s a new way to interact with products. It gives you visibility into code, databases, and logs you’d normally never see.

And before you ask: no, you don’t need to know how to code. It helps, but it’s not required.

What matters more is your ability to be specific about what you need the system to do. And if you’re a PM, that’s a skill you’ve probably mastered a long time ago.

Why Vibecoding Belongs in My Toolkit Now

Most people think of vibecoding as a quick prototyping trick.

And sure, it is.

But for a PM, the real value hides in the less obvious benefits: the ones that change how you work day to day.

1. Empowerment

Humans like to make things. If you’re a PM, you like to make things a lot.

And if you’re a PM like me, you don’t just like making things - you like learning, tinkering and experimenting.

Vibecoding gave me three gifts:

1. It bulldozed the walls between my ideas and actually doing something about them

2. It gave my PM skills (strategizing, defining, framing) a bigger playground than a Miro board

3. It keeps pointing out what I need to learn next

Put it all together, and vibecoding leaves you feeling not just empowered, but refreshed. Like your creative energy finally has room to stretch.

2. Automating Internal Ops

Many PMs get stuck doing product operations, reporting, and endless workflow tweaks (ask me how I know).

Vibecoding flips that script.

Instead of waiting in line for engineering time, you can spin up scrappy internal tools that actually move work forward:

• Dashboards on demand

• Workflow automations

• Reporting bots

• Experiment launchers

• Admin cleanup scripts

These aren’t the glamorous projects that get roadmap headlines, but they’re the ones that actually move the needle, keep the team humming, and uncover insights faster than formal development cycles.

3. Turbocharging the Build-Measure-Learn Cycle

Feedback loops are everything for a PM.

With vibecoding, those loops stop dragging and start snapping into place. You can spin up a functional prototype, put real user flows in front of actual people, and validate a concept, sometimes all in the same day.

I tried this while building StackShelf, and it was the fastest feedback loop of my entire career. Even faster than the ones I’d seen in dedicated innovation labs. Ideas that used to take weeks to validate were tested in a matter of hours.

A proud PM moment, if you ask me.

Just to warn you: after tasting that speed, going back to old validation methods feels impossible.

4. Making You a Better Partner to Engineers

My whole life, I prided myself on having a good understanding of what engineers need from me: how to be helpful, when to step in, and when to stay out of the way so their workflow isn’t disrupted.

Vibecoding takes that understanding a step further.

One of the clearest lessons was about sequencing. Vibecoding makes it obvious why engineers prioritize and split work the way they do. You start to experience why foundations have to come first: the database before the dashboard, the authentication before the profile page.

5. It’s Turning Into A Movement

Traditional product communities are informative, polite, and oddly uncollaborative. Rarely do you see PMs actually breaking problems apart together.

Vibecoding changes that.

It’s a movement of builders. PMs, designers, data folks, ex-consultants, founders building side by side, swapping tips and…having fun.

Which, if you think about it, is exactly how you imagined PM work would look when you first started.

In the Product With Attitude community alone, several PMs are already vibecoding in public: , , , , , , , , .

And that list only covers full-time product managers. If we include PM-adjacent roles the number is much higher.

TL;DR

The 5 Non-Obvious Benefits of Vibecoding Every PM Should Know:

1. Empowers creativity by smashing barriers between ideas and execution.

2. Automates boring internal ops (dashboards, reporting, workflows).

3. Turbocharges the build–measure–learn cycle with rapid prototypes.

4. Makes you a sharper partner to engineers.

5. It’s turning into a community-driven movement of PMs vibecoding in public.

Additional Resources

• Go Beyond the Prototype: Everything You Need To Build & Launch AI Products

• PRD Template and Self-Auditing Prompt

• GitHub Setup for Complete Beginners

• Community for Feedback and Help

Learning Paths

👉 Unsure how to start vibecoding? → Reach out, I’m just a message away!
👉 Looking to improve your prompts? → Start with this post
👉 Curious WHY I vibecoded StackShelf? → Start with this post and follow the links.

Community Updates

1. We’re still growing! We just crossed 2.3K members, thank you all for being here!

2. Stackshelf just crossed 113 products.

2. launched vibecoding.builders - a showcase site for our vibecoded creations!

3. ’s vibecoded app is launching on Product Hunt soon, so keep an eye out!

4. Thanks to , we now have our own spot at 💎 AI Vanguard Society. If you’re into AI, you’ll feel right at home there.

Join Us!

Recommended Reads

: Lovable Just Killed Two Apps? Create Your Own SaaS Without Coding in 2 Days - Pawel vibecoded his newest product from A-Z.

: Substack automation with n8n: how to publish Notes automatically - not vibecoding, but a generous share so I’m passing it along.

All illustrations are original works created by me in Procreate, never AI-generated.
Feel free to reuse with credit (Karo Z., Product With Attitude).

It’s An Absurdly Great Time To Be Creative

Up until last year, there was a wall between you and your ideas. It was called “knowing how to code.”

This year, that wall has cracks, holes, and at least seven Substackers peeking through. Tools like Replit, Cursor, and Lovable are turning creativity into software - fast.

You don’t need to ‘‘be technical’’, or have big funding. You just need curiosity, your creative power and a half-decent prompt.

What follows are real things built by real people (many with zero coding skills), why your turn might be next and what to watch out for.

Subscribe now

From Idea to Revenue: How I Built XR Jobs Board With 0 Technical Experience

• Author: and

• Small iterative steps to turn a XR Jobs Board idea into a functioning, revenue-generating site.

• 👉 Read here.

I broke Replit, so you don’t have to. How I Built A Showcase Hub Just For Substack Creators.

• Author:

• This post continues to get a lot of traction and I’d be remiss not to shout out my own publication.

• 👉 Read here.

How I Vibe-Coded the Proudwork Landing Page

• Author:

• Transforming a minimalist Canva mock-up into a live landing page. Kenny spent just over $100 and demonstrating a fast, low-code workflow for launching a clean video-hosting site.

• 👉 Read here.

What Is Vibe Coding? A Guide to AI Coding Tools That Deliver Real Business Value

• Author:

• If you need a buyer’s guide, start here: feature matrix, pricing notes, and enterprise-readiness scores for Cursor, Replit, v0, and more.

• 👉 Read here.

What people are vibe coding (and actually using)

• Author:

• 50+ useful/fun/clever examples of what non-technical people are building—to inspire your own vibe-coding journey

• 👉 Read here.

Announcing the official Vibe Coding Showcase

• Author:

• A meta-move: vibe-coding a site that curates the best vibe-coded projects. Great place to browse, and to submit your own experiments.

• 👉 Read here.

Vibe Coding Needs Context Engineering

• Author:

• Why vibes alone won’t ship an enterprise app. A lucid argument for moving past prompt tinkering toward systematic context engineering, complete with a four-pillar framework.

• 👉 Read here

Vibe Coding: Not Worth the Risk?

• Author:

• Two real-world fiascos: a dating-safety app leak and an AI agent nuking a production DB - illustrate what happens when security trails the vibes.

• 👉 Read here.

Why I’m All-In On Vibe Coding

I’ll be tracking this space closely — for three reasons:

1. To learn.

2. To share what I learn with others building in public.

3. And because we’re at the starting line of something big - and not every generation gets to say that.

It’s Your Turn Now
Build something small, silly, smart - or all three. Because the wall is cracked and it would be a pity not to peek through.

Prompts & Workflows To Get YOU Started

These are not generic or random; I only share the prompts I’ve personally refined through multiple rounds of testing.

• Prompt Builder

• Prompt Evaluator

• Vibecoding in Replit: Anti-regression Agent

• Vibecoding in Replit: Founder’s Agent

• Vibecoding Resources on Github

TL;DR

• The wall between creativity and code is crumbling.

• Thanks to tools like Replit and Cursor, anyone with curiosity and a decent prompt can build software—no tech background required.

• This roundup highlights real projects built by real people (many non-technical), why vibe coding is having a moment, what to watch out for, and how to start your own build-in-public journey.

Are You New Here And Enjoying This Post?

• You might also like work by these brilliant builders: , ‚ , , , ,

• Whatever you build, make sure it’s ethical: , ,

• Not sure how to navigate the AI shift? hosts free workshops to help

• And when you're ready to launch your own thing, make sure your privacy policy is solid- ’s free tool can help

• Grab 50+ freebies from great Substack writers on stackshelf.app

• Subscribe to join our community

Subscribe now

Got a favorite July read I missed?

Hit reply with the link - just make sure it’s on Substack 🤗

Community Updates

We’re rising, again!

The Builder-Evaluator Loop is a two-prompt system that writes, scores, and rewrites AI prompts against a 35-criteria rubric across 7 categories (Clarity, Specificity, Context, Format, Tone, Output, Edge Cases). The Prompt Builder drafts the prompt. The Prompt Evaluator scores it from 0 to 175 and returns a revision. This is the 2026 evolution of The Self-Improving Prompt System I published in July 2025. Works in ChatGPT, Claude, Perplexity, and Gemini. Saves credits, kills trial-and-error, and turns prompt writing into a measurable workflow.

I still hear: ‘‘I’m not technical’’ or ‘‘The results were meh’’ from some of my friends.

You’re not alone if your AI experience still feels not quite right - or a bit like tossing darts blindfolded: sometimes they hit, sometimes they puncture your hard-won patience.

This simple, step-by-step prompt system unlocks ChatGPT’s potential for better, more consistent results. No technical skills required. You’ll be ready for reliable answers in under two minutes.

Jump in and explore the step-by-step prompt system now; I’ll break down the science behind its consistent results at the end.

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome! Here’s what you might have missed:

• The Only AI Prompting Guide That Works On Reasoning Models (And Our Cognition)

• AttitudeVault: my searchable prompt and Skills library, including community-shared prompts from Product with Attitude readers.

SUBSCRIBE

What’s Inside

• Why a 35-criteria rubric beats “rewrite until it feels right”

• The 7 rubric categories and what each scores

• The Prompt Builder prompt (free, copy-paste ready)

• The Prompt Evaluator prompt (paid, the scoring engine)

• A worked example: a low-scoring prompt rewritten to high-scoring

• How to chain the two into a single agent loop

Why Trial-and-Error Prompting Is an Expensive Habit in 2026

A vague prompt run a thousand times burns a thousand cycles of credits to find the version that should have existed on attempt one.

A 35-criteria rubric is not academic. It’s a checklist that turns a hunch into a score. The score tells you which knob to turn, in what direction, by how much.

The shift: prompt engineering becomes prompt evaluation. The skill is no longer crafting the perfect sentence. The skill is scoring the sentence you already have.

The 7 Categories of the 35-Criteria Prompt Rubric

The Builder-Evaluator Loop: a 35-criteria Prompt Rubric

Two prompts. One writes, one scores. The scorer hands the writer a rubric, the writer rewrites, the scorer scores again. The loop stops when the score crosses a threshold I set.

Your setup:

• ChatGPT Plus

• Prompt Builder

• Prompt Evaluator

That’s it.

This simple trio works for everyone, from building advanced AI agents to writing a best man speech.

The Prompt Builder

Copy-paste into any model. Drafts the first version of a prompt against the rubric.

Read more

In 2025, I built StackShelf, a shelf-in-bio for Substack creators, using Replit and ChatGPT. The launch nearly died on Google OAuth: every tester got locked out, I was the only one who could log in, and Replit kept fixing one thing while breaking another. The bug took multiple days and a holiday’s worth of bad dreams to crack. The full story is below. The prompt that finally fixed it lives behind the paywall.

There are two kinds of product updates.

• The ones you proudly list in changelogs and marketing decks.

• The ones you bury deep under “general improvements” because, well, “accidentally deleted the auth flow” feels too raw.

This series is about the second kind.

Because while StackShelf now behaves like a real, grown-up platform, just two weeks ago it was being held together by stubbornness, and the kind of optimism that borders on delusion.

So here it is - the first post: a full rundown of the behind-the-scenes process, bugs, errors, and mysterious side effects that made up the sleep-deprived road to something that finally works.

Hey, I’m Karo Zieminski 🤗

AI Product Manager and builder.

I write Product with Attitude, an AI newsletter for thousands of subscribers developing critical AI literacy the only way it sticks: through practice.

We don’t just use AI. We build workflows, automations, and products with it, while studying how AI itself is built, positioned, and woven into our work.

If you’re new here, welcome! Here’s what you might have missed:

• Claude Design Review & Prompts

• Is Your Replit Looping? This Will Help.

• Perplexity Computer: What I Built in One Night

• I Built a Runaway Subscribe Button. It Brought 70 Subscribers in 6 Days.

SUBSCRIBE

What’s Inside

Why Substack creators need a shelf-in-bio. The non-negotiables I scribbled before writing a single prompt. The Google OAuth bug that locked out every tester except me. The pattern of fixes that kept breaking the previous fix. The Reddit rabbit hole that led to the prompt that finally worked. And the community that turned a broken MVP into a real product.

Why I Built StackShelf

Substack is designed for writing and building an audience, not for selling.

But here’s the honest truth: most Substackers absolutely want to monetize their expertise.

And picking the best way to do it reminds me of picking the least terrible bathroom at a music festival -none inspire confidence, but you have to go:

• Gumroad, Amazon, etc. - your products drift through cyberspace, lost among millions, nowhere near your actual readers.

• Rely on blog posts - great, until they disappear in the feed and your readers struggle to find it when they need it

• Cross your fingers and hope new readers just stumble across your offer

If you’ve ever lost your own product in your own newsletter, please know you’re in excellent company. And you deserve better.

Assumptions & Non-Negotiables

Assumptions

Going in, I assumed three things:

• Substackers care about trust

• Substackers want to support each other

• Substackers need something like StackShelf – this was instantly validated: this post brought in 88 new subscribers and and a flood of DMs.

  The 88-subscriber tell. One post about why StackShelf needs to exist pulled in 88 new subscribers in a few days. That's the signal that confirmed the assumption. Not a survey. Not a focus group. Just readers showing up.

Non-negotiables

Design Choices

• Creator first: every decision must prioritize their needs

• Shelf-in-bio: beautiful bento-style showcase, no compromises

• Visual hierarchy: clear information architecture, users are guided naturally

• Performance as design: Speed and responsiveness as essential design features

• 1-click redirects to Gumroad (or wherever the products actually live)

• Color palette: no corpo colors, warm gradients to create optimism and energy

• Typography: not another generic vibe coding font

• Privacy-first analytics (click counting - yes, tracking who clicked - no)

Tools I Used to Build StackShelf

• ChatGPT: Thinking buddy, critic, PRDs, value prop canvas, and prompts for Replit.

• Figma: Sketches and design files for Replit.

• Replit: Development, deployment and documentation.

• Github: Code repository.

What Broke When I Shipped StackShelf?

There are plenty to choose from, but today, let’s talk about making Google OAuth work in Replit. This one’s got more twists than a season finale of Game of Thrones.

Right before going on holidays, I decided it was the perfect time to ship the MVP.

My plan was to send it out for testing while I’m away, then come back to an inbox overflowing with thoughtful, actionable feedback. The sort of feedback that makes you want to hug strangers.

You can already see where this is going. Let’s never do that again.

Not one tester could log in.

Not. A. Single. One.

I could, of course, but I’ve long suspected Replit finds me easier to humor than others.

Error 1

I didn’t panic at first. It’ll be a quick fix, I thought, just like every other time.

So, there I was: making dinner, packing my suitcase, toggling between folding socks and debugging in Replit.

Replit responded promptly, made a fix, tested it, and declared victory.

The agent was pleased with itself.

My testers, on the other hand, were not.

, who is much kinder than the situation deserved, stayed on the line as we attempted another round of digital whack-a-mole.

Still, nothing. The login remained an exclusive club, of which I was the only member.

It dragged on for hours.

• Replit fixed the authentication → broke the redirect.

• It fixed the redirect → broke the authentication, and I started rubbing my temples.

• Got that back → the login button vanished, no warning, no farewell note

• Re-added the button → and with impressive efficiency, everything looped right back to error one.

By this point I was saying things I’d have to apologize for if computers had feelings. It was 2 am and I realized this bug wasn’t going down tonight - so I did.

Replit Google Oauth Fix

While on holidays, I kept having replit-related dreams and continued digging into the problem.

It turns out, Google OAuth is a common issue on Replit: I discovered entire Reddit threads devoted to solving it.

And I started taking notes. I dug into their complaints, analyzed patterns, and kept refining a prompt that might solve the problem before it started.

And it did.

When authentication finally worked, I could hardly believe it. I just sat there, afraid to touch anything. It was less victory than cautious disbelief, but hey, I’ll take what I can get.

What Does Debugging Replit Teach You About Building Solo?

Every single bug taught me something, not just about state management, redirect logic, or the unique flavors of API weirdness, but about resilience, boundaries, and the specific psychology required to debug a mess of your own making.

I built my bulletproof prompts out of all this - and, miraculously, they work every time.

The Community Behind StackShelf

In product work, you know you’re onto something special when people show up early -and stay. When they stick around after the first test fails or the prototype breaks, they stop being “testers” and start becoming co-creators.

I’ve been lucky to find those people. StackShelf is, to an embarrassing degree, the product of their patience.

• : a quiet force of leadership and encouragement from day one. He’s contributed so much, I drew him his own doodle avatar (scroll up).

• : another engineering leader, landing a hand even though he's busy building his own app for busy parents.

• : the first author and illustrator to join. That trust means everything!

• & : the ethics and privacy conscience of Substack.

• : my go-to for Substack strategies and the only person who can explain algorithms without sighing.

• : the go-to digital product builder who can turn a napkin sketch into a product before I find a pen

• , , – product and design thinkers whose perspectives will help shape the next phase of testing

• : Creator of Writestack and a strong source of inspiration

• and - the kind of people you want by your side while navigating the AI transition, or honestly, just a Tuesday

• – my favorite designer in the world (we go way back). She just joined Substack and her presence is a gift to the platform.

• – who generously agreed to write a post about StackShelf on his excellent blog. That support goes a long way.

• - Our first adventurous spirit, poet and life coach to join the journey.

• : The mastermind behind all things Substack data, making sense of the numbers like no other.

• : A fellow obsessive learner, always curious and diving deep into new knowledge.

• : our very first supporter from the world of politics.

• : A scientist turned developer, there’s really nothing she can’t do

Final Patch Notes

• StackShelf is live and in testing

• You can sign in, even with Google

• I still say “just one last fix” and mean it every time

Paid members get access to my bulletproof Replit prompts.

Why It’s Important To Share This Post

We need to kick off the network effects.

If you're not familiar with network effects, think of it like this:

• Every share brings more eyes

• Each new set of eyes = more readers for everyone

• Some of these readers are creators themselves = more content

• More content = even more eyes and shares

That’s how we’ll build the viral loop together.

Keep Reading

Community Updates

We’re rising again!

WHY SUBSCRIBE ・YOUR BENEFITS・ TOOLS I BUILT・CLAUDE HUB・PERPLEXITY HUB ・VIBE CODING HUB

SUBSCRIBE

• Some are tactical.

• Some are emotional.

• All are tested and honest.

• I feel so strongly about each of them, I will not change my mind even if you offered me a lifetime supply of paid Substack subscribers.

This list is not aspirational, it doesn't ask you to “evangelize the vision” or “orchestrate complexity” - it's operational.

It started as a single note-to-self, then grew one mistake and one win at a time, and now it won't stop growing. I hope it helps someone!

19 Product Team Lessons in 4 Minutes

1. Minimum Viable Team:

   

2. Design like people are tired and distracted, because they are.

3. Build with opinion, you can’t please your way to greatness. Just make sure that your opinion is facts.

4. Working with Devs 101:

   • Email = emergency.

   • Slack = everything.

   • Meetings = last resort.

   Meet them where they are.

5. Pricing is product. Roadmap is sales magnet. FAQ section is your sales funnel.

Read more