Behind the builder / 2 October 2026
The website is the hook. The pilot has to do the work.
UBIKITOS refined a publisher pilot around existing tools, human approval and traceable outcomes. A smaller first campaign made the delivery and model choices concrete.
A smaller first decision
The publisher proposal had become a more actionable delivery plan. Instead of asking the buyer to accept an entire twelve-module future at once, the offer could be approached in stages: the website, a bounded pilot and a larger roadmap if the first work justified it.
The website remained the visible introduction. It gives someone a quick way to see a changed experience and decide whether a further conversation is worth having. The pilot has a different job. It needs to connect an actual workflow, preserve approval and produce an outcome that can be inspected.
The commercial checkpoint recorded preparation rather than acceptance. The scope and implementation discussion had advanced; a signed agreement, paid pilot or revenue had not been evidenced.
Give ordinary tools ordinary jobs
The proposed stack used Notion for knowledge, WooCommerce for commercial facts, n8n for workflows, Postiz for social publishing, Postgres for state and Metabase for analytics. UBIKITOS would own the reasoning, governance, approval and provenance around those parts.
That allocation makes the plan more concrete. A catalogue price should come from the shop. A publishing action needs the relevant account and an approval path. The record of a run needs somewhere durable to live. Those are responsibilities to connect and test, not reasons to reinvent every component.
The exact integration effort still depends on access to the business’s hosting, shop, social accounts and analytics. The architecture can describe the route before those connections are verified.
The model should fit the task
Routine grounded work could use a local Qwen model on the VPS, with selective cloud escalation for work that needed stronger capability. That was a routing design to evaluate, not a claim that one model would solve every task at a particular cost.
For a catalogue-grounded draft, the critical questions include whether the source facts were retrieved, whether the answer stays within them and whether the workflow knows when to ask for review. A harder planning or reasoning task may justify a different model. The choice should follow the work and its checks.
This is where the model-agnostic WorkMachine explanation becomes useful. The intelligence can change while the surrounding requirements for permission, evidence and accountability remain explicit.
One campaign was enough to make the questions real
The proposed first pilot was deliberately bounded: one campaign, five to ten books, two feasible social channels, read-only access to the shop, a selected knowledge subset, an approval and publishing loop, a tracked purchase path and a daily brief.
That is small enough to discuss precisely. Which facts enter the draft? Who approves it? What happens when a product detail changes? Can a published item be traced back to the approved version? What reaches the report after the campaign runs?
The reporting cascade also kept a useful limit in view: work-transfer hours were not measured. An attractive automation plan is not evidence of time returned to the founder. That needs observation once the workflow is running.
The public explanation caught up
The UBIKITOS site also published its release journey, with R3.8.12 Hybrid Retrieval shown as current and R3.8.13 Versioned Cognition marked in development, following the founder’s latest status confirmation. Earlier stages became easier to explore through their names and purposes.
That publication improves the explanation of the work. It does not deploy the research candidates into a customer environment. The distinction belongs in the story because it keeps the next decision clear.
Today’s practical next step was to turn a prepared offer into an agreed, bounded engagement. The website can open the door. The pilot has to earn the reason to keep it open.