AI-Powered Proposal PlatformAI-Powered Proposal Platform

In 2020, I researched how freelancers and creatives in Latin America create proposals. I interviewed 7 creatives, analyzed 12+ competing tools, and identified a clear gap: the market was either fast but unprofessional, or beautiful but exhausting. That research became Waco3 — the UX case study.

Five years later, the opportunity returned with AI. Freelancers were still losing deals because proposals took 3–6 hours each, and clients were still ghosting after confusing quotes. So I built the product the research had asked for.

Waco3 is not a proposal builder. It is a business layer for freelancers and creatives, built to move them from idea to proposal to closed deal, faster.

Most tools focus on document creation. Waco3 focuses on decision-making and outcomes. From the moment a proposal is generated to the moment a client engages with it, the system keeps working in the background: structuring the content, adapting the tone, tracking how the client reads it, and recommending what to do next.

The platform covers the full commercial workflow: AI proposal generation with tone and format controls, engagement analytics with session recordings, follow-up recommendations based on what the client actually looked at, custom branding with PDF export, quote-to-invoice through Stripe, and English and Spanish support across the whole product.

Instead of bolting AI on as a feature, Waco3 runs an AI layer across the entire product experience. The layer sits between user intent and output, and powers three systems.

Users don't generate "text". They generate structured proposals. The system takes a minimal input (project type, scope bullets, client context, desired tone) and returns modular sections — scope, pricing, timeline — with controlled outputs that match the editor's structure. Tone and format shift with the user's context.

Why modular sections? The 2020 research showed freelancers didn't write proposals top-to-bottom. They jumped between scope and pricing, adjusting one based on the other. A single monolithic AI output would have forced them right back into the linear workflow they were trying to escape. Modular generation means they can regenerate the pricing section after a scope change without touching anything else.

The AI system is built as an abstraction layer, so models and strategies can change without the product experience changing. Structured prompting keeps outputs predictable. Retrieval personalizes the content based on past work and context. Model behavior gets tested against real proposal scenarios. The goal was never to experiment with AI. It was to make AI reliable inside a production workflow.

AI output is never final. It lands directly in the editor, fully editable, with no separation between AI-generated content, manual edits, and regenerating an individual section. No modal, no confirmation step, no 'accept AI suggestion' gate. The output appears and the user owns it from that moment.

Why edit-in-place? Early prototyping showed that the moment AI content sat in a read-only preview or behind a confirmation modal, users treated it as something the tool wrote, not something they wrote. Trust collapsed. Removing that boundary between AI output and the user's own text was the single biggest decision for adoption. When the AI is uncertain about a number or a fact, the editor highlights it for confirmation. Uncertainty is surfaced, not hidden.

Why streaming? Streaming is a UX feature, not a performance optimization. Token-by-token generation buys patience for the parts that genuinely take time. Without streaming, a six-second generation feels broken. With it, users start reading and editing before the AI finishes. Wait time turns into work time.

The hardest part of AI UX isn't the happy path. It's every other state. Errors degrade gracefully: a model timeout falls back to a pre-written template the user can edit. Partial results are first-class. If a section fails, only that section is regenerated. Retries are explicit, so the user always knows whether they're seeing a fresh answer or a cached one.

This is where most tools stop. Once a proposal is sent, Waco3 becomes a behavioral intelligence system. It tracks time spent per section, scroll behavior, engagement patterns, and optional session recordings, then translates the raw data into plain-language insights and follow-up suggestions the user can act on.

"Your client spent 3 minutes on pricing, consider following up about budget" is more useful than a dashboard full of charts. This is where the product shifts from document tool to business tool.

Tracking is consent-first: clients see a lightweight notice on first view, and recordings are opt-in at the proposal level. The point is to help freelancers close deals, not to surveil their clients.

Waco3 runs on two parallel design systems: one for the platform, one controlled by the user. It was the hardest architectural decision in the product.

The internal UI system that powers the application: editor behaviors, layout patterns, interaction states, and AI-state handling (loading, streaming, partial results, error recovery). This system keeps the product experience consistent.

A second system the user controls. It defines how their proposals look: branding (colors, typography, spacing), proposal appearance, and PDF output styling. Built on root-level CSS variables, a modular section architecture, and dynamic layout behavior.

Why dual systems? A single design system means one of two things has to give. Either the user's brand overrides the editor UI (breaking the tool), or the tool's style overrides the user's brand (breaking the output). Keeping the two systems separate means every document feels custom-built without breaking the consistency of the editor itself. The proposal looks like them, not like Waco3, while the editor they build it in stays predictable and fast.

Before launch, I designed and produced an intrigue marketing campaign from the ground up: concept, video production, editing, and music. The goal was not to explain the product. It was to create empathy. To connect with creatives across music, design, film, photography, and illustration by showing that Waco3 was built for them, by one of them.

The campaign leaned into emotional storytelling over feature demos. Each piece was made to spark curiosity — short-form video that felt more like a creative project than an ad. Music, pacing, and visual language were tuned for the Latin American creative community specifically, not a generic startup audience.

The campaign generated meaningful early sign-ups before the product was publicly available. More importantly, it confirmed that the audience I'd researched back in 2020 was still there — freelancers and creatives who want better tools, and who also want to feel seen by the products they use.

One Next.js codebase serves both the marketing site (SSR for SEO) and the app (App Router for the interactive editor). A Node.js API layer handles auth, data, and Stripe webhooks. The AI pipeline runs as a separate service so model calls can be versioned and observed without redeploying the app. As a solo design engineer, every shared component between marketing and product is one fewer thing to keep in sync. The marketing site's pricing page and the app's plan-selection screen are literally the same component.

Research participants reported 3–6 hours per proposal in 2020. With Waco3, the same proposal takes minutes. Faster creation was never the real goal, though. The follow-up recommendations are what turn engagement data into closed deals instead of a dashboard nobody reads.

Every major design decision in Waco3 came from a specific UX problem, not a technical preference.

The gap between design and engineering is where the most interesting problems live. Building Waco3 as one person meant every tradeoff (UX, architecture, business logic, AI behavior) had to be held in one head. That constraint forced clarity.

Waco3 was built with AI tooling at every layer — not just as a product that delivers AI, but as a codebase scaffolded and iterated using it.

Tools: Claude Code · Codex · Gemini CLI · Cursor