Better build decisions.
Less unnecessary building.

Evaluation phases answer different questions. Release stages describe audiences and readiness. Implementation checkpoints protect the evaluator before a scoped change. These are three separate layers, not seventeen sequential development tasks.

PROPOSED ADD Generate heavier phases on demand after human approval, with an explicit research-cost cap for each run. Keep Quick Screen lightweight and preliminary, with no mandatory paid research-provider call. An unresearched screen must say what it does not know.

Required blueprint fields for every profile

Each stage below includes all seven required planning fields. Audience ranges are illustrative, never quotas. Graduation thresholds must be chosen per idea before testing; the templates here are proposals, not empirically validated universal benchmarks. Human approval is required to advance.

Demand tests can happen before coding or alongside technical proof: interviews, a manual concierge test, or a landing-page response test may be cheaper than an app. The stage framework governs product access and operational readiness; it must not lock all customer discovery behind internal development.

The archived prompt is an inspection and backup-planning assignment only. It has not been executed here. No evaluator tags, database copies, Render changes, commits, pushes, application deployments, or paid model calls were made for this report. Publishing this static report is separate from deploying the evaluator.

Inspection & plan → explicit backup/tag approval → verify checkpoint → separate Phase 1 implementation approval

PROPOSED ADD Freeze a small benchmark of representative ideas and a human review rubric before prompt/schema changes. Include straightforward, technically blocked, weak-demand, and expensive-AI ideas. Compare claim support, critical-risk detection, decision usefulness, and run cost—not merely valid JSON. This is a scoped quality check, not a new evaluation platform.

Not implemented: this report specifies the work; it does not modify the evaluator, pinned skill, schema, prompts, database, or deployment.

These notes are separate from preserved conversation requirements. No source text has been removed, and no recommendation here authorizes application changes.

Sources were accessed on October 20, 2026. External references support the narrow claims linked above; they do not approve this roadmap or validate any business idea. Product-policy choices and advisory recommendations are explicitly labeled.

1. Render — Persistent Disks

   Persistence boundaries, single-instance/downtime constraints, and disk-snapshot cautions.

2. SQLite — Online Backup API

   Database-consistent live backup mechanism; foundation for a proposed backup and restore procedure.

3. GOV.UK — How the beta phase works

   Limited private beta before broader public beta; not the source of our paid-beta subdivisions.

4. GOV.UK — How the alpha phase works

   Test risky assumptions early; cited as context, not a mandatory delivery methodology.

5. NIST — Secure Software Development Framework 1.1

   Integrate security practices throughout the lifecycle.

6. The Lean Startup — Principles

   MVP and Build–Measure–Learn; terminology differs from our internal-only MVP convention.

7. IdeaBuddy — Official product site

   AI-assisted validation and planning; marketing positioning, not independently tested quality.

8. ValidatorAI — Official product site

   Free idea analysis/scoring and next-step prompts; marketing positioning, not independent validation.

Download original conversation.txt The embedded download preserves the original file bytes.

and where does the tech stack show up in this list of phases
It should be much more prominent. I buried it inside the phases, and tech stack selection is one of the primary reasons we're building this app.

I'd make it a dedicated phase, immediately after feasibility research and before the 24–48-hour build plan.

Revised phases
Phase

Focus

Key deliverable

1. Idea Screening

Is this a viable business?

Business verdict

2. Deep Investigation

Market, competitors, technical feasibility, risks

Research dossier

3. Tech Stack & Architecture

What should we build it with, and why?

Researched technology blueprint

4. 24–48 Hour Bootstrap

Smallest working version

Exact build instructions

5. Launch & Monetization

Design, marketing, payments, customer acquisition

Launch blueprint

6. Scale or Exit

Growth, infrastructure upgrades, acquisition potential

Scaling roadmap

Phase 3 needs to be substantial
It should produce three architecture recommendations, not just one.

Stack A — 24–48 Hour Bootstrap

The simplest, cheapest combination that proves the core functionality. Target near-zero fixed costs wherever feasible.

Stack B — Production MVP

A secure, reliable, low-maintenance stack capable of supporting actual paying customers without unnecessary infrastructure.

Stack C — Scaling

What changes when usage grows, which bottlenecks trigger upgrades, and which components can remain unchanged.

For each stack, the report should include:

Specific technologies: Frontend, backend, database, hosting, authentication, storage, payments, AI models/APIs, and automation.

Alternatives compared: Render vs. Vercel vs. Cloudflare vs. Railway, for example, when relevant.

Actual costs: Free-tier eligibility, monthly fixed costs, usage costs, and estimated costs at different customer volumes.

Technical limitations: Background jobs, execution timeouts, API constraints, vendor lock-in, security, and scaling bottlenecks.

Why this stack wins: Evidence-based tradeoffs, not default preferences.

Migration triggers: Exactly when and why we'd need to upgrade or switch.

And one particularly important requirement:

The bootstrap stack should not create unnecessary technical debt that forces us to rebuild everything at launch. Sometimes spending $5–$10 per month is smarter than choosing a free solution that creates weeks of migration work.

One more thing
I'd put a Technical Red Flags section at the very beginning of the executive summary.

If an idea depends on an API that doesn't exist, a model that can't perform the required task reliably, prohibited scraping, or economics that don't work, we need to know before generating a 48-hour build plan.

So yes, Phase 3 becomes one of the most important parts of the entire product.

The guiding principle should be: Research the technology first, choose the architecture second, and only then generate the build instructions.

i think that 4 and 5 should be one phase.
Agreed. Building and launching should be one phase. Especially for vibe-coded apps, we shouldn't treat getting something functional and getting it in front of customers as two separate major projects.

That also reinforces our goal of avoiding mission creep.

Revised 5-phase framework
Phase

Focus

Deliverable

1. Idea Screening

Business viability, demand, competitors, monetization, AI disruption, exit potential

Initial verdict: Go, Validate, Pivot, or Kill

2. Deep Investigation

Market research, customer pain points, technical feasibility, risks, unknowns

Evidence-backed research dossier

3. Tech Stack & Architecture

Research and compare bootstrap, production MVP, and scaling stacks, including costs

Technology blueprint and recommendations

4. Build & Launch

24–48-hour bootstrap, MVP scope, internal UX, website design, pricing, marketing, deployment

Actionable build-and-launch playbook

5. Scale or Exit

Growth, infrastructure upgrades, profitability, automation, defensibility, resale

Scaling and exit roadmap

One important distinction for Phase 4
I'd organize Build & Launch into three tracks within the same phase:

Build: Exact features, architecture, implementation steps, tests, and explicit exclusions.

Design: Modern internal app UX plus a conversion-focused public website.

Launch: Payments, positioning, initial marketing channels, acquisition experiments, and success metrics.

These tracks should work together, but we shouldn't force someone to finish an elaborate marketing website before they can test the app's core functionality.

And Scope Guard applies across all five phases, not just Build & Launch. Every recommendation should distinguish between what matters now, what can wait, and what would be overbuilding.

I think this five-phase structure is a much cleaner foundation for the actual product.

that works...   but lets also keep in mind mvp is always just an internal testing...   in dev do they have stages?  

like mvp test it internally, beta for real users, beta for paid users, beta for large paid user group, etc
Yes. Software development has several commonly used release stages, although companies define them differently.

And I think we should adopt a formal release-stage framework for our Idea Evaluation App so that every app we investigate gets a realistic roadmap from internal prototype to a scalable business.

One distinction I'd make: development phases describe what we're working on; release stages describe who can use the product and how much reliability it needs.

Recommended release stages for vibe-coded apps
Stage 1 — Prototype / Proof of Concept

Internal
Prove that the hardest technical component actually works.

Ugly is fine. Manual processes are fine. Fake or sample data is fine if clearly labeled. No paying users.

Exit: Critical technical feasibility demonstrated

Stage 2 — Internal MVP

Internal
The smallest end-to-end functional product that you can actually use and evaluate.

Basic UI, core workflow, working integrations, persistence where needed, and essential security. No unnecessary features.

Exit: Core functionality works and delivers useful results

Stage 3 — Private Beta

Invited users
A small group of real users tests usability, usefulness, and reliability.

Typically 5–20 users. Real onboarding, feedback collection, bug tracking, and basic support. Usually free.

Exit: Users can succeed without founder assistance

Stage 4 — Paid Beta

Paying users
Validate willingness to pay and the economics of delivering the service.

A small paying cohort, potentially 10–50 users. Billing, refunds, usage limits, cost tracking, and dependable core workflows.

Exit: Repeatable paid usage with sustainable unit economics

Stage 5 — Expanded Paid Beta

Controlled growth
Increase usage to discover operational and scaling problems.

Perhaps 50–500 paying users, depending on the product. Test concurrency, cost spikes, support load, retention, and operational automation.

Exit: Reliable performance and positive economics at the intended launch volume

Stage 6 — General Availability

Public launch
Open to the broader market, with proven core functionality, reliable operations, and a sustainable business model.

Established onboarding, support, monitoring, backups, billing, and customer acquisition.

Exit: Ready for ongoing optimization and scaling

These are recommended planning stages, not universal industry standards. User counts are illustrative; progression should depend on risk, complexity, and evidence rather than arbitrary numbers.
How this fits into our five phases
We don't need to add six more phases. Instead, release stages become part of Phase 4: Build & Launch, with Phase 5 handling expansion after launch.

Here's how the framework works:

Our evaluation phase

Release stages it plans

1. Idea Screening

Determines whether to investigate

2. Deep Investigation

Identifies feasibility and business risks

3. Tech Stack & Architecture

Recommends technology for each release stage

4. Build & Launch

Prototype → Internal MVP → Private Beta → Paid Beta → Expanded Paid Beta → Public Launch

5. Scale or Exit

Growth, upgrades, profitability, acquisition

The most important rule
Each release stage should have its own feature limits, cost budget, and graduation criteria.

For example:

Stage

Infrastructure philosophy

Prototype

Almost free; prove the hardest component

Internal MVP

Near-zero cost; functional, not polished

Private Beta

Low-cost hosting with essential security

Paid Beta

Reliable billing, data protection, quotas, and cost controls

Expanded Paid Beta

Upgrade only when real usage justifies it

Public Launch

Production reliability matched to actual demand

Security basics shouldn't wait until paid beta, particularly when real user data or paid APIs are involved.

And we shouldn't automatically recommend migrating from one stack to another at every stage. A good initial architecture might serve the product through all six stages. That's an outcome we'd actively prefer.

One final addition I'd make to our evaluator
For every proposed feature, the AI should identify the earliest release stage where it becomes necessary.

For example, multi-tenant authentication might be unnecessary for an internal MVP, essential for a private beta, and need more robust authorization testing before paid beta.

That gives the founder a concrete defense against mission creep:

This feature may be valuable, but it isn't required until Stage 4. Don't build it during Stage 2.

I would make these six release stages an official part of our product specification. They provide the discipline we've been missing: prove feasibility, prove usefulness, prove demand, prove willingness to pay, prove scalability, and only then expand.

oh thats perfect.. lets add that framework and thinking for the phase then.
Agreed. We'll make the six release stages an official framework within Phase 4: Build & Launch, and use them to inform the technology recommendations in Phase 3.

The important part is that this isn't just a checklist. It becomes part of how the evaluator makes decisions.

Updated Phase 4 — Build & Launch
Six-stage release roadmap

Prototype / Proof of Concept — Prove technical feasibility.

Internal MVP — Prove the complete core workflow delivers useful results.

Private Beta — Prove real users can use it successfully.

Paid Beta — Prove people will pay and unit economics work.

Expanded Paid Beta — Prove the product handles growing usage reliably.

General Availability — Launch broadly with appropriate operational readiness.

For each release stage, the evaluator must produce:

Objectives and exit criteria: What must be demonstrated before advancing.

Feature scope: Build now, defer, and explicitly exclude.

Technology requirements: What the current stack must support and whether any upgrade is actually necessary.

Costs: Expected fixed and variable costs, usage assumptions, and spending limits.

Design and UX: The level of internal app and public website design needed at that stage.

Marketing and validation: How to recruit users, test demand, collect feedback, and measure results.

Risks and safeguards: Security, data protection, operational reliability, and likely technical blockers.

Three rules we'll enforce throughout
1. No automatic graduation. Completing the development tasks doesn't mean the product is ready for the next release stage. It must meet the exit criteria.

2. No automatic infrastructure upgrades. The evaluator must justify every proposed technology change with evidence, costs, and a specific trigger.

3. No premature features. Every feature gets an earliest-needed stage. Anything beyond the current stage is deferred unless it's a critical dependency or safety requirement.

This also means our 24–48-hour bootstrap plan covers the Prototype and Internal MVP stages, not an entire commercial product. It's a conditional target, not a promise that every idea can be built in two days.

Our finalized product framework
Phase

Primary question

1. Idea Screening

Should I pursue this?

2. Deep Investigation

What does the evidence reveal, and what could go wrong?

3. Tech Stack & Architecture

What should I build it with, at each stage, and why?

4. Build & Launch

How do I progress through the six release stages without overbuilding?

5. Scale or Exit

How do I grow, optimize, or eventually sell it?

One additional principle: the executive brief should always identify the current release stage and the single most important next milestone. That keeps the entire research system focused on action instead of information volume.

This is now the framework I'd use as the product specification when we return to Hermes. We should update the pinned skill and report schema deliberately, rather than immediately asking Hermes to rebuild everything.

ALSO is absoultely critical we do not allow for mission creep.  however we can safeguard.

ok so.. lets do phase 1.  do we need to backup or do anything?  not sure how render works or if need to do anything there.  but i think we've got our plan.
Yes. We have the plan. Now we need to protect what we've built and execute it without repeating the last several days.

And I want to make mission-creep prevention a hard requirement, not just something we remind Hermes about.

Before Phase 1, I recommend one short checkpoint.

First: Protect our working app
We have two different things to protect:

Component

Where it lives

What we should do

Application code

GitHub dev branch

Create a known-good Git tag

Evaluation history

Render persistent disk / SQLite

Back up history.sqlite3

API keys and settings

Render environment

Record variable names and configuration, never secret values

Live staging deployment

Render

Leave it running and unchanged

Production main branch

GitHub

Leave untouched

Important: Render deployments are not database backups. Redeploying an earlier commit doesn't necessarily restore the data on a persistent disk.

So yes, I'd protect SQLite separately before making major schema changes. We should use SQLite's safe backup mechanism rather than copying a live database file blindly.

We don't need to migrate hosting, buy another service, or create a second Render instance.

Our immediate plan
Checkpoint 0 — Protect current working version

Tag Git, back up SQLite, document recovery steps.

Phase 1 — Idea Screening

Define and implement the useful initial business verdict, without touching the working Full Investigation pipeline unnecessarily.

Scope Guard — Every change

Reject features, infrastructure changes, and refinements not required by the current milestone.

Send Hermes this first
This is intentionally a small assignment. We're not implementing Phase 1 yet.

Checkpoint 0 — Preserve Working Staging MVP
We have a working cloud-hosted Idea Evaluation App on Render, deployed from GitHub dev.

We are beginning a new product-development plan. Before changing the app, establish a safe recovery checkpoint.

This session is ONLY for inspection and backup planning.

Inspect Git status, current branch, remote dev, and any uncommitted changes.

Identify the exact deployed commit if verifiable from available information. Do not assume local HEAD is deployed.

Determine the safest way to create a Git tag for the verified working version.

Inspect the existing Render persistent-disk and SQLite configuration to determine a safe, non-destructive backup method.

Identify how to back up and restore /var/data/history.sqlite3 without corrupting the live database.

Identify any schema-migration or rollback risks.

List the required Render environment variable names without displaying secret values.

Do not modify code, create tags, copy databases, change Render settings, deploy, commit, push, or call paid APIs.

Report a short, concrete checkpoint procedure and anything requiring my approval.

Scope Guard: Do not propose infrastructure upgrades, new services, CI/CD redesigns, multi-user features, or unrelated improvements. This is a private, single-owner MVP.

Stop after reporting. We will execute the checkpoint separately.

Then Phase 1
Once the checkpoint is complete, we'll focus strictly on Idea Screening.

Its deliverable should be a short but substantive decision brief: business viability, market signals, actual competitors, monetization, AI disruption, resale potential, fatal technical risks, and the most important unknowns.

No full tech-stack blueprint yet. No UI redesign. No expanded marketing plan. Those belong to later phases.

And every Phase 1 task must answer one question:

Does this help us make a better Go / Validate / Pivot / Kill decision?

If not, it doesn't belong in Phase 1.

My recommendation is to run the checkpoint instruction above, send me Hermes' response, and then we'll move directly into Phase 1 with a tightly controlled scope.