Behind the builder / 14 September 2026
Can one company hold all these ideas?
I asked whether one company could hold several software directions. UBIKITOS needed a clear offer and workable focus without losing the broader creative ambition.
The question was bigger than a feature
On September fourteenth, I asked whether I could create a company without one clear product. The examples were not variations of the same tool: software development, VSTs, games, and SaaS. That question belongs in the UBIKITOS diary because it reveals the business behind the technical work. The challenge was not a shortage of things to build. It was how to give several kinds of creative and software work a coherent home without making the company impossible to explain.
I was asking about the shape of the company; I had not completed a registration or settled a final product strategy. Alongside it, project handoff work was being prepared while usage credits were constrained. The broader technical evidence hold remained in place. There were several unfinished practical matters, but the most human one was simple: how do I keep the range of what I want to make without asking every customer to understand the entire range at once?
A company can be broader than its first offer
There is a useful distinction between the container and the offer. A company can organise several projects over time, while a particular product page or customer conversation still needs a clear proposition. The founder may see a common thread in the tools, methods, or creative interests. The customer needs to know what this particular thing does for them. Those two levels can coexist, but they should not be forced into one sentence that lists every possible future product.
A music producer looking at a VST will care about the instrument or effect, its sound, and how it fits their work. A business user considering an AI workflow will care about the task, the controls, and the result. A player considering a game will care about the experience. These are illustrative audiences, not claims about existing customers. The point is that coherence at company level does not require identical buying reasons at product level. It requires a structure that lets each offer remain understandable on its own terms.
The list was creative, not random
VSTs, games, SaaS, and business AI can look scattered when placed in one line. They also share a practical reality: each involves designing software around an experience. That commonality can make them plausible parts of a founder’s wider practice without proving that they should all be pursued simultaneously. The operating question is which project deserves attention now, what finish line it has, and how its work relates to the company’s current commitments. A broad identity does not remove the need for a narrow next task.
This is where the earlier July and August lessons return. A portfolio can preserve ideas without activating every one. A roadmap can sequence work instead of simply collecting possibilities. A parked project can remain valuable without issuing instructions to the current build. The company question therefore should not be answered only with a name or a category. It also needs an operating approach that prevents the founder’s range of interests from becoming a permanent competition for the same limited attention.
The website has to choose a front door
A website is often where this tension becomes visible. The founder wants visitors to see the full ambition. The visitor wants to understand where they are. If the first screen presents too many unrelated promises, curiosity can turn into uncertainty. A clearer front door can introduce the company’s central purpose and then give distinct projects their own places. That is a design principle, not a claim that a new website structure was launched on September fourteenth.
For UBIKITOS, the practical question is how to explain the accountable AI work without making every creative project feel like an appendix to an architecture document. The company story should be broad enough to accommodate the founder’s work and specific enough to be memorable. Product pages can then do the detailed explaining. This separation can make the whole company easier to understand because visitors are not asked to decide what a game, an audio tool, and a governed workflow have in common before they can find the thing that interests them.
Credits made continuity concrete
The same period included preparation for a handoff while available usage credits were limited. That is an unglamorous but useful part of building with AI tools: the work needs to survive a change in session, capacity, or available service. A handoff packet can preserve the current objective, completed work, unresolved conditions, and next authorised task. Its value is in helping the next session resume accurately, rather than requiring the founder to retell the whole project from memory.
Prepared handoff material is not the same as the work it describes being completed. That distinction remained important here. The packet could make continuation easier without closing the technical questions or creating a launch. It also connected to the company question in a practical way. A founder managing several kinds of software needs continuity that does not depend entirely on one conversation. The system should help preserve the work’s shape when the available tool changes, so a temporary limit does not become a full context reset.
A portfolio still needs evidence
Different projects will need different kinds of proof. An audio tool needs to work in the intended music environment. A game needs to be played and understood by people beyond its creator. A business workflow needs to deliver a useful result under the controls its users require. Putting the projects under one company does not make one project’s evidence transfer automatically to the others. The shared organisation can support them, but each offer still has to earn its own claims.
This is useful because it prevents a broad company identity from becoming a broad capability claim. UBIKITOS can be ambitious about the kinds of software it may create while remaining specific about what has been built, tested, and used. That makes the story more credible and the next decisions clearer. It also gives the founder permission to explore without pretending every exploration is already a product. A company can contain experiments. The important thing is that the public presentation tells visitors which things are available and which remain work in progress.
The useful answer was an operating question
The conversation did not settle every strategic choice, and it did not create a legal outcome. It clarified the kind of company question I was asking: how to build a home for several software directions without losing focus. The next useful work would be to choose a clear current offer, preserve the other ideas in a sensible structure, and keep each project’s status honest. The handoff preparation supported continuity, while the technical evidence hold still needed its separate resolution.
September fourteenth is a reminder that a founder is not only choosing features. Sometimes he is deciding what kind of place all the features belong to. The range of ideas is part of the appeal of building; the challenge is making that range workable and understandable. UBIKITOS did not need to pretend every project was the same. It needed a coherent way to hold them, a clear front door for each audience, and enough focus that one real thing could be finished while the others remained possibilities worth keeping.