The stack was growing. The first workflow needed a floor.

Several foundations at once

On 24 July, the infrastructure work included Notion, n8n, Supabase and local automation foundations. Several useful pieces were being designed in parallel.

Each part could make sense on its own. A workspace for organising information. A way to connect steps. Somewhere to store structured data. Local tools to carry out work. Together they suggested a system with considerable reach.

The bottleneck was that the foundations were expanding in several directions at once. The recorded next step was to freeze the minimum stack and implement only the shared foundation path.

That is the infrastructure equivalent of deciding to build a floor before ordering furniture for every room. The components matter, but the first workflow needs a dependable route across them more than it needs the maximum possible number of components.

The day established design direction. It did not prove that every proposed integration was already working as one operating system. The useful question was which smallest combination could support a real piece of work.

A tool should have a specific job

Tools become easier to evaluate when their intended responsibilities are clear.

A workspace can organise the request and its context. An automation tool can connect steps under defined conditions. A database can preserve structured records. A local execution environment can perform work that requires the machine's capabilities.

Those are possible roles, not a claim that every capability was implemented on this date. The practical point is that a tool belongs in the stack because it serves an identified need.

If two components both appear to own the current task state, the project needs to decide how that relationship works. If no component clearly owns a required check, the gap remains even when the stack diagram looks comprehensive.

The danger of choosing tools primarily for their breadth is that the architecture inherits several overlapping ways to solve the same problem. The founder then spends time deciding which feature to use rather than testing whether the workflow itself is useful.

One shared path can reveal the real requirements

A minimum foundation path should be able to carry a bounded request from its starting point to an inspectable result.

Imagine a hypothetical request recorded in a workspace, processed through a defined sequence and returned with a result and supporting evidence. Following that path makes requirements visible. The request needs an identity. The executor needs the right inputs. The result needs to be attached to the correct request. The user needs to understand its status.

If one of those steps fails, the project learns something concrete about the integration. It may need clearer data, a more reliable handoff or a better failure state. That is much more useful than debating every feature the tools could eventually support.

The 24 July plan was to implement this kind of shared foundation before broadening the stack. The minimum was not meant to be impressive by itself. It was meant to be sufficient for a real test.

Connections create responsibilities

An integration is often described as though connecting two services is the whole task. In practice, the connection raises several new questions.

What happens if one side is unavailable? Which record is current? How is a partial update recognised? What should happen if the same request arrives twice? How does a person find out that the workflow stopped halfway through?

The right answer depends on the action and the systems involved. The important part is that these questions exist even when the first demonstration works.

A hypothetical automation that copies a note into a database might look simple. If the note is later edited or removed, the relationship becomes more complicated. Does the database update? Does it preserve history? Is a missing record treated as an error or an intentional deletion?

These examples explain why the shared path needed deliberate implementation. Adding an integration adds a relationship that the system must maintain, not merely another logo to display on the architecture page.

Local work and hosted work have different conditions

The infrastructure plan also involved local automation. That introduces another practical boundary: something that works on the founder's machine may depend on conditions that do not exist elsewhere.

A local file, an already running service or an authenticated session can make a prototype work smoothly. Moving the workflow to another environment requires those dependencies to be understood rather than assumed.

This does not make local development a problem. It is a useful place to build and inspect a workflow. The issue is the claim made about it. A successful local path should not automatically be described as a hosted service available to others.

The day's record concerns foundations being defined, with implementation of the minimum path still ahead. Keeping the environment visible would help later checks establish exactly what had been demonstrated.

That is particularly relevant for an AI-assisted project, where a fluent deployment explanation can sound very similar whether it describes completed setup or an intended future arrangement.

The smallest stack still needs room to fail

A minimum stack should not mean a stack that only works when everything goes well.

The first useful path needs some way to recognise failure and leave the work in an understandable state. Otherwise the simplicity is achieved by leaving the awkward parts for the founder to reconstruct later.

This can be modest. A clear error with the relevant task identity may be more useful than a sophisticated recovery mechanism whose behaviour is not yet understood. A visible waiting state may be more honest than a status that claims completion because one process ended.

The purpose is to make the first workflow learnable. If it fails, the next change should have a clear target. If it works, the project should know which conditions supported that result.

The historical next step was to freeze the shared foundation and implement it. That would create the opportunity to discover which additional capabilities were actually necessary rather than adding them in anticipation of every possible future.

The foundation had a job to earn

The day's infrastructure work gave UBIKITOS a more explicit set of possible components. The important constraint was to use a minimum shared path before expanding further.

That is a practical way to protect an ambitious project from its own options. Every tool offers a new set of possibilities. A working path creates evidence about which possibilities matter now.

The next step was implementation of that path, followed by a result that could be inspected from beginning to end. It would not need to represent every future company workflow. It would need to establish that the selected foundations could support one useful job.

Looking back, the stack should be judged by the burden it removes from the work, not by how comprehensive it looks in a list. The tools were available to help build the floor. They did not all need their own room immediately.