Lessons From Shipping a Portfolio of AI Web Tools
The biggest lesson from running a portfolio of AI web tools is that the model is the easy part. The hard, durable work is everything around it — the input a real user actually uploads, the quality bar, and the first ten seconds of the experience.
TL;DR
- The model is a commodity; the wrapper is the product. What you build around the model is where the value and the defensibility live.
- Real inputs break demos. Ordinary phone photos and messy files are the true test set.
- Ship a quality gate, not just a generate button. Catch the bad output before the user does.
- The first ten seconds decide retention more than any feature.
- A portfolio is a discipline problem, not a scale problem.
Why the model is the easy part
Any capable team can call the same models I call — so the model is not the moat. The parts users feel are the parts I control: how the tool interprets a bad input, what it does when the model returns something off, how fast the first result lands, and whether the output is usable without instructions. That’s where I spend my time.
Definition: by wrapper I mean the full product layer around a model call — input handling, prompt construction, retries, quality checks, fallbacks, and the interface. The model answers; the wrapper decides whether the answer is any good.
Real inputs are the test set that matters
Every AI tool looks great on the demo image and falls apart on a real one — so I test on the ugly inputs first. Across the CLOOMS tools, the failures were never the polished sample photos; they were the sideways selfie, the dark bathroom lighting, the file that’s technically the wrong thing.
The practical rule I ended up with: the acceptance test for an image tool is a normal phone photo taken in bad light, not a studio shot. If it holds there, it holds in production. If it only holds on the demo, I haven’t shipped a product — I’ve shipped a screenshot.
Ship the quality gate, not just the generate button
A generate button without a quality gate ships the model’s worst day straight to the user. Models are non-deterministic; some fraction of outputs are wrong, warped, or off-brief. The tools that felt reliable were the ones where I added a check between “model returned something” and “user sees it” — regenerate on a bad result, fall back gracefully, and never present an obviously broken output as if it were the answer.
This is the single change that moved a tool from “impressive sometimes” to “trustworthy” — and trust is what makes someone come back or share it.
The first ten seconds decide everything
Retention is set before a signup box ever appears. A person tries a tool, gets one result, and decides in seconds whether it was worth it. So across the portfolio I hold one rule hard: a real result comes before any account. You earn the signup by being useful first; you don’t extract it up front and hope the result justifies it later.
A portfolio is a discipline problem
Running many tools solo works only because each one is narrow and shares the same method. I’m not maintaining a dozen philosophies — I’m applying one filter, start from a job you can name in a sentence, across a dozen narrow tools. The moment a tool tries to do five things, it stops being maintainable by one person and stops being clear to the user at the same time.
The same restraint is what lets me run a consumer and a B2B AI company at once: shared method, separate surfaces.
FAQ
Isn’t the model the hard part of an AI tool? No — calling the model is the easy, commoditized part. The hard part is input handling, quality control, and the experience around it, which is what users actually feel.
How do you keep AI output quality high? I put a quality gate between the model’s response and the user: check the result, regenerate on a bad one, and fall back rather than show a broken output. Non-deterministic models need that guardrail.
Why test on bad photos on purpose? Because production inputs are messy. A tool that only works on clean demo images will fail the first real user. The ugly input is the real acceptance test.
How can one person run this many tools? By keeping every tool single-purpose and reusing one build method. The full set is on the projects page.