# Build brief — a focused alternative to Sumora

> **Verdict:** Partly, if you narrow it · **Buildability:** 54/100 · **Category:** Automation
> **Source:** https://www.canitbevibecoded.com/sumora
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Sumora. Verify current pricing and capabilities before acting.

## Context

**Sumora** — AI agents that run multi-step business workflows like prospect research and outreach, with browser automation and integrations. It currently costs $79.99/mo.

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 focused implementation 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.

This brief describes a focused, single-operator replacement for the part of Sumora that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

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.

- Automate a small number of known workflows with logs, retries, and manual recovery.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Playwright and a machine willing to run a real browser.
- Patience for step-level debugging.

### Data and integrations

- An LLM API key.
- A search API or scraping tolerance.
- SMTP credentials or a mail API if you want it to actually send.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation 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.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- 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.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: low. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/sumora