LayoutCloud: A Browser-Native Layout Tool for Professional Publishing

Architecture, engineering, and construction firms (AEC, the people who design and build the physical world) win work by writing proposals. The content that fills those proposals already lives inside the firm: staff résumés, past projects, references, compliance answers to a request for proposal. The tools have no idea it does. Teams rebuild the same material by hand in InDesign, route it for review over email, and mark it up in Bluebeam. Nothing sits in the gap between Figma, with great collaboration and weak print, and InDesign, with great print and a dated interface.

A working browser-based editor now runs, and it reaches well past a layout skeleton. It has a true US Letter page model, a configurable column grid, smart snapping with alignment guides, and text that flows through linked frames and multi-column stories. On top of that sit first-class tables (typed columns, header and total rows, merged cells), images with fit and crop, layout containers with a resizable grid and content-driven reflow, template pages, facing-page spreads with a cover option, page management, and full undo and redo. Type is real: a searchable library of open fonts, plus custom font upload, and text that embeds correctly in the exported PDF. Documents save and reopen, and export as vector PDFs with selectable text and subset-embedded fonts.

The AEC layer is real too. A structured content library of people, projects, firms, and assignments binds to the page through data-bound blocks (a résumé, a project sheet, a team roster), and merges one page per record, the InDesign data-merge pattern aimed at proposals. An editable brand kit holds a firm's colors, type, and logos, and a multi-tenant content backend lets an agency manage many client brands from one place. The tool is heading into its first real test on live proposals, starting with a full rebuild of a real AEC proposal to prove it can carry professional work end to end. Work in progress, and honest about it.

I set out to build the tool I kept watching people struggle without. I run marketing and technology at an agency that serves AEC firms, and proposals are how those firms stay alive. Win the proposal, win the project. A proposal looks like a document, but it is really a database wearing a document costume. Behind every polished PDF sits structured content that gets retyped for every new pursuit. (I have watched a specialist rebuild the same principal's bio for the fifth time. Nobody should have to do that to a living person.)

The big idea came first. A browser-native publishing tool with Figma's collaboration and InDesign's print quality, so teams could stop emailing PDFs and duplicating files. Then reality narrowed it. Replacing all of InDesign at once is a proven way to lose, so I chose a beachhead: AEC proposal production. It is deadline-driven, the content is structured, and the pain is sharp enough that people will try something new.

My role was to define the product and direct the build. I owned the research, the product decisions, the interaction design, and the specifications. I do not write production code. I write the specs and direct AI coding agents to implement them, then review the result on screen the way I would review any design. More on that below, because it shaped how fast this moved.

The research started before any building. I built a competitive analysis across 19 tools, from proposal software to design tools to RFP automation, and scored where each one broke down. I checked my read against designers directly, pulling sentiment from forums, Reddit, and Slack groups, because I wanted this driven by evidence rather than only my own experience. I studied tools well outside desktop publishing, including Miro, Notion, Pitch, Webflow, and Penpot, to learn how modern interfaces stay simple while doing complex work. And I went deep on the domain itself, reading real proposals and RFPs to understand how the content is actually structured.

That research produced the reframe that set the direction. The competitor is not another app. It is the entrenched habit of InDesign plus email plus Bluebeam. And the defensible value is not pixel fidelity, which many tools can approximate. It is the AEC-specific data model: proposal structure, résumé logic, and compliance mapping that no general tool understands. So the product binds the page to a structured content library. A résumé or project record lives in one place, drops onto the layout, and freezes its values only at export.

From there I designed the core of the experience. I separated navigation from contextual editing so the interface stays calm, with pages and layers in a dedicated panel and the right side reserved for whatever you have selected. I reframed collaboration around permissions and workflow rather than files, with comment-only reviewer roles for stakeholders who do not own the design software, and version history built into the document. I treated fonts as an adoption issue, because professional designers will not accept a tool that cannot use their installed type. And I held the line on scope, sending posters and one-pagers to Canva and keeping the product focused on multi-page documents, while insisting that professional table-stakes like facing pages ship early.

Then I built it. I used Magic Patterns to prototype the full content workflow, from a firm's brand kit through the editor and live data binding. In parallel, I directed Claude Code inside Cursor to build the real product and deploy it to the web. The deployed editor now runs on a true US Letter page model with per-page margins, a six-column grid, structure guides, snapping, and text threading, where a story flows across linked frames and reflows instantly as it changes.

My contributions included:

• Competitive and cross-category research across 19 tools and adjacent categories
• Community and field validation with designers and proposal teams
• Product vision, MVP scope, and beachhead definition
• Workspace and interaction design, including the panel layout and switchable workspace presets
• A collaboration model based on roles, review, and in-document version history
• Design-system decisions for type, color, and object styles
• A technology-agnostic functional specification covering styles, color, preflight, and print export
• An AEC content model that binds structured records to the page and freezes them on export
• A working, deployed prototype built by directing AI coding agents

The parts I am most proud of are the places I changed my mind.

I started certain that live co-editing had to be foundational. The research pushed back. For a lot of designers, what they actually want is a better InDesign, not a multiplayer canvas, so I demoted real-time editing from a launch requirement to a differentiator and started sketching page-level locking as a lighter middle ground. My positioning got sharper too. "Figma for print" became "an InDesign replacement," because that is the frame that describes the real job. And I still have an open tension on fonts, between using a designer's installed type seamlessly and packaging fonts so collaborators see the right thing, without redistributing licensed files. I would rather show that honestly than pretend it is solved.

I want to name this directly, because it is becoming a real design skill. I did not hand this to engineers and wait. I defined the product, wrote the specs with exact requirements, and directed AI coding agents to implement it, reviewing every result visually and correcting course. It let one designer take an idea to a deployed, working build in a single week, and it moved the craft up a level, from arranging pixels to defining the system and steering the build.

The rollout starts small and specific. First the proposal specialists at my own agency, using it on real pursuits. Then a regional engineering firm as a design partner, testing it against their own work. The question I am building to answer is not technical. It is whether teams will actually leave InDesign, or keep coping with it the way they have for years. That is the assumption worth testing, and it is next.