Vibecode Sumora
track this build5 steps, step by step0%KINDA · weekend project
The visible surface, a prompt box that produces a researched, personalized outreach message, is a one-sitting build. What takes real work is everything that keeps an agent from quietly going insane on step seven: persistent memory about your business and each contact, retries, browser sessions that survive logins and captchas, cost ceilings, and a human approval gate before anything is actually sent. For one person automating their own pipeline, you can get to genuinely useful in a weekend because you are allowed to be the approval step and the error handler. The gap widens fast the moment you want it unattended, multi-user, or connected to a real CRM and mailbox over OAuth. The failure mode also matters: a broken personal script wastes your evening, a broken agent emails the wrong prospect from your domain.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Sumora. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Sumora indie build ## Goal Build the smallest trustworthy replacement for the core Sumora workflow for one developer or a tiny team. ## Scope A local agent loop that takes a target company or list, researches it with search plus a headless browser, drafts a personalized outreach message against your stored business context, and queues it for your approval before sending. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through - Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift - Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person - Cost control and model routing, so one runaway loop does not become a surprise bill - Deliverability and sending reputation work, which is its own unglamorous specialty If those capabilities are essential, use Sumora instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local, single-user AI outreach agent runner. No accounts, no cloud, no telemetry. Stack: TypeScript, Node 20, better-sqlite3 for storage, Playwright for browsing, Hono for a tiny local HTTP server, and a plain server-rendered HTML UI with htmx. No React, no Next, no ORM. Secrets in .env: OPENAI_API_KEY, SMTP_URL. Data model in SQLite: - business_context: freeform notes about my company, offer, tone, and hard rules (one editable blob) - targets: company name, domain, contact name, contact email, status - runs: target_id, state (queued, running, needs_approval, approved, sent, failed), created_at - steps: run_id, index, tool, input, output, error, tokens, cost_cents - drafts: run_id, subject, body, revision Agent loop per target, each step written to the steps table before and after execution so a crashed run is resumable: 1. fetch the target's homepage and one about or pricing page with Playwright, extract readable text 2. summarize what the company does and one specific hook 3. draft a short outreach email using business_context plus the hook 4. run a self-check pass: is the claim supported by the fetched text, is any name or fact invented, is it under 150 words 5. set state to needs_approval and stop Hard rules to implement, not just mention: - nothing is ever sent without an explicit approve click in the UI - per-run and per-day cost ceilings from .env, abort the loop when exceeded - exponential backoff with max 3 attempts on fetch and model calls, then mark the step failed and leave the run resumable - a resume command that picks up any run stuck in running and replays from the first incomplete step - dry-run mode is the default; sending requires SMTP_URL to be set and a --live flag UI at localhost:8787: paste or import targets as CSV, edit business_context, list runs with their step timeline, view and edit a draft, approve or reject, see spend to date. Out of scope: CRM integrations, OAuth, multi-user, LinkedIn or any logged-in site automation, scheduling, deliverability warmup, analytics. Include a README with setup, an .env.example, a seed CSV of three fake targets, and one integration test that runs the full loop against a local fixture HTML page with the model call stubbed. ## Required capabilities - An LLM API key - Playwright and a machine willing to run a real browser - A search API or scraping tolerance - SMTP credentials or a mail API if you want it to actually send - Patience for step-level debugging ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Sumora. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Sumora indie build ## Goal Build the smallest trustworthy replacement for the core Sumora workflow for one developer or a tiny team. ## Scope A local agent loop that takes a target company or list, researches it with search plus a headless browser, drafts a personalized outreach message against your stored business context, and queues it for your approval before sending. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through - Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift - Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person - Cost control and model routing, so one runaway loop does not become a surprise bill - Deliverability and sending reputation work, which is its own unglamorous specialty If those capabilities are essential, use Sumora instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local, single-user AI outreach agent runner. No accounts, no cloud, no telemetry. Stack: TypeScript, Node 20, better-sqlite3 for storage, Playwright for browsing, Hono for a tiny local HTTP server, and a plain server-rendered HTML UI with htmx. No React, no Next, no ORM. Secrets in .env: OPENAI_API_KEY, SMTP_URL. Data model in SQLite: - business_context: freeform notes about my company, offer, tone, and hard rules (one editable blob) - targets: company name, domain, contact name, contact email, status - runs: target_id, state (queued, running, needs_approval, approved, sent, failed), created_at - steps: run_id, index, tool, input, output, error, tokens, cost_cents - drafts: run_id, subject, body, revision Agent loop per target, each step written to the steps table before and after execution so a crashed run is resumable: 1. fetch the target's homepage and one about or pricing page with Playwright, extract readable text 2. summarize what the company does and one specific hook 3. draft a short outreach email using business_context plus the hook 4. run a self-check pass: is the claim supported by the fetched text, is any name or fact invented, is it under 150 words 5. set state to needs_approval and stop Hard rules to implement, not just mention: - nothing is ever sent without an explicit approve click in the UI - per-run and per-day cost ceilings from .env, abort the loop when exceeded - exponential backoff with max 3 attempts on fetch and model calls, then mark the step failed and leave the run resumable - a resume command that picks up any run stuck in running and replays from the first incomplete step - dry-run mode is the default; sending requires SMTP_URL to be set and a --live flag UI at localhost:8787: paste or import targets as CSV, edit business_context, list runs with their step timeline, view and edit a draft, approve or reject, see spend to date. Out of scope: CRM integrations, OAuth, multi-user, LinkedIn or any logged-in site automation, scheduling, deliverability warmup, analytics. Include a README with setup, an .env.example, a seed CSV of three fake targets, and one integration test that runs the full loop against a local fixture HTML page with the model call stubbed. ## Required capabilities - An LLM API key - Playwright and a machine willing to run a real browser - A search API or scraping tolerance - SMTP credentials or a mail API if you want it to actually send - Patience for step-level debugging ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Sumora. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Sumora product brief ## Problem The visible surface, a prompt box that produces a researched, personalized outreach message, is a one-sitting build. What takes real work is everything that keeps an agent from quietly going insane on step seven: persistent memory about your business and each contact, retries, browser sessions that survive logins and captchas, cost ceilings, and a human approval gate before anything is actually sent. For one person automating their own pipeline, you can get to genuinely useful in a weekend because you are allowed to be the approval step and the error handler. The gap widens fast the moment you want it unattended, multi-user, or connected to a real CRM and mailbox over OAuth. The failure mode also matters: a broken personal script wastes your evening, a broken agent emails the wrong prospect from your domain. ## Product outcome A local agent loop that takes a target company or list, researches it with search plus a headless browser, drafts a personalized outreach message against your stored business context, and queues it for your approval before sending. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - An LLM API key - Playwright and a machine willing to run a real browser - A search API or scraping tolerance - SMTP credentials or a mail API if you want it to actually send - Patience for step-level debugging ## Explicit non-goals for v1 - Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through - Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift - Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person - Cost control and model routing, so one runaway loop does not become a surprise bill - Deliverability and sending reputation work, which is its own unglamorous specialty ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build a local, single-user AI outreach agent runner. No accounts, no cloud, no telemetry. Stack: TypeScript, Node 20, better-sqlite3 for storage, Playwright for browsing, Hono for a tiny local HTTP server, and a plain server-rendered HTML UI with htmx. No React, no Next, no ORM. Secrets in .env: OPENAI_API_KEY, SMTP_URL. Data model in SQLite: - business_context: freeform notes about my company, offer, tone, and hard rules (one editable blob) - targets: company name, domain, contact name, contact email, status - runs: target_id, state (queued, running, needs_approval, approved, sent, failed), created_at - steps: run_id, index, tool, input, output, error, tokens, cost_cents - drafts: run_id, subject, body, revision Agent loop per target, each step written to the steps table before and after execution so a crashed run is resumable: 1. fetch the target's homepage and one about or pricing page with Playwright, extract readable text 2. summarize what the company does and one specific hook 3. draft a short outreach email using business_context plus the hook 4. run a self-check pass: is the claim supported by the fetched text, is any name or fact invented, is it under 150 words 5. set state to needs_approval and stop Hard rules to implement, not just mention: - nothing is ever sent without an explicit approve click in the UI - per-run and per-day cost ceilings from .env, abort the loop when exceeded - exponential backoff with max 3 attempts on fetch and model calls, then mark the step failed and leave the run resumable - a resume command that picks up any run stuck in running and replays from the first incomplete step - dry-run mode is the default; sending requires SMTP_URL to be set and a --live flag UI at localhost:8787: paste or import targets as CSV, edit business_context, list runs with their step timeline, view and edit a draft, approve or reject, see spend to date. Out of scope: CRM integrations, OAuth, multi-user, LinkedIn or any logged-in site automation, scheduling, deliverability warmup, analytics. Include a README with setup, an .env.example, a seed CSV of three fake targets, and one integration test that runs the full loop against a local fixture HTML page with the model call stubbed. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Sumora capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Sumora indie build ## Goal Build the smallest trustworthy replacement for the core Sumora workflow for one developer or a tiny team. ## Scope A local agent loop that takes a target company or list, researches it with search plus a headless browser, drafts a personalized outreach message against your stored business context, and queues it for your approval before sending. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through - Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift - Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person - Cost control and model routing, so one runaway loop does not become a surprise bill - Deliverability and sending reputation work, which is its own unglamorous specialty If those capabilities are essential, use Sumora instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build a local, single-user AI outreach agent runner. No accounts, no cloud, no telemetry. Stack: TypeScript, Node 20, better-sqlite3 for storage, Playwright for browsing, Hono for a tiny local HTTP server, and a plain server-rendered HTML UI with htmx. No React, no Next, no ORM. Secrets in .env: OPENAI_API_KEY, SMTP_URL. Data model in SQLite: - business_context: freeform notes about my company, offer, tone, and hard rules (one editable blob) - targets: company name, domain, contact name, contact email, status - runs: target_id, state (queued, running, needs_approval, approved, sent, failed), created_at - steps: run_id, index, tool, input, output, error, tokens, cost_cents - drafts: run_id, subject, body, revision Agent loop per target, each step written to the steps table before and after execution so a crashed run is resumable: 1. fetch the target's homepage and one about or pricing page with Playwright, extract readable text 2. summarize what the company does and one specific hook 3. draft a short outreach email using business_context plus the hook 4. run a self-check pass: is the claim supported by the fetched text, is any name or fact invented, is it under 150 words 5. set state to needs_approval and stop Hard rules to implement, not just mention: - nothing is ever sent without an explicit approve click in the UI - per-run and per-day cost ceilings from .env, abort the loop when exceeded - exponential backoff with max 3 attempts on fetch and model calls, then mark the step failed and leave the run resumable - a resume command that picks up any run stuck in running and replays from the first incomplete step - dry-run mode is the default; sending requires SMTP_URL to be set and a --live flag UI at localhost:8787: paste or import targets as CSV, edit business_context, list runs with their step timeline, view and edit a draft, approve or reject, see spend to date. Out of scope: CRM integrations, OAuth, multi-user, LinkedIn or any logged-in site automation, scheduling, deliverability warmup, analytics. Include a README with setup, an .env.example, a seed CSV of three fake targets, and one integration test that runs the full loop against a local fixture HTML page with the model call stubbed. ## Required capabilities - An LLM API key - Playwright and a machine willing to run a real browser - A search API or scraping tolerance - SMTP credentials or a mail API if you want it to actually send - Patience for step-level debugging ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Sumora product brief ## Problem The visible surface, a prompt box that produces a researched, personalized outreach message, is a one-sitting build. What takes real work is everything that keeps an agent from quietly going insane on step seven: persistent memory about your business and each contact, retries, browser sessions that survive logins and captchas, cost ceilings, and a human approval gate before anything is actually sent. For one person automating their own pipeline, you can get to genuinely useful in a weekend because you are allowed to be the approval step and the error handler. The gap widens fast the moment you want it unattended, multi-user, or connected to a real CRM and mailbox over OAuth. The failure mode also matters: a broken personal script wastes your evening, a broken agent emails the wrong prospect from your domain. ## Product outcome A local agent loop that takes a target company or list, researches it with search plus a headless browser, drafts a personalized outreach message against your stored business context, and queues it for your approval before sending. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - An LLM API key - Playwright and a machine willing to run a real browser - A search API or scraping tolerance - SMTP credentials or a mail API if you want it to actually send - Patience for step-level debugging ## Explicit non-goals for v1 - Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through - Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift - Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person - Cost control and model routing, so one runaway loop does not become a surprise bill - Deliverability and sending reputation work, which is its own unglamorous specialty ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build a local, single-user AI outreach agent runner. No accounts, no cloud, no telemetry. Stack: TypeScript, Node 20, better-sqlite3 for storage, Playwright for browsing, Hono for a tiny local HTTP server, and a plain server-rendered HTML UI with htmx. No React, no Next, no ORM. Secrets in .env: OPENAI_API_KEY, SMTP_URL. Data model in SQLite: - business_context: freeform notes about my company, offer, tone, and hard rules (one editable blob) - targets: company name, domain, contact name, contact email, status - runs: target_id, state (queued, running, needs_approval, approved, sent, failed), created_at - steps: run_id, index, tool, input, output, error, tokens, cost_cents - drafts: run_id, subject, body, revision Agent loop per target, each step written to the steps table before and after execution so a crashed run is resumable: 1. fetch the target's homepage and one about or pricing page with Playwright, extract readable text 2. summarize what the company does and one specific hook 3. draft a short outreach email using business_context plus the hook 4. run a self-check pass: is the claim supported by the fetched text, is any name or fact invented, is it under 150 words 5. set state to needs_approval and stop Hard rules to implement, not just mention: - nothing is ever sent without an explicit approve click in the UI - per-run and per-day cost ceilings from .env, abort the loop when exceeded - exponential backoff with max 3 attempts on fetch and model calls, then mark the step failed and leave the run resumable - a resume command that picks up any run stuck in running and replays from the first incomplete step - dry-run mode is the default; sending requires SMTP_URL to be set and a --live flag UI at localhost:8787: paste or import targets as CSV, edit business_context, list runs with their step timeline, view and edit a draft, approve or reject, see spend to date. Out of scope: CRM integrations, OAuth, multi-user, LinkedIn or any logged-in site automation, scheduling, deliverability warmup, analytics. Include a README with setup, an .env.example, a seed CSV of three fake targets, and one integration test that runs the full loop against a local fixture HTML page with the model call stubbed. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Sumora capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent · this prompt is generated from the build plan · improve it via PR
Because the demo is the easy 20 percent and the remaining 80 percent is failure handling nobody enjoys writing. A business paying for this is buying the assumption that the agent will not send the wrong message to the wrong contact at 2am, and that when something does break, someone else's on-call rotation deals with it. A solo operator who is happy to review every draft can absolutely self-host their version and get most of the leverage. A team of ten with a shared pipeline and a reputation to protect generally decides that the subscription is cheaper than owning an agent orchestration layer.
xUnattended reliability: retries, resumable runs, and recovery when a step fails halfway through
xMaintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift
xSandboxed execution and guardrails so a confused agent cannot take a real action against a real person
xCost control and model routing, so one runaway loop does not become a surprise bill
xDeliverability and sending reputation work, which is its own unglamorous specialty
Nothing worth pointing at. That's why the prompt exists.
share on X ↗"I just replaced Sumora ($79.99/mo) with one prompt"
Vibecode Sumora
Kinda. The core of Sumora is buildable in a weekend with the prompt on this page, but there are real gaps: Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through, Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift. Read the honest list above before committing.
How much does Sumora cost?
Sumora costs about $79.99/month (Starter, checked 2026-08-18), which is $959.8799999999999 per year.
What do I lose by replacing Sumora?
Honestly: Unattended reliability: retries, resumable runs, and recovery when a step fails halfway through; Maintained integrations and OAuth to CRMs, mailboxes, and calendars, plus keeping them working when those APIs shift; Sandboxed execution and guardrails so a confused agent cannot take a real action against a real person; Cost control and model routing, so one runaway loop does not become a surprise bill; Deliverability and sending reputation work, which is its own unglamorous specialty. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Sumora?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.