Customer Zero was a way to make the idea answer back

The architecture needed a smaller test

On 26 July, the architecture was rethought around Hermes, lean foundations and Customer Zero. The recorded concern was overengineering around commercial assumptions that remained unproven.

The next step was to use a simplified reference company to validate the engines and modules.

Customer Zero is an appealing phrase because it turns the builder into an early user. The company or project doing the building becomes a place to test the workflow before presenting it as a dependable service for someone else.

That can be useful. It can also become circular if the founder’s enthusiasm is treated as independent evidence of market demand.

Today’s direction was therefore practical rather than conclusive. Use a smaller reference setting to make the system encounter a real job. Learn what the components need to do. Keep the difference between internal usefulness and external validation visible as the work progresses.

The architecture needed something that could push back on its assumptions.

A reference company gives the system a context

A workflow cannot be evaluated only through abstract roles. It needs a situation with goals, inputs, constraints and a definition of an acceptable result.

A simplified reference company can provide those conditions without requiring the project to support every possible business at once. It gives the system a place to answer concrete questions about work.

Imagine a fictional small organisation trying to prepare a weekly operations review. The inputs might be a task list, a few completed outputs and unresolved issues. The result needs to help someone decide what deserves attention next.

That example exposes practical requirements. The system needs to distinguish completed work from activity, preserve unresolved questions and avoid inventing progress where the inputs are silent.

The 26 July record does not say that this particular review was implemented. It describes the move towards a simplified test setting. The value of that setting would be its ability to make the architecture’s assumptions observable through a bounded task.

Being your own customer changes what you notice

Internal use can reveal friction that a diagram or demonstration misses. The founder has to live with the output rather than simply explain why the system is promising.

Does the result arrive in a useful form? Does the workflow require repeated clarification? Is it easier to complete the task through the system than to work around it? Which parts still depend on knowledge the founder carries outside the tool?

Those are practical questions Customer Zero can help investigate. They do not require an invented customer persona who conveniently understands every internal term.

At the same time, the founder has advantages that future users may not share. Familiarity with the project can hide unclear instructions. Personal motivation can make a cumbersome workflow feel more tolerable. The builder may repair problems without noticing how much intervention the task required.

That is why internal use is useful evidence with a specific scope. It can improve the workflow while leaving the question of external demand and independent usability open.

Lean foundations mean fewer assumptions at once

The day’s architecture direction emphasised lean foundations. The aim was not to make the system small as an aesthetic preference. It was to reduce how many unproven relationships had to work simultaneously.

A simpler path is easier to inspect. If a result fails, the project has fewer places to look before forming a useful diagnosis. If it succeeds, the conditions supporting the success are easier to preserve.

This is especially relevant in an AI workflow because several kinds of uncertainty can overlap. The request may be ambiguous. The model may make an unsupported inference. An external service may fail. The acceptance criteria may be unclear.

Adding more components before separating those problems can make the system harder to improve. A new layer may compensate for one symptom while creating another dependency.

The reference-company approach offered a way to test the foundations against a concrete task, allowing the next layer to be justified by an observed need rather than by the completeness of the imagined platform.

The first useful result should be easy to inspect

A Customer Zero exercise should have a result that someone can examine without needing to accept the project’s entire thesis in advance.

A hypothetical task might produce a source-backed brief, a reconciled task list or a proposed workflow change. The important part is that the output has a clear purpose and criteria for acceptance.

If the criteria are vague, the founder can always find something encouraging in the result. That makes the experiment less informative. A precise requirement creates the possibility of an honest failure, which is part of what makes the test useful.

The day’s next step was validation of engines and modules through a simplified company. That validation would need to establish what each part contributed and whether the complete path delivered the intended result.

A good internal test should make the project easier to challenge, not merely give it a friendly place to demonstrate itself. The reference setting is valuable because it can expose what remains awkward or incomplete.

The commercial assumptions still needed their own test

The concern about unproven commercial assumptions remained central. Customer Zero could help with delivery and usability, but it could not determine by itself whether another organisation would choose the offer.

A founder may value a capability because it supports a wider personal project. A customer may have a simpler alternative, different constraints or a problem that does not justify the proposed complexity.

The commercial question therefore needs to remain separate enough to be investigated honestly. What recurring problem would the customer recognise? What are they doing now? What would a useful improvement look like from their perspective?

There is no external customer result to report for 26 July. The architecture rethink was a step towards making the system more testable internally while keeping the market question visible.

That separation helps avoid a common shortcut: using an internal prototype’s existence as evidence that a buyer wants it. Existence, usefulness and demand are related questions, but they are not the same result.

A smaller company could teach the larger system

The recorded direction was to use a simplified reference company, validate the necessary components and keep the foundations lean.

That gave the project a more concrete way to learn. The system could be asked to do something recognisable, and its output could be judged in context. The result could then inform which parts of the architecture needed improvement.

For UBIKITOS, the useful promise of Customer Zero was not that the founder would become proof of a market. It was that the builder would stop being only the author of the system’s ambitions and become a user of its actual behaviour.

The next work still had to produce and verify the bounded workflow. But the direction was clearer: let a small operating reality challenge the large design.

The reference company did not need to represent the whole world. It needed to be real enough to tell the project when its answer was not yet good enough.