Content contributors were writing in long-form prose, but the bot-training and in-app content pipelines needed clean, structured text. I built a browser-based editor that lets a contributor paste raw copy, run it through an AI formatting pass, and see exactly how it will render, so structure gets fixed before the handoff instead of after.
View tool preview →Context
I needed content that was clean, structured, and ready to drop into bot-training sets and in-app responses. Most contributors wrote in long-form prose, understandable to a person, but misaligned with what a structured interface expects. The mismatch showed up downstream: inconsistent output in production tools, manual rework by design and dev, and a constant tension between giving contributors creative freedom and holding the line on technical constraints.
Problem
Contributors had no way to see how their writing would actually render once it hit a structured interface, so problems only surfaced after handoff, when it was already someone else's job to fix. I needed a tool that closed that gap directly: let a contributor write naturally, then show them the structured result immediately, with AI doing the reformatting work instead of a person doing it by hand. 1Decision 01Contributors couldn't predict how free-form text would map onto a structured layout until a developer had already built it. Chose: I built a client-side editor with Quill.js for entry, plus import support for .docx (via Mammoth.js) and .xlsx (via SheetJS), so contributors could bring content from wherever they already wrote it. Traded: Supporting multiple import formats meant maintaining three separate parsing paths instead of one, but it met contributors where they already worked instead of forcing a new habit. 2Decision 02A single format preview wasn't enough, since the same content needed to work as HTML, Markdown, and a styled card. Chose: I built instant view-switching between HTML, Markdown, and card previews, using Showdown.js, Markdown-it, and Prism.js for rendering and syntax highlighting. Traded: Three render paths to keep in sync is more surface area than one, but it meant a contributor could catch a formatting issue in whichever output actually mattered for their use case. 3Decision 03Manually restructuring prose into headers, lists, and consistent formatting was the exact rework the tool was meant to eliminate. Chose: I added a two-step AI pass: a first system prompt applies structure (lists, headers), and a second checks the result against formatting requirements, so contributors focus on writing while the tool handles structure. Traded: Two sequential AI calls added latency versus one, but a single pass produced less reliable structure in testing. 4Decision 04Contributors needed to bring their own AI provider without me building a backend to manage keys. Chose: I made the tool entirely client-side, with users supplying their own GPT-4o or Claude 3.5 Sonnet API key stored in the browser, and adjustable model parameters like temperature. Traded: No server means no shared usage or centralized cost control, but it kept the tool lightweight and avoided handling anyone's credentials myself.
I iterated after early user testing: adding PNG export via html2canvas so a contributor could capture and share a card preview, and streamlining the API key and model-parameter inputs so switching providers didn't require re-reading instructions each time.
Result
The tool wasn't rolled out org-wide, but a small network of content collaborators used it to preview chatbot responses and content blocks, format writing to cut down on dev handoffs, and get a feel for design-system constraints without sitting through formal training. It also caught formatting issues during internal review instead of after content shipped.
It's a scrappy, narrow tool built for a specific audience, and it proved a point I keep coming back to: a designer who can build doesn't need a full product cycle to remove a recurring friction from a team's workflow.