PRODUCT BLUEPRINT · DECISION & PLANNING SYSTEM
A vibe-code idea evaluator that turns a promising idea into an evidence-aware decision, a justified technology plan, and a stage-gated route to market—without turning every idea into a giant software project.
SCOPE A · THE TOOL WE ARE BUILDING
The evaluator itself remains an internal, single-owner MVP. It organizes screening, research, stack tradeoffs, costs, unknowns, and decisions. It is not an autonomous builder, deployment agent, or a commitment to sell this evaluator as SaaS.
SCOPE B · THE IDEAS IT EVALUATES
The five evaluation phases and six release stages describe what the evaluator can plan for an evaluated idea. A commercial roadmap can be generated without forcing the evaluator itself through paid beta or public launch.
Baseline honesty: working Render staging is user-reported. The local deployment configuration declares the dev branch, a single instance, a persistent disk mounted at /var/data, and SQLite at /var/data/history.sqlite3. This is configuration evidence only: the deployed commit, effective live settings, backups, and runtime behavior have not been verified for this report. The project README supplies context, but parts remain local-first; it is not proof of the deployed system.
WHAT THE EVALUATOR PRODUCES
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.
| Evaluation phase | Decision & deliverable | Boundary |
|---|---|---|
| 1. Idea Screening | Should I pursue this? A short business brief covering viability, demand, competitors, monetization, AI disruption, exit potential, technical red flags, and unknowns. Verdict: Go / Validate / Pivot / Kill. | Go means proceed to research—not “business validated.” No complete architecture or launch campaign. |
| 2. Deep Investigation | What does the evidence reveal? Research customer pain, market alternatives, distribution, data permissions, technical feasibility, model limitations, risks, and unresolved dependencies. | An evidence-backed dossier with a cheapest-test plan, not fabricated proof of demand. |
| 3. Tech Stack & Architecture | What should I build with, when, and why? Compare three architecture profiles, researched costs, tradeoffs, limitations, and explicit upgrade triggers. | Research technology before choosing architecture; choose architecture before detailed build instructions. |
| 4. Build & Launch | How do I progress without overbuilding? One playbook with coordinated Build, Design, and Launch tracks across the six release stages below. | A conditional 24–48-hour timebox covers a prototype or internal MVP—not an entire commercial product. |
| 5. Scale or Exit | How do I grow, optimize, or sell? Plan profitability, retention, operational automation, defensibility, infrastructure triggers, and resale readiness. | Consider implications early; execute growth and exit work only when evidence and the current milestone justify it. |
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.
A FIRST-CLASS DELIVERABLE
PROFILE A
Prove the difficult component and the smallest useful end-to-end workflow. Prefer near-zero fixed cost, not free infrastructure that forces a rebuild. A modest paid service may be the cheaper overall choice.
PROFILE B
Support real users and eventually paying customers with appropriate reliability, authorization, protection, and operating controls. Add only what the audience and risk require.
Proposed terminology edit: historical name was “Production MVP.”
PROFILE C
Identify measured bottlenecks, capacity limits, upgrade costs, and a migration path only if needed. Explicitly list components that remain unchanged. Higher limits on the same stack can satisfy this profile.
Frontend, backend, database, hosting, authentication, storage, payments, AI models/APIs, and automation. Mark a component unnecessary when appropriate. Compare relevant alternatives—such as Render, Vercel, Cloudflare, or Railway—only against the actual workload, not as a vendor checklist.
Document background jobs, execution timeouts, model quality, API limits, data access, secrets, authorization, security, vendor lock-in, and scaling bottlenecks. Link claims to official documentation and explain why the winner fits.
Separate fixed monthly spend from variable usage; show free-tier eligibility and limits, realistic volumes, retries/failures, and cost per successful result. State assumptions, quote freshness, spending limits, and migration effort.
Use low/base/high usage scenarios tied to the idea. Define a measurable upgrade trigger, the benefit, and the least disruptive change. Exact provider pricing belongs in each idea’s Phase 3 research; this blueprint does not invent a universal stack quote.
ROADMAP GENERATED FOR EACH IDEA
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.
Internal; no paying users
Owner/internal testers only
Invited real users; illustrative 5–20, usually free
Small paying cohort; illustrative 10–50
Controlled growth; illustrative 50–500 paying users
Broader public market
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.
| Phase 4 track | What its playbook must specify | Scope restraint |
|---|---|---|
| Build | Exact features, chosen architecture, implementation sequence, integrations, tests, deployment steps, and explicit exclusions. | Prove the core workflow before adding later-stage capabilities. |
| Design | Stage-appropriate internal app usability and conversion-focused public website: input, result, progress, failure, and next-action states. | No elaborate website before core feasibility; no premature interface redesign of the evaluator. |
| Launch | Positioning, pricing, payments when needed, recruitment channels, acquisition experiments, feedback collection, and success measures. | Cheap demand tests can start early; scaled campaigns wait for evidence. |
JUST-IN-TIME CAPABILITY
| Capability | Earliest typical need | Risk-based exception |
|---|---|---|
| Hardest dependency test; explicit sample-data labels | Prototype | Check data rights and commercial API permissions before touching real data. |
| Core workflow, useful persistence, tests, budget limits | Internal MVP | Use manual steps when safe; persistence is required where loss would invalidate testing. |
| Secrets, restricted access, data minimization, safe errors | From first real data or paid API use | Never postpone essential security until paid beta. [5] |
| Invitations, usable onboarding, feedback, support | Private Beta | Tenant isolation and authorization tests arrive before multiple users share private data—not at an arbitrary later milestone. |
| Billing, refunds, quotas, cost-per-result tracking | Paid Beta | Spend controls are earlier if APIs cost money; billing can remain absent in an internal tool. |
| Concurrency testing, support automation, capacity upgrades | Expanded Paid Beta | Load-test earlier if the core design is concurrency-sensitive; upgrade only on evidence. |
| Broad acquisition website, mature operations | General Availability | A simple demand-testing page may be earlier; backups and monitoring arrive when data and risk require them. |
NON-NEGOTIABLE BOUNDARIES
Maintain a current-milestone allowlist. Every task must state its decision benefit and acceptance test. An exception must name a critical dependency, security need, or data-integrity risk; document time, cost, and scope impact; obtain explicit approval before work.
If it does not improve the current Go / Validate / Pivot / Kill decision, Phase 1 rejects it. A useful later idea goes into the deferred list, not the active task list.
PROTECT BEFORE CHANGING
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.
| Protect | Inspection & proposed procedure | Approval boundary |
|---|---|---|
| Application code | Inspect branch, worktree, remote dev, and uncommitted changes. Verify the deployed commit independently; local HEAD is not deployment proof. Identify a known-good tag target. | Tag creation is a later, separately approved action. Leave production main untouched. |
| Evaluation history | Inspect configured SQLite location and persistent mount. Plan a consistent backup of /var/data/history.sqlite3 using SQLite’s Online Backup API, not a blind raw copy of an active database. [2] | Authorize backup and an isolated restore drill separately. Do not test restoration over the live database. |
| Settings & recovery | Inventory environment variable names and configuration without secret values. Record schema compatibility, restore steps, and a safe maintenance window. | Do not change settings or expose credentials. Keep staging running unchanged. |
Inspection & plan → explicit backup/tag approval → verify checkpoint → separate Phase 1 implementation approval
THE ONLY NEXT IMPLEMENTATION SLICE
Start with technical red flags, current release stage, and the next milestone. Cover business viability, demand signals, actual competitors, monetization, AI disruption, resale potential, technical risks, and the most important unknowns.
End with a reasoned Go / Validate / Pivot / Kill verdict, confidence tied to available evidence, the cheapest next validation test, and its estimated time and cost assumptions. Unknown costs stay unknown; lack of research is visible.
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.
RESEARCH CONTEXT, NOT NEW REQUIREMENTS
GOV.UK alpha guidance supports testing risky assumptions early. That supports the proof-first approach, not a rule to follow government project timings or discard all prototype code. [4] NIST supports integrating security into the development lifecycle rather than waiting for paying users. [5]
IdeaBuddy advertises AI-assisted idea validation, financial planning, and business-plan creation, with a 15-day free trial—not a claim of permanent free access. [7] ValidatorAI advertises free idea scoring, competitor/customer analysis, and next-step landing-page prompts. [8]
Official positioning only. No hands-on product tests, independent quality findings, or comparative performance claims.
PROPOSED · NOT APPROVED
These notes are separate from preserved conversation requirements. No source text has been removed, and no recommendation here authorizes application changes.
Label claims FACT / INFERENCE / ASSUMPTION / UNKNOWN. Record supporting source, freshness, confidence, and the evidence needed to resolve uncertainty. Never fabricate customer validation or treat model output as a completed experiment.
Critical blockers cannot average away. Screening Go permits deeper research only. Require human review before advancing release stages or approving additional research spend; a model cannot certify its own readiness.
Ask for a credible cheaper validation test before coding. Allow demand discovery before technical stage completion. Generate heavy reports on demand, enforce per-approved-run cost caps, and benchmark quality before prompt/schema changes.
Keep your “Internal MVP” definition. Rename future Profile B from the original “Production MVP” to “Customer-ready production baseline.” Keep the original label visible in the archive and this note. MVP usage varies outside this product. [6]
Describe 24–48 hours as a conditional prototype/internal-MVP timebox with assumptions and blockers, not a full public-product delivery promise. Keep all three profiles, while allowing the same underlying stack across them.
Do not carry forward mandatory duplicate stacks, automatic migrations, or a guaranteed 48-hour commercial launch. This is a recommendation about future requirements—not deletion of the original conversation or existing features.
OFFICIAL SOURCES · CLICK TO INSPECT
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.
Persistence boundaries, single-instance/downtime constraints, and disk-snapshot cautions.
Database-consistent live backup mechanism; foundation for a proposed backup and restore procedure.
Limited private beta before broader public beta; not the source of our paid-beta subdivisions.
Test risky assumptions early; cited as context, not a mandatory delivery methodology.
Integrate security practices throughout the lifecycle.
MVP and Build–Measure–Learn; terminology differs from our internal-only MVP convention.
AI-assisted validation and planning; marketing positioning, not independently tested quality.
Free idea analysis/scoring and next-step prompts; marketing positioning, not independent validation.
COMPLETE SOURCE · VISIBLE, NOT COLLAPSED
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.