Vizcom
Fairly pricing expensive magic
Meter AI use in a unit designers can reason about: credits, instead of capping it like a coding tool.
The situation
This study covers only what is already public. Vizcom is a live product, and it is where I work now.
I am Vizcom’s first product manager. The product is an AI design platform: industrial designers turn sketches into renders, and it serves free users, students, professionals, and enterprise design teams. The category is young, and Vizcom is a small company in a market where Adobe and Autodesk could decide to compete tomorrow. Speed matters, and the edge has to be maintained deliberately.
The constraint
The economics of the product were changing under it. Each generation of image models has cost more to serve than the last: the opposite of text models, which get cheaper per token with every release. And designers do not live inside the product all day, the way a developer lives in an editor. They work in bursts, around deadlines and client reviews.
Those two forces met. Rising per-generation costs, episodic usage, and a user base that spans free users through enterprise design teams: the standard pricing playbook did not fit, and the product had almost no cost tracking. In eight months it had to go from that to a model that was positively margined and still fair.
The call
The call was to build Vizcom Credits: metered access shaped to episodic use, instead of the usage caps the industry defaults to.
The alternative was the familiar one: cap usage the way daily-use products do. It fails for designers. A developer lives inside the tool; a designer visits it. A cap taxes exactly the professional whose work comes in bursts, and subsidizes the always-on power user. Credits meter the work itself, so usage follows the work rather than the calendar.
The reasoning
Credits are a translation layer. Designers do not think in tokens or inference costs. They think in renders, revisions, and deadlines. Naming a unit they can budget in turned an invisible GPU bill into something a non-technical user can reason about. That is pricing as product design: the metering unit is the user experience.
The fairness question had a shape. The users the model needed to protect were the professionals whose usage is episodic: the ones a cap would punish for working in bursts. The users it should not subsidize were the ones consuming beyond what the product could sustain. Credits drew that line by charging for work, not for attention.
And pricing cannot be designed in the dark. Before the model could be fair, the product had to be able to see what a generation actually costs, so the work started with instrumentation.
What happened
Credits launched, and the disruption we had prepared for did not come. Churn due to the change was 1%, and the users who left were the ones consuming beyond what the product could sustain, not the professionals the system was built to protect. Credits is still how Vizcom works today.
The larger judgment
The credits question was a pricing problem. Underneath it was the question an AI design platform answers feature by feature: which parts of a designer’s workflow should the model own, and which should be deterministic software.
My position is not that the model should own everything. It is that the product has to know the difference. The model is best at exploration: many directions, quickly. Deterministic software is best at precision: the exact dimension, the guaranteed repeat, the version that must be the same every time. A product that blurs the two is selling surprise as reliability.
What I’d do differently
Build the cost instrumentation before the pressure arrives. When the margin question hit, the product had almost no cost tracking: the first months of the credits work went into instrumenting generations before we could price them. That is a first-PM miss, and mine: cost visibility is infrastructure, and infrastructure comes before the argument that needs it.