Struqo

Struqo is a design tool for small timber structures: carports, sheds, terraces. You draw in a floor plan, place posts, beams, rafters, studs, cladding and roofing, choose a wood species, and the model exists once. Every other drawing derives from it: elevations, sections and detail sheets live in one project, listed in a drawings panel on the left. Dimensions are added automatically. A north setting on the project drives the compass directions of elevations and sections, and each sheet carries its own scale.

The wood species shows the same way in 2D, 3D and print. The bill of materials is generated from the drawing and lists cross sections, cut lengths and fasteners, with subtotals per cross section, exportable as PDF or CSV. The plan set prints as a multi-page PDF with a title block on every sheet: scale, sheet count, version tag, and a note that structural sizing stays with a qualified planner.

The design system is public. struqo.app/styleguide renders tokens, building blocks and voice straight from the code. The token values on that page are read live from the CSS custom properties of the app, so they match the product. Tokens come in two tiers, primitives and semantic names, and components consume only the semantic tier. A lint hook rejects hardcoded colours outside the token file.

Building blocks follow Brad Frost's atomic hierarchy, from foundations and atoms to templates and pages. One catalog file in the code records each block's layer, status, code path and the Figma set that mirrors it. The styleguide navigation is built from that file and the Figma pages reference it. Direction of truth is one way: code changes first, Figma and the styleguide follow, and a script compares the Figma variables against the code in light and dark.

Three tools sit around the code. FigJam carries the strategy map, regenerated every week from a Markdown file and Linear. Figma holds the library, with variable collections for primitives, semantic colours in light and dark, and scale, and one page per layer. Claude Design works on a bundle of the real components, compiled CSS and fonts that a sync script builds from the repository, so explorations start from the shipped building blocks.

Building a canvas application with AI taught me where the collaboration works well and where it breaks down. Boilerplate, test scaffolding, state management wiring, CSS layout: AI handles these reliably. Complex spatial logic (canvas coordinate transforms, hit detection, snap-to-grid behavior): AI needs precise context and frequent correction.

The bigger lesson is about process. AI delivers reliably when the work around it is disciplined. Every change starts as a Linear story with a job to be done, a persona and acceptance criteria, and no code is written without an issue. A session owns one merge request, never two. A merge skill walks a fixed sequence of gates before anything reaches main: preflight, merge, verify, push, reconcile the issue, clean up, log. The skill calls existing checks instead of re-implementing them, and it measures where it could guess: test counts, build stamps, timestamps.

I measure the collaboration itself. One story was tracked at 25 interruptions and 10.9 hours of waiting, most of it caused by a shell command pattern that kept tripping the permission system. Fixing that one pattern removed most of the waiting. The portfolio value is the process: one person shaping a workflow in which AI ships product reliably, session after session.