EchoMe

Turn conversations into production-ready web apps with AI orchestration

Comment

Inspiration

We've all felt the frustration: you have 24 hours to build, but spend the first 8 on auth boilerplate, database setup, and deployment configs before touching actual features. Every hackathon, every side project, same story—70% setup, 30% product. We got curious: what if you could just talk to your computer and watch a working app materialize? Our solution was to create EchoMe: voice-driven development that turns "build me a task tracker with dark mode and google login" into deployed, production-ready code, so you can focus on what makes your idea unique, not npx create-next-app for the hundredth time.

What it does

EchoMe turns conversations into deployed web apps. you describe what you want—"build a task tracker with dark mode and google login"—and watch a complete, production-ready react/next.js app materialize with real routing, data models, auth, and ui components you can edit, export, and ship.

  • Voice → app: you describe features ("task tracker with dark mode and google login"). EchoMe turns that into a live preview and a real project.
  • Real code generation: produces a clean react/next.js codebase (tailwind), not screenshots. you can export, edit, and re-import.
  • Component-aware building: chooses and composes accessible components (forms, tables, modals, charts) and binds them to state.
  • Data modelling: infers entities from your description ("task, project, user"), creates schemas, seed data, and crud routes.
  • Auth in one line: adds email/password or oauth (google/github) per your prompt. actions & workflows: hooks buttons to server actions (e.g., "generate pdf invoice", "send email on submit").
  • Templates as starting points: landing page, website, portfolio, blog, ecommerce, photography—then customize by voice.
  • Deployment built-in: one command to ship to vercel (or export a zip). iterate conversationally: say "make the cta primary, add pricing section, swap hero image, shorten copy" → instant diffs.
  • Source-of-truth history: every change is a patch; you can inspect, revert, or cherry-pick. plugin surface: bring your own component library, rest/graphql endpoint, or design tokens; EchoMe will honor them when generating.

How it works (under the hood)

  1. Understand: Transcribes your voice, extracts requirements (entities, pages, actions, constraints).
  2. Plan: Generates a build plan (routes, components, data layer, dependencies) and a typed schema.
  3. Build: Creates code, runs checks (type, a11y, layout), renders a live preview.
  4. Refine: Applies your follow-ups as structured diffs against the codebase.

Tech notes: React/Next.js app scaffold, Tailwind, shadcn/ui, server actions, file-based routing, Zod for schemas, lightweight ORM adapter. Model-agnostic codegen pipeline.

How we built it

  • Next.js, Tailwind, shadcn/ui for the studio interface: Clean, fast, component-driven.
  • ElevenLabs (TTS): turns system updates into natural speech back to the user.
  • API (Next.js on Vercel Functions): orchestrates everything — parses prompts, calls codegen, pushes builds, triggers deploys.
  • Claude Code: generates/edits the app’s codebase from the user’s description.
  • Daytona: hosts the working repo/workspace and runs preview builds.
  • Vercel: production hosting for the generated app.
  • Supabase: app-side auth, Postgres, and file storage.

Challenges we ran into

1) Clean isolation between our studio code and user-generated projects

Problem: We needed a way to keep EchoMe's studio (UI + API) totally separate from each user's generated repo—while still letting users peek, edit, and deploy easily.

What we tried:

  • Monorepo with apps/studio + apps/generated/* (messy boundaries, leaky tooling).
  • Git submodules / nested repos (UX pain, brittle CI).
  • Ephemeral containers (Codespaces/WebContainers) with in-browser FS (great DX, limits on build/deploy hooks).

Decision: Daytona workspaces per project: isolated repo, reproducible builds, simple Git surface.

Why it worked:

  • True process/file isolation from our studio code.
  • Git-first workflow (branch per change, diffs, PRs).
  • Easy handoff to Vercel deploys.

Lesson: Treat generated code as a first-class repo in its own sandbox. Our studio only orchestrates.

2) Daytona API limits → keep preview DB local (not Supabase)

Constraint: We couldn't make lots of outbound calls from the workspace reliably, so wiring a live external DB (e.g., Supabase Postgres) during preview added flakiness.

Workaround:

  • Use local DB in preview (SQLite/Drizzle or Prisma) with seed data.
  • Generate a dual-target data layer:
    • Preview: SQLite file + local adapters.
    • Deploy: Supabase Postgres + Storage, env-injected at build on Vercel.
  • Stub Supabase calls behind a thin repository interface so switching backends is config-only.

Result: Stable previews with zero external dependencies; seamless flip to Supabase on deploy. Lesson: Decouple "preview runtime" from "prod runtime." Keep the seam at configuration + adapters.

3) Sneaky preview bug: code wrote to one dir, preview read another

Symptom: Codegen completed, commits looked fine, but the preview never reflected changes. Root cause: We were writing files to repo/app/ while the preview process served repo/ (or vice versa). Classic path drift.

How we found it: Old-school terminal spelunking: pwd, cd, ls -la, git status, cat pages/_app.tsx —and comparing workspace logs to preview server CWD.

Fixes:

  • Standardized workspace layout: single repo root (/workspace/app), preview always runs from there.
  • Added a pre-preview sanity check: verify expected files exist, print CWD, and assert package.json path.
  • Logged absolute paths for all file writes; blocked preview if mismatch.

Lesson: Make paths explicit and verifiable. Add guardrails that fail fast with actionable logs.

What's next for EchoMe

A few ideas come to mind

  1. Performance optimization, cut codegen time, smarter caching for repeated operations, and faster preview refresh.
  2. Get Daytona premium to allows us to make external api calls to set up Supabase for users' projects, instead of a project having a local database.
  3. Bring your own component library (chakra, material-ui), design tokens, or api schemas. EchoMe should adapt to your stack, not force you into shadcn/tailwind if you don't want it.
  4. Collaborative mode, multiple people voice-editing the same project simultaneously. Perfect for pair programming or live client demos where you're iterating together in real-time.

Built With

  • claude
  • daytona
  • elevenlabs
  • next.js
  • shadcn
  • supabase
  • tailwind
  • vercel
Share this project:

Updates