How Closegrain Cabinetmakers was made

Palette — workshop-afternoon oak

Every colour is argued from the bench at 4pm. This ground-plus-red-brown pairing deliberately lives near the most common AI-default palette (cream + terracotta + high-contrast serif), so the spec drew three hold-the-line rules: the accent is jarrah heartwood — deeper and browner than terracotta, argued from WA's own timber; the display face is a slab, never a high-contrast serif; and the ground carries a visible warm grain texture (a tiled data-URI SVG of faint plane strokes and knots), not gallery cream.

Type

The signature — Cabinet Configurator

Project chips (kitchen / robe / laundry / vanity), kitchen layout chips (galley / L / U / island), a 4–12 lm slider and finish chips (melamine / 2-pac / veneer) drive a procedural SVG maker's plan: plan view plus an elevation strip. Carcasses hatch in (a 45° SVG pattern), 600 mm module lines divide each run, the door-face line sits on the working edge, and jarrah dimension lines with architectural tick ends annotate each segment. The elevation strip draws one door per 600 mm module in the chosen finish — melamine flat, 2-pac with a sheen gradient and highlight line, veneer with a drawn-grain pattern overlay — under a grey benchtop bar labelled "stone — separate trade".

Implementation notes: run geometry is computed in metres per layout, converted at 36 px/m, bounding-boxed and centred, and the dynamic <g> is rebuilt as an SVG string on every input. Positioning lives on outer <g transform> attributes; the hatch-in and dim fades are CSS opacity animations on separate inner elements that set no competing presentation attribute (the W16/W17 rule). No stroke-dash draw-ins are used anywhere, which sidesteps the round-cap dot artefact class entirely. The rest state is mid-demonstration: L-shape, 7 lm, 2-pac, plan drawn, $11,900 showing — and a live price readout sits in the configurator header so the figure shares the 1200×750 thumbnail with the plan. State is exposed at window.__cabinetmaker.

Pricing model — shape and derivations

• Layout is deliberately flat. The spec pins no per-layout rate, so layout chips honestly re-render the drawing without moving the figure — and the card says so: "layout changes the drawing and the design conversation — the metres change the price." A silent no-op control would read broken; a stated one reads honest.
• The benchtop is a separate stated-extra row on every kitchen card — "stone from $600/lm, quoted separately" — never silently included. Benchtops are genuinely a different trade, and folding a guess into the cabinetry figure would be the dishonest kind of tidy.
• Laundry slider-disable is a derived decision. The spec pins robes and vanities as quoted-on-drawing but gives laundries only a flat "from $3,200" with no per-lm rate. A live metre slider would therefore compute an unpinned gradient — so the laundry disables the slider with its own honest reason ("laundries price by cabinet count and bench runs, not metres"). Documented here so QA has a source of truth.
• Finish chips stay live for non-kitchen projects but only redraw the door faces; the disable-reason block states that the from-price holds. Every control changes the price honestly or visibly explains why it can't.
• Cheapest configurator output is the vanity's $1,400, which equals the services grid's lowest "from" — the floor contract holds. The cheapest kitchen is 4 × $1,150 = $4,600, consistent with "from $1,150/lm" over the stated 4 lm minimum.

Conversion decisions

• Consult, not quote. Custom cabinetry can't be quoted from a form, so the CTA is "book a design consult" everywhere — header, hero, card, sticky bar — and the configurator's job is to walk in the door with an honest number already in hand.
• Configurator → form handoff. "Bring this plan to a consult" pre-fills the project select and a details line ("L-shape kitchen · 7.0 lm · 2-pac poly — configurator estimate $11,900 cabinetry (stone benchtop from $600/lm, quoted separately)") and scrolls to the form. The demo interaction becomes a warmer lead. The form is never pre-filled on fresh load, so validation stays honest.
• Form fields: name, phone, suburb, project, one free-text "what are you planning" — the minimum a cabinetmaker needs to bring the right samples. Empty submit raises a per-field message and aria-invalid; a filled submit shows a local confirmation in the "thanks — request received, we'd call you back within one business day" lexicon, with a plain line that this is a demonstration and nothing was sent.
• Mobile: sticky call/consult bar (48px targets), header phone collapses to a 44px icon button at 375px, body 17px, hero value prop + CTA + trust signal inside the first screen.
• Honesty as trust strategy: flat-pack honesty (under $8k, buy flat-pack — we'll say so), lead-time honesty (4–6 weeks), hardware honesty (Blum standard), re-face honesty in the FAQ. For a trade drowning in showroom gloss, saying the cheap thing out loud is the differentiator.

Local SEO we'd implement for the real business

This demo page ships only a WebPage schema naming it a demonstration — fictional structured data in a real index is dishonest markup. For a real client we would ship LocalBusiness + Review schema fed by their actual details and review stream:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com.au/#business",
  "name": "Real Cabinetmaker Pty Ltd",
  "description": "Custom kitchens, robes, laundries and vanities made in Perth.",
  "url": "https://example.com.au",
  "telephone": "+61 8 XXXX XXXX",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Unit X / XX Example St",
    "addressLocality": "Bassendean",
    "addressRegion": "WA",
    "postalCode": "6054",
    "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -31.9, "longitude": 115.94 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "07:00", "closes": "16:00"
  }],
  "priceRange": "$$$",
  "areaServed": "Perth metropolitan area",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9", "reviewCount": "87"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "Real Customer" },
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "reviewBody": "Pulled from the client's live Google review feed."
  }]
}
</script>

Plus: Google Business Profile with workshop photos and the service-area set, suburb-level service pages (kitchens Bassendean / Morley / Bayswater…), review schema fed from the live Podium/Google stream — never hand-typed — and a real NAP consistent across the site, GBP and directories.

What would change for the real client

• Cabinet Vision or Mozaik design-to-CNC workflows — the consult's drawing becomes the machine file; the web configurator's layouts would mirror the shop's actual template library.
• Buildxact quoting so the configurator's estimate flows into a real, itemised quote with board and hardware take-offs.
• Xero progress invoicing — deposit on signed drawings, progress at machining, balance at install, matching how cabinetmakers actually bill.
• Embedded consult booking (Calendly-style) so "book a design consult" becomes a real diary slot, not a callback promise.
• Blum, Polytec and Laminex trade feeds for live board/hardware colours in the finish chips — the veneer swatch would be the actual decor range.
• Podium review flow replacing the demo review cards with the live stream.
• Their photography: the procedural workshop scene stands in for the real 4pm-roller-door shot every cabinetmaker already has on a phone.

Iteration log

Techniques

• Procedural SVG throughout — maker's plan (patterns: 45° hatch, drawn grain, sheen gradient; architectural dimension lines), Perth service-area map, workshop scene, grain-textured ground via tiled data-URI SVG. No raster images, no libraries.
• String-built SVG re-rendered per input on a single dynamic <g>; CSS opacity animations only on inner elements that set no presentation attributes.
• Vanilla JS: state object → render (controls / plan / card / probe); form validation with per-field errors; details/summary FAQ for free accessibility.
• Entry choreography gated on document.fonts.ready with a 1.2s fallback timer; content never stuck at opacity 0 without JS.