What We Tested, What Failed, and What Changed

A build record is useful only if it includes the parts that did not work. During the Orabuena website build, several reasonable-looking configurations failed the test that mattered: could a real person understand the site, take the intended action, and see only promises I was prepared to support?

Could one landing page carry the website?

No. The static page could communicate a product idea, but it could not carry the relationship. A visitor had no proper About page, research appointment, participation forms, account surface, editorial library, or transparent build record.

I rebuilt the site as editable WordPress pages and blocks with separate Home, About, Appointment, Participate, Founding, Blog, Journal, Account, Shop, and Legal paths.

Did a saved editor state prove the public result?

No. One article kept its title, category, and excerpt while the body failed to persist. The editor looked reassuring. The public result was incomplete.

That changed the verification rule. I now distinguish what was entered, what was saved, what survived a reload, and what a visitor can actually see. A nearby green message cannot stand in for the layer I am claiming.

Did a generic appointment fit the purpose?

No. A generic consultation did not give the conversation a clear Orabuena context or separate it cleanly from a sales call.

The Appointment page now uses a dedicated Orabuena research event and explains what the conversation is—and is not—before somebody books.

Did the email workflow actually reach an inbox?

The early answer was unknown. A saved sender and an active schedule did not prove delivery. I tested the product-update path through double opt-in, confirmed it from an external inbox, and received the welcome message. Only then did I activate the automation.

The next problem was voice. The message was technically correct and still did not sound like me. So I rewrote it, then reviewed the next message, the form receipts, the articles, and the public pages using the same standard: the reader should hear a person who understands the burden, not a plugin describing a workflow.

Did an empty storefront look safely inactive?

Not at first. The empty Shop exposed generic storefront controls and price-range values. Even without products, that could imply a commercial offer that had not been approved.

The Shop now explains that purchases are not open. Prices remain unpublished, FluentCart remains in Test Mode, and checkout remains inactive. The Founding 20 application collects an application—not a payment and not an acceptance.

What remains untested

• A complete unsubscribe and suppression test after a confirmed subscription.
• The logged-out customer account, login, and recovery journey.
• A paid Founding 20 seat guard and checkout journey; these remain inactive until the offer is ready to publish.
• Product usefulness, willingness to pay, and participant-derived demand.
• Final legal alignment for subscription and separate digital-product commitments.

The change in method

The most important change is not a page or plugin setting. It is the rule I use to describe progress: configuration, attempted action, persisted state, rendered behavior, external delivery, and participant evidence are different claims.

I will keep verifying the layer that matches the statement. If you have lived through a similar gap between “configured” and “actually works,” tell me where it happened. Research participation remains separate from product-update emails, a Founding 20 application, and any future purchase.