My projects can share code. They cannot share a customer.
A common AI workshop makes several projects easier to build. It does not make the people who use them interchangeable.
A workshop full of possibilities still needs a connection to someone outside.AI-generated conceptual setting.
VibeCord is about helping someone create a useful Discord bot. DrawerSense is about helping someone find an object. JustSwipe is about getting a decision out of a pile of agent work.
From the workshop, those projects have a lot in common. They involve software, interfaces, models, context and ways of checking whether an action worked. A fix or a useful component may carry from one to another.
From the other side of the screen, they are different problems.
That is the tension behind building a portfolio with a shared AI production system. The machinery can become more reusable while the work of understanding each person starts again.
Follow the idea
What travels between these projects?
A conceptual comparison of published project aims. It does not rank the projects or report customer demand, saved time, retention or commercial results.
Shared machinery can make the next experiment easier.
Reuse the workshop
Interfaces, model connections and software checks can help across projects. This is the part a common production system can make easier.
The person and problem change with the project.
Keep the people distinct
A Discord organiser, someone looking for a misplaced object and a person managing agent decisions are trying to do different things.
These are questions to investigate, not reported customer outcomes.
Learn from the relevant attempt
A useful bot, a found object and a well-prepared decision are different outcomes. Keep each observation attached to the question it can answer.
The workshop is shared; the learning may not be
Suppose a Discord community needs a particular bot. Learning why its organisers reject a template could help improve VibeCord. That knowledge may do very little for someone trying to find the tool they put down yesterday.
The same distinction applies to distribution. A community where one project is useful is not automatically a place to introduce the others. Trust earned for one job may help, but it does not establish that the second problem exists or that the proposed answer fits it.
This makes a portfolio look different depending on what is being counted. A common build process shows reuse. Separate customer questions show the attention each product still needs.
BESF describes the ambition to connect building with customer feedback. The hard part of that connection is keeping the feedback attached to the actual product and person it came from. A shared system should preserve those distinctions.
The same weak signal can mean different things
A prototype without customers might be a useful technical experiment. It might also be a business idea avoiding its first encounter with a buyer. Looking only at the finished screen does not tell the difference.
A small paid service can answer a commercial question sooner than a long research project. That does not automatically make it the better long-term project. Comparing both only by immediate revenue would decide the question before considering their different purposes.
The reverse is also possible: calling something a long-term bet can become an excuse to avoid any evidence that might change the plan.
The useful comparison asks what the next piece of work is supposed to resolve. Can the proposed system perform the difficult part? Will someone attempt the workflow? Will they return? Can it be delivered without consuming more support than expected?
Those questions call for different observations. A payment does not answer all of them, and an impressive demonstration does not become demand because it took less effort to build.
Keep the option without keeping every project busy
There is room between abandoning an idea and operating it as a business. A project can retain its source, its working experiment and the question that would justify returning to it.
That matters when producing more features is cheap enough to keep every project looking active. Activity can conceal the cost of switching attention, learning a new market and maintaining another promise to users.
A small build can still be the best way to learn. People often need something concrete to react to. The useful stopping point is where the build can answer its question, followed by the attempt that gives the answer meaning.
The scarcity essay considers how constraints move as AI gets more capable, including the possibility that judgement itself becomes cheaper. This portfolio question does not require judgement to remain a protected human skill. It requires learning from one setting without pretending it answers every other one.
These projects are at different stages; this article does not establish durable demand for any of them. The attractive possibility is a workshop that makes each experiment cheaper. Whether the portfolio also makes the next customer easier to understand remains a separate question.