When we priced Versyka, per seat was the obvious default. Almost every developer tool does it.
It didn't fit, for three reasons.
1. A bot doesn't have seats
Versyka opens pull requests. The people who review them might be one platform engineer or the whole team. Charging for each of them would mean charging more because more people can look at a PR, which is backwards.
2. The value is in the fix, not the access
What a team actually wants is a breaking upgrade done: the code rewritten, the tests passing, a PR to review. An afternoon of an engineer's time that didn't get spent. That's the unit worth paying for.
3. A failed attempt shouldn't cost you
If the change can't pass your tests, you didn't get anything. So it isn't counted.
What counts as a fix
A migration pull request: a breaking upgrade where Versyka changed your code and your tests passed.
What doesn't count:
- Version upgrades with no code changes. Unlimited on every plan (with a fair-use cap on daily test runs), because they're cheap to run: no AI, just your tests in a sandbox.
- Replacing a retiring AI model with its direct replacement.
- Attempts that never passed your tests.
- Seats, from the Team plan up: everyone with write access signs in, no seat fees. Free and Starter include you and two teammates.
The plans
| Plan | Price | Fixes / month | Per fix |
|---|---|---|---|
| Free | $0 | 2 (5 repositories) | |
| Starter | $49/mo | 10 | $4.90 |
| Team | $249/mo | 60 | $4.15 |
| Scale | $749/mo | 200 | $3.75 |
The trade-off we accepted
Usage pricing is harder to predict than seats, for us and for you. Two things help: the monthly allowance is a ceiling (nothing surprise-bills), and the dashboard shows how many fixes are left this month before any work starts.
I'd like to hear from people who've bought or built usage-priced dev tools: what made the unit feel fair, and what made it feel like a meter running?
Top comments (4)
For me a unit feels fair when I can guess the cost before I click. Per fix works if I know what counts as one fix before the bot starts. It starts feeling like a meter when a fix turns out to be "one big fix" only after the fact. Since failed attempts aren't billed, what happens with a fix that gets merged and then reverted a day later?
That's the right test, and it's why we drew the line before the work starts rather than after.
One fix = one migration pull request: one breaking change in one repository, however many call sites it touches. It's counted when the pull request opens, never per file or per line. Version bumps and exact model-ID swaps aren't counted at all, and if your checks still fail after the rewrite, no pull request opens and nothing is counted. So it can't turn into "one big fix" after the fact.
Great question on reverts, and it's one we've already planned for. A revert means we got something wrong that your checks didn't catch, so it shouldn't cost you a fix. We're thinking of a 7-day window: fully revert a Versyka pull request within 7 days of merging it, and that fix goes back on your allowance. Until it's built in, just email us and we'll credit it.
What made per-unit pricing feel fair to me as a buyer was knowing the scope before the work started, not after. Your rule that attempts which never passed don't count already does a lot of that.
The one place it can still feel like a meter is when a single upgrade touches three packages and turns into three fixes. If the dashboard said "this will likely count as 2 fixes" before it runs, I think most people would stop worrying.
I've seen the same with people selling agent work one job at a time: a fixed price for one clearly scoped outcome ($49 for one eval run, say) sells better than a monthly plan, because the buyer can picture what they get. Then the jobs that keep coming back tell you which plan to build.
Thanks, this is a really useful way to put it.
The good news is the dashboard already does what you're describing. Every Migrate button shows its cost before you click it ("Migrate · 1 PR", or "no PR used" for an exact model swap), and the confirm step says "uses 1 of N left this month" before anything runs. When you pick several security fixes at once, it splits them into version bumps, which are free, and ones that need code changes, and shows the total, like "uses 2 of N", before you start.
So three packages that each need code changes would show up as three separate fixes, labelled up front, and you can untick any of them. A plain version bump never counts.
And the revert credit from the thread above is live now: fully revert a Versyka pull request within 7 days of merging and it goes back on your allowance.
Agree on the per-job point, too. A fixed price for one clearly scoped result is an easy yes for a buyer, and the jobs people come back for are the best signal for what to build next.