The blank project was the wrong starting point

We have started a lot of projects from a blinking cursor.

The repository exists. The dependencies are installed. The CMS has one cheerful empty collection. Technically, work has begun.

It never feels like it.

The useful questions happen before that point. What are we actually building? Who has to maintain it? Does the client need a five-page site, a publishing system, a product application, or an enterprise marketing surface with twelve systems already arguing over the customer record?

A starter template cannot answer those questions. So we are shifting from a permanent starter stack to a permanent starting system.

The workshop begins with the shape of the project, not a framework logo.

One workshop, several honest routes

There is no single stack that makes sense for a local restaurant, a five-page campaign, a content-heavy marketing site, and a regulated software product.

The new system treats those as different routes from the beginning. A small static site should stay small. A marketing team may need structured publishing and previews. A full application needs identity, data, permissions, observability, and a real deployment plan. Enterprise work adds consent, analytics governance, CRM ownership, experimentation, and handoff rules.

The workshop asks enough questions to choose among those routes. Then it shows the recommendation, the alternatives, the cost, and the reasons in plain language.

The goal is not to make the choice feel inevitable. It is to make the tradeoffs visible.

Design before component shopping

We are also changing how the visual layer begins.

The interview can collect brand mood, color, typography, motion, accessibility needs, and examples of things the client likes or hates. If an existing site is involved, the process can inspect its content and visual signals rather than asking everyone to recreate the brand from memory.

From there it recommends a restrained component foundation and a smaller set of visual accents. Clean and editorial when the brand needs trust. Bright and reactive when the company is allowed to have a pulse. Odd little jelly controls when the project has earned them.

The components remain owned by the project. The design decisions remain documented. Nobody gets six competing button systems because a demo page looked exciting at 1:17 in the morning.

A recommendation you can see

The recommendation is not meant to end as a spreadsheet.

It produces a visual direction, a page plan, likely integrations, quality gates, and a populated first version. A marketing CMS should open with useful content types and sample pages. A static project should already have a home page, contact route, legal baseline, design system, changelog, SEO structure, and working forms.

The client should see the system breathing before the larger build begins.

A working recommendation can be saved, shared, costed, and challenged before it becomes a commitment.

Triad lives in the field

There is a friendly agent inside the workshop called Triad.

Not a chatbot floating in the corner and waiting to be tolerated. Triad lives beside the decisions. It suggests the next useful question, explains unfamiliar terms, and can make a visible selection while showing what changed.

The personality is helpful, a little snarky, and aware that most people do not wake up wanting to compare content models or consent platforms.

Every option also gets a plain-English explanation. Why Astro? What does brutalist mean? When does a client need a CMS? What exactly are they paying us to maintain?

Those questions should not require a private vocabulary.

The same interview stays legible when it is happening across a café table instead of a conference room.

More than the build

The later steps cover the less glamorous parts that usually arrive as separate surprises.

Analytics and consent. Search and error tracking. Transactional email. Payments. Hosting ownership. Accessibility and Lighthouse targets. Contract shape. Retainer or handoff. Training. Domain and email costs. The difference between what the client owns and what we continue to operate.

At the end, the client can keep a private summary, email it, or save it as a PDF. If the project moves forward, the same decisions become a working repository and an initial set of pages instead of another document somebody has to translate.

That part is coming soon.

For now, the first project is still sitting inside its own workshop, asking itself what it wants to be. At least the cursor is no longer blinking alone.