Why I'm Building LumX
LumX keeps the products I build, operate, or validate, the path from planning to the next decision, and lessons found in the field in one product archive.
LumX is the working archive for products I plan, build, operate, or validate in public, along with the decisions and lessons behind them. It is a portfolio of what I can make, a place to collect feedback on live products and public demos, and a one-person studio that turns that evidence into the next version.
LumX exists under one name so development tools, deployment paths, content, user feedback, and operating knowledge do not disappear inside individual projects. Each new piece of work can begin from the decisions and failures the previous one made visible. Worthwhile external ideas can still be built selectively on top of that accumulated practice.
A longer time horizon than one product
A standalone brand is useful for a product, but the context behind the work can disappear when that product ends. A conventional portfolio has the opposite problem: it preserves final screens but rarely captures why a decision was made or what changed after launch.
LumX sits between those two forms. Each product has its own user and problem, while the methods, technical foundation, and operating decisions stay with the studio. DUGOUT 9's public demo appears beside the operating records for Clad and somesignal because decisions found at different stages should inform what improves next.
The products are also the clearest proof of my capability. How a problem is framed, how the experience and system fit together, and what changes after launch are more credible when they remain visible in products and contemporaneous notes rather than as abstract claims.
Public notes keep the outcome from rewriting the process
I do not need to publish every part of the work in real time. I want to preserve the decisions: what the hypothesis was, why I reduced the scope, which alternative I rejected, and which assumption failed after contact with real use.
These records serve two purposes. They make it harder to rationalize old decisions after knowing the outcome. They also give other builders something more reusable than a finished screenshot. A clear tradeoff and its consequence can travel across products; a polished launch image usually cannot.
What three different products contribute
Clad analyzes a photo for personal color and connects the result to palettes and beauty recommendations. It requires translating model output into language a consumer can understand, exposing uncertainty without making the product unusable, and designing one path from input to recommendation.
somesignal uses personality inputs and cultural context to provide compatibility results and conversation prompts. Its operating questions center on turning the interest of a first result into useful conversation and a clear reason to return.
DUGOUT 9 is a public demo for a KBO game companion that connects today's matchup and recent form with team history, quizzes, and puzzles. It turns moment-sensitive game information into a mobile flow while making source attribution, delayed data, durable storage, and operator permissions visible product boundaries.
All three products extend beyond the visible screen. Input and processing, data and result generation, explanation, operating signals, and feedback all need to fit together. Two live services and one public demo have different problems and levels of maturity, but each connects product design, systems, and cloud operating conditions inside a usable service.
What LumX should accumulate
The studio should retain four kinds of output:
- live products people want to use;
- worthwhile services built with clients;
- decisions and failed assumptions discovered while building them;
- tools that reduce repeated work in deployment, quality checks, and publishing.
The goal is not to make the word “studio” appear larger than the work. LumX will be valuable if Clad and somesignal are used, DUGOUT 9 moves from public demo toward durable operation, and the resulting knowledge produces a better next release and client project. What matters is not the number of projects attached to the name, but how clearly they demonstrate the ability to turn an idea into a compelling and responsibly operable service.