Briefly

From messy brief to signed-off proposal

Comment

Inspiration

My team are all fresh graduates. No years of client work behind us, no mentor who's closed a hundred deals—just skills and the terrifying moment when a potential client sends you a wall of WhatsApp messages and says, "So, how much?" We learned quickly that the hard part of freelancing isn't the work. It's everything before the work: knowing which questions to ask so you don't get burned, figuring out what's actually in scope, putting a number on your own time without underselling it, and writing something that makes a client take you seriously. Experienced freelancers have that instinct. We don't—yet. So we built the tool we wished existed: something that reads the mess a client sends you, asks the questions a veteran would ask, and turns it into a proposal that protects you.

What it does

Briefly turns a messy client brief — forwarded email chains, WhatsApp dumps, voice-note transcripts — into a scoped, professional proposal in four steps:

Paste the chaos. Any format, any structure, along with an optional note about how you price. Answer what matters. Instead of generating blindly, Briefly asks 3–5 targeted questions about the things that genuinely change scope or price—the budget nobody mentioned, the deadline that's actually two deadlines, and the "small feature" that's secretly a payment integration. Every question explains why it matters. Skip any of them, and the answer becomes an explicitly stated assumption in the proposal instead of a silent guess. Get a real proposal. Streamed in live: overview, scope, a mandatory out-of-scope section (the part that prevents scope creep), deliverables, timeline, an editable pricing table with a live total, assumptions, and terms. Every section is editable inline, and any section can be regenerated with a plain-language instruction like "split the timeline into two phases." Send it. Copy it, export as PDF, or open a pre-drafted cover email.

How we built it

We started contract-first: before writing any feature code, we defined every shape that crosses the frontend/backend boundary in a single type. ts, then built stub API routes returning fake data. That let one of us build the entire wizard UI against stubs while the other built the real AI pipeline—and integration was flipping one flag per route. The stack is deliberately simple: Next.js App Router on Vercel, no database, state in React + localStorage. All the intelligence lives in three API routes powered by GPT-5.6 with structured outputs—clarify (question generation), generate (streaming proposal via an NDJSON event protocol), and refine (single-section regeneration). An AGENTS.md at the repo root kept both of our Codex sessions generating consistent code: the same conventions, the same file ownership boundaries, and the same rules. Codex was paired with programming doing the implementation. Our job became that of the senior developer specifying, reviewing plans, and verifying—every Codex task started from a written plan we approved or amended, and every result was verified against sample briefs before pushing.

Challenges we ran into

Making the model respect product invariants: "Every skipped question must become a stated assumption" and "every proposal must contain an out-of-scope section" aren't suggestions—so we enforce them server-side: proposals that violate them fail validation and trigger a retry. Section regeneration without collateral damage. Regenerating one section must never clobber the user's manual edits elsewhere, and pricing must only change when the instruction is actually about money. We ended up with a server-side heuristic that silently strips unexpected pricing changes rather than trusting the model's judgment. Streaming, properly. We stream raw deltas for the live-writing effect but only trust the final validated object—and discovered the difference between "streaming locally" and "streaming through serverless infrastructure" the practical way. Model quirks. Early runs leaked the model's self-corrections into user-facing output, and user-provided numbers would drift ("30–40 photos" becoming "20–30"). Both became explicit prompt rules with tests.

Accomplishments that we're proud of

The accomplishment we are most proud of is when we gave Briefly a messy brief one of us got from a bakery from a previous job he had issues with; they wanted a website for their business. Briefly asked about the buried payment integration, the two-deadlines-in-one problem, and who curates 2,000 photos—the exact questions he didn't ask and later caused issues for him down the line when it came to delivery day when he had a scenario of what I delivered wasn't what the client had in mind. Also, the contract-first workflow meant three people and two AI agents built this in parallel with almost zero merge conflicts, which was a first for us.

What we learned

That the highest-leverage way to work with a coding agent is to invest in the context it works inside—contracts, conventions, and rules files—rather than in longer prompts. And, honestly, we learned how proposals work. Building the tool taught us the client-communication skills we built it to compensate for.

What's next for Briefly

Proposal history and templates learned from your past projects, brief input from uploaded files and voice notes, multi-currency support, and a shareable client-facing proposal link with accept/comment actions. Longer-term: closing the loop — when a client replies with changes, Briefly updates the scope and flags what the change does to the price.

Built With

Share this project:

Updates