Product Decisions and the Tradeoffs Behind Them

Building a public website for a product in discovery creates a temptation to make the business look further along than it is. I do not want to do that with Orabuena. I want to publish what a person can actually use, label what I am still testing, and keep consequential paths inactive until I can support the promise they make.

Decision: make the site editable

The first public version was a static landing page. It explained the idea, but it did not give me a manageable way to maintain pages, forms, appointments, a blog, or this Journal.

I rebuilt the public site in WordPress with Kadence-compatible blocks. The tradeoff is more settings and more plugin interactions to verify. The benefit is that the website can grow without turning every sentence into a code release.

Decision: keep every relationship separate

A person may volunteer for evaluation research, ask for product updates, apply to the Founding 20, book a conversation, or eventually make a purchase. Those are not five names for the same permission.

Separate paths create a little more explanation. They also make the choice honest. Research interest does not become marketing consent. An application does not become an acceptance. A booking does not become a sale.

Decision: activate email only after delivery is real

The product-update form uses double opt-in. I tested that path through the external inbox, received the confirmation and welcome messages, and then activated the first FluentCRM automation. I am reviewing every message because a technically correct email can still fail if it sounds like a machine talking about a person.

The tradeoff is slower activation. The benefit is that “sent” does not get mistaken for “delivered,” and consent remains a choice the reader can verify.

Decision: keep pricing and checkout inactive

I have a Founding 20 model: twenty people, each offered 50% off the applicable Standard list price for as long as the qualifying subscription remains continuously active. But the list price is not published, FluentCart remains in Test Mode, and checkout is not open.

That costs me the chance to take money today. It also prevents a pricing hypothesis from becoming a promise before plan scope, limits, policies, willingness to pay, tax handling, and the seat guard have been verified.

Decision: write around human authority

Orabuena is a private executive office for the one-person company. It is not supposed to become the hidden authority for that company. Preparation, approval, execution, completion, and evidence remain different states.

That position is less dramatic than promising an autonomous business. It is also closer to the responsibility a founder actually carries when money, clients, privacy, legal commitments, and reputation are involved.

What remains unresolved

• Which workflow deserves the first product implementation after participant evidence is available?
• What Standard plan scope and list price can support the Founding 20 promise responsibly?
• Which legal commitments belong to subscriptions and which belong to separate digital products?
• What additional marketing sequences will be useful without filling an inbox simply because the software can?

These are not defects I intend to hide. They are decisions that need evidence or explicit authority before the public promise expands.

The rule I am carrying forward is simple: a configured feature is not automatically a verified workflow, and a plausible direction is not automatically a public capability.