AI-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 — designed to move them from idea to proposal to closed deal, faster and more intelligently.

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 is continuously working in the background: structuring content, adapting tone, tracking engagement behavior, and recommending next actions.

The platform covers the full commercial workflow — AI proposal generation with tone and format controls, client engagement analytics with session recordings, AI follow-up recommendations based on engagement signals, custom branding with professional PDF exports, quote-to-invoice with Stripe billing, and full English and Spanish support.

Instead of treating AI as a feature, Waco3 introduces an AI layer across the entire product experience. This layer sits between user intent and output, powering three core systems.

Users don't generate "text" — they generate structured proposals. The system takes minimal input — project type, scope bullets, client context, desired tone — and produces modular sections (scope, pricing, timeline) with controlled outputs aligned to the editor structure. Tone and format adapt to the user's context.

Why modular sections? During the 2020 research, I found that freelancers didn't write proposals linearly — they jumped between scope and pricing constantly, adjusting one based on the other. A monolithic AI output would force them back into the linear workflow they were already escaping. Modular generation lets them regenerate just the pricing section after changing scope, without touching the rest.

The AI system is designed as an abstraction layer — different models and strategies can evolve without changing the product experience. Structured prompting ensures predictable outputs. Retrieval mechanisms personalize content based on past work and context. Model behavior is tested and refined across real proposal scenarios. The goal was not to experiment with AI — it was to make AI reliable inside a production workflow.

AI output is never final. Everything lands directly in the editor, fully editable, with no friction between AI-generated content, manual edits, and regeneration of individual sections. There is no modal, no confirmation step, no 'accept AI suggestion' gate. The output lands and the user owns it immediately.

Why edit-in-place? Early prototyping showed that the moment AI content appeared in a read-only preview or a confirmation modal, users treated it as something the tool wrote — not something they wrote. Trust collapsed. Removing the 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 fact, the editor highlights it for confirmation — uncertainty is surfaced, not hidden.

Why streaming? Streaming is a UX feature, not a performance optimization. The perceived speed of token-by-token generation earns user patience for the parts that actually take time. Without streaming, a 6-second generation feels broken. With it, users start reading and editing before the AI finishes — turning wait time 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 — 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 that raw data into plain-language insights, actionable follow-ups, and context-aware recommendations.

"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 operates on two parallel design systems — one for the platform, one controlled by the user. This 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 enforces consistency across the product experience.

A second system, controlled by the user, defines how their proposals look — branding (colors, typography, spacing), proposal appearance, and PDF output styling. Powered through CSS variables at the root level, modular section architecture, and dynamic layout behavior.

Why dual systems? A single design system would mean 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 them separate means every document feels custom-built without breaking system consistency. The user's 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 but 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 crafted to spark curiosity — short-form video that felt more like a creative project than an ad. The music, pacing, and visual language were designed to resonate with the Latin American creative community specifically, not a generic startup audience.

The campaign generated significant early sign-ups before the product was publicly available. More importantly, it validated that the audience I had researched in 2020 was still there — freelancers and creatives who wanted better tools but also wanted 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. But faster creation was never the real goal — the follow-up recommendations turn engagement data into closed deals rather than into 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.