Open models or a paid API: the calculation that decides it

A ready made background removal service costs around 20 cents per image. A user uploads roughly fifty items of clothing into a wardrobe. Multiply it out. That gives about ten dollars per person just to prepare pictures, against annual revenue per user of a couple of dollars.

The calculation took fifteen minutes and closed the question. What follows is how to run that calculation before development, while it can still change something.

Count the cost per user, not per call

A price per API call says nothing until it is multiplied by human behaviour. The same twenty cent operation is trivial in one product and ruinous in another, and the only difference is how many times a single user triggers it in a month. So the comparison always reduces to two numbers in the same units: what you earn from an active user per period and what you spend on them over the same period. If the second exceeds the first, growth increases losses and no amount of code optimisation changes that. The product can look great and collect good reviews while every new person makes things worse.

What self hosting changed

Background removal here runs on BiRefNet under the MIT licence, attribute recognition on marqo-fashionSigLIP under Apache 2.0. Both open. Both on our own server. The economics change shape after that. Per image payment disappears and a fixed rental of roughly six thousand roubles a month takes its place, while the cost of one operation drops to fractions of a kopeck. The more users, the lower the per operation cost, so spending stops growing in step with the audience. The honest downside: rental is paid when you have few users too, and early on that is more expensive than per call pricing.

What we deliberately did not do

We did not train our own model. Background removal and attribute recognition are solved problems, and our own model would have taken months for the same quality. What should be yours is the part nobody sells, in our case the algorithm matching an outfit to a specific wardrobe. We did not take a foreign cloud backend either. Personal data of Russian citizens flows through the system, and the law requires it to be recorded and stored in databases located in Russia. Popular foreign platforms have no Russian regions, so hosting was settled before model selection even started.

And we did not leave expensive operations unlimited. That is a separate principle: a cheap operation can be unlimited, an expensive one becomes the product’s currency. If generating an image costs whole roubles and processing an uploaded photo costs a fraction of a kopeck, the second one is unlimited. Otherwise your most active users are your most expensive ones, and the product punishes you for success.

Three questions before choosing

How many operations does one active user trigger per month? Without that number there is nothing to compare.

Are there data constraints. Personal data, medical or banking secrecy, a clause in a client contract, any of it can close off an external service regardless of price, and learning that before the architecture is cheaper. The third question is about people: who maintains the server. An open model is not only a licence, it is updates, monitoring and being on call, and without that person fixed rental becomes hidden debt that comes due at the worst possible moment.

Where to start in practice

Start with a paid API while the user base is small. You pay only for what is used and you validate the idea faster. The overpayment at this stage is measured in tens of dollars. That is nothing.

In parallel, calculate the point where per call pricing exceeds rental, and agree in advance that the migration happens when that point arrives, long before the invoice that upsets you. For the migration to be possible at all, isolate the model behind your own interface from day one: product code calls your processing function and never the vendor directly. A few hours at the start. Weeks saved later.

What I do not know

We never measured the quality of open models against paid ones on a large sample. The comparison was done by eye on a few dozen images, and for our task no difference was visible. Calling that a careful benchmark would be generous.

People often object here: what if the open model turns out worse on real data? Fair question. Check it before migrating, on a sample of your own files, and if the difference is visible the paid service stays, only now you know what you are paying for. What is your ratio of operations per user to revenue per user? Send the numbers and we will find the switching point together.