The weekly issue is now part of the product

This week was mostly about the frame around the work. A floor plan needs walls, but a product also needs edges: when it speaks, when it waits, what it promises, and what it refuses to pretend.

The letter gets walls

The newsletter is now a real part of ArchCanvas, not a loose note assembled by hand.

I built the weekly issue as a small architectural journal: a subject line, a short editor’s note, two to four product sections, a closing note, and a featured floor-plan project for the issue artwork. The template is designed to carry a plan and renders beside the writing, so each issue has something drawn in it, not only words.

The important constraint is editorial. The letter is about product and craft only. It carries what shipped, what changed, and what someone can now do with the tool. It does not carry business counters. That keeps the surface clean for prospective users: plans, compiler work, interface changes, limits, and next steps.

Under the surface, the flow now has a few rails:

• Generate the issue from the week’s shipped work.
• Render it into the magazine-style email template.
• Check it before sending.
• Schedule it on the weekly cadence.
• Keep an archive after it goes out.

That last piece matters more than it sounds. A product archive is a record of decisions. It lets someone come back later and see the tool accrete, week by week, with the rough edges still visible.

Monday machinery

The newsletter also got its plumbing.

The signup form now writes through the subscribe API, and the production container has the Resend API key and audience wiring it needs. The broadcast target is explicit. The bearer check is timing-safe. The weekly cron is wired. The footer link is in place.

I also added tests around the path instead of trusting the calendar. There is coverage for the email template, the full newsletter suite runs, and the JSX transform is handled through oxc. There is also an autumn DST test, because “send this every Monday” is a simple sentence that hides a surprising amount of clockwork.

None of this changes the shape of a floor plan. It changes the reliability of the room around it. The writing can now be produced, checked, scheduled, and archived by the same system each week, instead of depending on a founder remembering every moving part at the right hour.

A calmer meter

In the studio, I changed the generation copy to set a plainer expectation: 2–3 minutes.

That is the honest range the interface should prepare someone for. A floor-plan generation is not an instant visual shuffle. The system has to turn a brief into a structured plan, run it through the deterministic parts, and come back with something dimensioned and internally consistent enough to think with.

The wording matters because waiting feels different when the tool tells the truth up front. A spinner without context feels broken. A clear estimate gives the wait a frame.

The credit grant changed too: the signup grant moved from three generations to one, with lifetime caps for the free tier. That is a product boundary, not a growth trick. It makes the first run available, keeps the cost surface controlled, and forces the first experience to be treated as a real design pass rather than a pile of disposable attempts.

The bet is still the same: one plan should be worth studying. If it is not, the right fix is not to hide behind volume. The right fix is to improve the plan.

Names on the door

Both public homes moved onto their long-term domains.

ArchCanvas now lives at archcanvas.uk. ArchLang now lives at archlang.uk, with the custom-domain setup recorded as durable project truth in the docs.

This is small infrastructure, but it is the kind that removes grit. The product has a stable front door. The open-source floor-plan language has its own address. The docs now remember how the doors were hung, so the setup is not trapped in a terminal history or one person’s memory.

ArchLang remains the quiet machine underneath the drawn work: the source format, the compiler target, the thing that lets a plan be checked instead of merely pictured. The domains make that split easier to hold. ArchCanvas is where someone asks for a plan. ArchLang is where the plan language can be inspected, improved, and treated as infrastructure.

If you are sketching a small house, flat, studio, or garden room, reply with the brief you would want to test first. I am especially interested in the awkward parts: the tight corner, the bad entrance, the room that needs daylight but has nowhere obvious to sit.