Brief Builder

Brief Builder is a conversational AI tool that guides creative professionals through the briefing process and produces a complete, handover-ready document at the end. Built in six weeks on a no-code stack, it serves as both a useful product and a proof that design and product thinking can be shipped without engineering resource.

The Problem

The quality of a creative brief determines almost everything that follows. Most people know what they want to achieve but don't know what a designer, photographer, or set builder actually needs in order to deliver it. The gap isn't knowledge it's the absence of a structured conversation that asks the right questions in the right order.

Existing solutions are either static forms that feel generic, or expensive briefing workshops that require scheduling. There was a gap for something conversational, immediate, and discipline-specific.

Goals

• Validate real demand for an AI briefing tool before investing in infrastructure.
• Demonstrate the ability to design, build, and ship a product end-to-end independently.
• Keep infrastructure costs at zero during the trial period.
• Collect meaningful behavioural data to inform next steps.

My Role

Solo product design, UX, system prompt engineering, no-code build, infrastructure setup, and analytics. Every decision from the conversation design to the Cloudflare security configuration was made and implemented without a team.

The Stack

The constraints were clear from the start: no backend, no servers, no engineering overhead. The stack that emerged was Webflow for the front end, Make.com to orchestrate AI calls and log usage, Google Gemini as the AI model, and a Cloudflare Worker sitting in the middle as a security proxy. Data persistence uses Make's built-in Data Store. The whole system is stateless no conversation history is stored anywhere.

Process

Conversation design first. Before any UI was built, I mapped the briefing journey for each creative discipline what a graphic designer needs to know is structurally different from what a set designer, lighting designer, or CAD technician needs. This produced 24 discipline-specific system prompts across six sectors, each tuned to the specific deliverables, constraints, and vocabulary of that role. Writing these took longer than any of the technical work.

Progressive disclosure in the UI. The tool works through areas one or two at a time rather than presenting everything at once. The interface is deliberately minimal a chat window, a discipline selector, a reference link input so nothing competes with the conversation itself.

Stateless architecture. Each message carries the full conversation history as a structured array. Gemini receives complete context on every request and responds in turn. This eliminates the need for session storage or a database while keeping the conversation coherent across 10–15 exchanges.

Security without a backend. Putting a webhook URL directly in client-side code exposes it publicly. A Cloudflare Worker acts as a proxy the browser calls the Worker, the Worker forwards the request to Make with a secret header, Make processes it. The webhook URL never appears in the browser. Rate limiting is handled inside the Worker using KV storage: 15 requests per minute per IP.

Solving the 50,000 character problem. Webflow has a hard limit on embed code length. With 24 discipline-specific prompts, the embed sat at 83,000 characters  well over the limit. The fix was to move all prompt data to an external JavaScript file served from Cloudflare's KV storage, loaded at runtime. The embed dropped to 31,000 characters and prompt updates now happen outside Webflow entirely.

Behavioural tracking. Every session generates an anonymous UUID. Four events are logged: conversation started, discipline selected, brief completed, and copy clicked. Drop-off is inferred any session with a start event but no completion. The data answers the one question that matters: are people actually using this?

Key Decisions

• No backend. The decision to keep everything serverless kept costs at zero during validation and forced a discipline around what actually needed to be built vs what was habit.
• The system prompt is the product. Generic prompts produce generic output. A prompt that knows a Props Designer needs to distinguish hero props from dressing props, items that need to break or be consumed, and hire vs build decisions produces something a working professional would actually use.
• Mobile bottom sheet over dropdown. On mobile, a standard dropdown triggers the native keyboard before the user has made a selection. Replacing it with a readonly input that opens a bottom sheet on tap solved this no keyboard until the user explicitly wants to search within the sheet.
• String parsing over JSON.parse. Gemini replies contain real language quotes, em dashes, apostrophes that break standard JSON parsing when assembled by Make. Rather than fight the escaping problem, the browser parses the raw response as text using string indexing. Inelegant but completely robust.

Outcomes

• Launched and live at laurencetaylor.uk/brief-gen within six weeks of starting.
• 24 disciplines across 6 creative sectors, each with a tailored conversational brief.
• Full session tracking in place completion rates, discipline distribution, and copy usage visible from day one.
• Embed under 50,000 characters with all prompt data externalised and independently updatable.
• Zero backend infrastructure no servers, no database, no ongoing hosting cost.

Reflections

This project confirmed that the hardest part of building an AI product isn't the AI it's the conversation design. The model is capable; what it produces is only as good as how well you've thought through what needs to be asked, in what order, and for whom.

It also reinforced that constraints accelerate decisions. Having no backend forced a clarity about what actually needed to exist. Every module in the Make scenario, every line of Worker code, every field in the data store exists because it had to not because it seemed like a good idea at the time.

The trial ran through to the end of June. It got some traction and genuine interest from people suggesting it does have value but not enough as a product on its own. I have some ideas on complimentary tools that could work in conjunction with this that combined could make this a more appealing proposition.