BuildStax: From First Call to Live Site

Inspiration

A small business that needs a website doesn't need another page generator. It needs someone who understands the business, gets the owner's vision, and actually follows through on revisions. Right now, that whole journey is scattered across lead lists, phone calls, inboxes, payment links, website builders, and tools that forget everything as soon as you switch between them.

We built BuildStax to pull that entire journey into one accountable, self-correcting agent loop.

What it does

BuildStax is a secure, login-protected command center that walks a local business all the way from first contact to a finished website:

Find and qualify leads — businesses with a weak or missing web presence.
Call first. Log the outcome, and permanently honor any do-not-call request.
Price it consistently. The system tests challenger versions of its pitch and keeps a record of what converts, but it can never quote below a hard floor: whichever is higher, the operator's configured minimum or twice the estimated delivery cost.
Turn the call into real scope — requirements, a quote, and a Stripe-hosted checkout link.
Build only after payment is verified, then publish a private, token-protected preview for the customer.
Close the loop. Collect structured feedback, track revisions, and keep sending the project back for review until the customer accepts delivery.

Throughout, the operator can see pipeline health, what's due, revenue, campaign performance, provider readiness, every state change, and the evidence behind each automated action.

The self-correcting loop

BuildStax treats autonomy as a state machine, not a chatbot with broad permissions:

Plan: Check the business's current stage, the campaign policy, remaining spend allowance, and the next valid action.
Act: Either pick a fresh capability through Zero, make a guarded change to the workflow, or hand the work off to the platform's build agent.
Observe: Record what happened — call outcomes, provider receipts, payment events, preview feedback, delivery results.
Correct: Revise the challenger pitch, the project requirements, or the build itself — without ever touching pricing rules, consent records, or deployment boundaries.

Everything a customer submits is treated as untrusted input. It can describe what they want the site to look like, but it can never change credentials, which provider gets used, spend caps, deployment targets, or the system's own instructions.

How we built it

Next.js 16, React 19, TypeScript, Tailwind CSS, Radix UI, and Lucide power the responsive operator workspace and the public preview pages.
InsForge (Postgres + Auth) is our system of record. Tenant-scoped row-level security, SQL constraints, guarded database functions, duplicate protection, and audit logs keep every change server-side and traceable.
Nexla ingests agent events into a transformed dataset and exposes it through governed MCP tools, giving the system durable memory — reads come back with receipts and traces instead of being a black box.
Zero.xyz is our live capability router. Instead of relying on cached data, BuildStax runs a fresh search → get → fetch → review cycle every time, checks for a usable schema, filters by health and price, enforces spend caps per intent, and logs the run ID and review for every call.
Pomerium Zero provides the identity-aware security boundary around the operator dashboard and the agent infrastructure behind it.
AkashML runs the pitch-writing model, generating schema-constrained challenger pitches that a human operator always reviews before anything goes out.
Stripe handles hosted checkout. Only a signed webhook plus a validating database trigger can mark a payment as real and move a project forward — a browser redirect alone is never treated as proof of payment.
Drizzle with file-backed SQLite gives us an explicit local testing mode, clearly separated from production — never a silent fallback.
Vitest, Playwright, and Axe cover the workflow rules, auth boundaries, price-floor enforcement, feedback validation, health checks, desktop/mobile layout, and accessibility.

Challenges we ran into

The hard part was never generating a web page. It was building a loop that could improve itself without quietly slipping past its own business and safety rules.

Marketplace providers change constantly, so caching an endpoint or a price isn't safe — everything has to be fetched fresh. Payment events can arrive more than once, so idempotency and ownership checks have to live in the database, not just the app logic. Customer-submitted text can contain prompt injection, so content and control have to stay strictly separate. We also made sandbox-versus-live status explicit everywhere, so a polished UI never pretends an external provider is live when it isn't.

Accomplishments we are proud of

BuildStax now runs the full operator workflow end to end: guarded transitions from discovery through delivery, permanent do-not-call handling, price-floor enforcement, fulfillment that only triggers on verified payment, customer previews, revision tracking, visible integration health, and a tested mobile experience.

We also ran the Zero discovery path with real, capped spending: a $0.01 search for Oakland businesses returned 25 records, 16 of which had no website listed.

What we learned

A self-correcting agent needs three things more than it needs a bigger prompt: a durable record of what it has observed, hard rules it can never negotiate away, and evidence a human operator can audit after the fact.

What's next

Next, we're completing the Plivo and OpenAI Realtime phone bridge, moving the website-building worker into its own dedicated, least-privileged environment, adding outcome-driven pitch experiments, and shipping deployment adapters that keep customer domains and credentials completely outside the generated site's control plane.