There's a story making the rounds that anyone who has shipped an AI-powered tool will recognize instantly. A developer gets pulled into a cross-border e-commerce project — an Ozon listing tool that generates product images. The existing thing is a Chrome extension: users drag it into the browser manually, then paste in their own API keys before anything works. The image generation fires synchronous requests through a relay, so the moment the network hiccups, it times out and throws an error. One batch of user complaints came in as 130 error screenshots.
The developer's diagnosis was blunt and correct: rip out the synchronous image calls, move them to an async task queue, and stop making every user babysit their own keys. The plan was to rebuild it as a SaaS web app — online signup, subscriptions, auto-billing, sub-accounts. The build mostly happened. The partnership fell apart over pricing and trust before it could land. (The commercial outcome here is a forum anecdote and unverified.) But the technical arc is the useful part, and it's the same lesson that keeps surfacing across AI coding discussions right now.
The pattern that keeps failing
Strip away the specifics and you get a shape that shows up again and again: a tool that pushes the hard, fragile parts onto the end user's machine. Local install. User-supplied keys. Synchronous calls to a model or relay that assume a perfect network. It demos fine on the builder's laptop and falls over the instant a real user with a flaky connection tries it.
The reason people build it this way is understandable — it's the path of least resistance. You don't have to host anything, you don't hold anyone's credentials, and you ship in a week. But every one of those shortcuts becomes a support ticket. The synchronous call becomes a timeout. The user-configured key becomes a setup wall that a non-technical seller can't climb, which turns into someone spending half a day remotely configuring one client's browser for a few hundred yuan a month. That's not a product, it's manual labor with extra steps.
There's a second, quieter signal running alongside this. A separate thread describes watching an AI coding credit system silently shift what the same task costs — 200 credits used to finish a job, then 150 barely starts one — with no way for the user to verify what they actually consumed. The takeaway there isn't really about one vendor's pricing. It's that opacity destroys trust. Users who can't see what a tool did on their behalf stop believing the numbers. And builders who can't audit what their own agent did to a machine — another shared post walks through exactly this, logging every file write and shell command an agent runs — are flying blind for the same reason.
So the pattern to move away from has three properties: it runs the risky work on the client, it hides usage, and it can't show its work. The fix has the inverse: own the backend, meter transparently, keep an audit trail.
What the hosted version actually needs
If you were rebuilding that Ozon tool — or honestly any AI tool that outgrew a script — the shopping list is short and boring, which is the point:
- A web frontend the user just opens, no install, no key-pasting.
- A backend that holds the keys and owns the model calls, so a network blip is the server's problem to retry, not the user's problem to screenshot.
- Long-running work (image generation, batch listing) handled as async jobs, not a request that blocks until it times out.
- A place to store usage and results so the numbers are inspectable — by you and by the customer.
- Accounts, so different users see different data.
- A way to charge for it.
None of that is exotic. All of it is the difference between a toy and something a stranger will pay for and keep using.
Mapping it onto VicroCode
Here's where the confirmed capabilities line up cleanly, and where they don't.
The frontend is a hosted HTML web app — you build it and publish it in-platform, so the user gets a URL instead of a `.crx` file to drag into Chrome. Note the boundary immediately: VicroCode does not package or distribute browser extensions. If your current product *is* an extension, the honest move is to rebuild the UI as a hosted web app, which is exactly the direction that Ozon story was already heading.
The backend is Python. That's where the key handling, the retry logic, and the orchestration live — on the server, not in the user's browser. Long jobs get structured so the frontend kicks them off and polls or checks status rather than holding a synchronous connection open until it dies. You expose that backend through API Endpoint Hosting, and use in-platform tool calls to wire the pieces together. If you're doing AI agent development rather than a single-shot tool, that same endpoint-plus-tool-call structure is what lets an agent take multi-step actions through a controlled surface instead of poking at a user's machine directly.
For the model calls themselves, there's a hard boundary worth stating plainly: you can use Model Center APIs only for models that are already available on the platform. The image model that specific Ozon tool relied on, the Claude access from the refund story, or any third-party relay — none of those are things you can assume are wired up. If the model you need isn't in Model Center, that capability isn't there, full stop, and you'd have to rethink the model layer around what's available.
Usage transparency and the audit trail both land on SQLite. Every job, its status, what it cost, what it produced — write it to a table you can query and edit. That's the direct answer to the trust problem: when a customer asks "what did I actually pay for," you have rows, not a shrug. The same store doubles as your operational log, so when something breaks you're reading records instead of asking users for more screenshots. Generated files and artifacts go through file management. If you later want retrieval over docs — product category rules, listing guidelines, past decisions — a LanceDB knowledge base is the place for that, though for a first version I'd skip it until the core loop works.
Accounts and billing are the part to be precise about. Project publishing, hosting, sharing, and monetization are confirmed capabilities, so you can charge for access to what you publish. But I won't pretend the platform gives you a specific subscription engine, sub-account hierarchy, or a named payment provider — that Ozon plan wanted WeChat and Alipay official interfaces, and those integrations are outside the confirmed set. Design your monetization around what publishing actually supports rather than assuming a full SaaS billing stack is handed to you.
A build order that won't collapse
If I were doing this from scratch, I'd go in this sequence, because it front-loads the thing that killed the original:
Start with the backend and the async job model, before any UI. Prove that a generation request can be submitted, run server-side with the key held there, retry on failure, and write its result and status to SQLite. That single change — synchronous-and-fragile to async-and-recorded — is the whole reason to rebuild.
Then put the thinnest possible hosted HTML page on top: submit a job, watch its status, see the result. No accounts yet. Get one full loop working end to end.
Only then add per-user separation and publish it behind whatever monetization the platform supports. Layer knowledge-base retrieval last, if the domain rules turn out to need it.
The meta-lesson across all these threads — the failed partnership, the credit opacity, the agent-audit tool, even the crowd insisting on "artisanal" hand-coding — is the same. People trust tools they can see into and that don't offload the fragile work onto them. Owning the backend, metering honestly, and keeping the results queryable isn't the flashy part of AI building. It's the part that decides whether anyone keeps using what you shipped.