When we first thought about pricing Raff, pure pay-as-you-go looked like the obvious answer.
It sounded modern. It sounded developer-friendly. And on paper, it matched the way many builders want to think: spin things up, use what you need, pay only for what ran.
At a conceptual level, I still understand why that model is attractive.
But building a cloud company teaches you something quickly: a pricing model does not have to sound good only in theory. It has to work in real life — for customers, for support, for operations, and for the platform itself.
That is exactly why we moved beyond pure pay-as-you-go billing.
The original idea made sense at first
In the early stage, pay-as-you-go felt aligned with the kind of users we care about.
Developers want freedom. Startups want flexibility. Small teams do not want infrastructure commitments before they know what the workload will become.
That logic is not wrong.
In fact, I think it is one reason usage-based cloud products became attractive in the first place. They remove the feeling of being trapped. They make experimentation feel possible. They lower the psychological barrier to launching something new.
For a young infrastructure company, that is a very tempting place to start.
And it was tempting for us too.
But a pricing model has to survive contact with reality
This is the part that matters most.
What looks elegant in a pitch or on a landing page does not always hold up once real usage patterns show up.
We learned that the hard way.
Pure pay-as-you-go sounds fair because it implies perfect alignment between usage and cost. But in practice, it also creates a different set of problems:
- cost perception becomes harder to anchor
- billing expectations become less stable
- users think in short bursts, even when their workloads are not actually short-term
- platform planning becomes harder
- pricing conversations become more reactive than intentional
And most importantly, it does not always match how customers actually behave.
A surprising number of workloads are not “launch for 30 minutes and destroy.” They are persistent. They are ongoing. They are the kind of projects that need a machine, keep the machine, resize the machine, and build on top of it.
Once we saw that pattern more clearly, it became obvious that pure pay-as-you-go was not the best long-term foundation for Raff.
The real issue was not flexibility. It was clarity.
This is where I think many infrastructure companies make the wrong distinction.
They assume the only alternative to pay-as-you-go is rigidity.
That is not how I see it.
The real question is:
Does the pricing model help the customer understand what they are buying and what it will cost as the workload becomes real?
That is where pure usage billing can become weaker than it first appears.
Yes, it feels flexible. But flexibility without enough structure can create a different kind of friction.
Teams start asking:
- What will this actually cost if we keep it running?
- Is this still the right configuration for next month?
- Are we optimizing for usage or just reacting to charges?
- How do I explain this model internally if the workload becomes more permanent?
That uncertainty is not always visible in the first week.
But it becomes much more visible once the project is no longer a temporary experiment.
We realized our customers needed something simpler
One of the things I care about most at Raff is reducing unnecessary decision fatigue.
Infrastructure is already full of choices: VM class, CPU, RAM, storage, backups, networking, regions, architecture, growth path.
If the pricing model itself also becomes something the user has to constantly interpret, the platform starts consuming too much attention.
That is why we moved toward a simpler subscription model.
Today, Raff publicly frames pricing around clear terms:
- monthly
- 1-year
- 2-year
Longer commitments come with bigger savings, and customers receive a detailed invoice at the end of each billing cycle. The platform also supports automatic and manual payment modes, with credits and account balance applied first before charging the payment method.
That is a much cleaner model for the kinds of teams we serve.
It is easier to understand. It is easier to explain internally. And it is easier to build on when the workload becomes something serious rather than temporary.
We did not reject flexibility — we changed where it lives
This is important.
Moving beyond pure pay-as-you-go does not mean we stopped caring about flexibility.
It means we stopped putting all of that flexibility pressure on the billing model alone.
Instead, we think flexibility should show up in more useful places:
- clear VM options
- monthly, yearly, and 2-year terms
- easy upgrades and resize paths
- backups and snapshots when workloads become important
- practical infrastructure layers like Linux VMs, object storage, and private cloud networks
That is a healthier version of flexibility.
Because what most users really need is not billing chaos in the name of freedom.
What they need is a platform that lets them start cleanly, understand their costs, and still adapt as the workload grows.
Why this shift made more sense for Raff specifically
I also want to be honest about something:
a pricing model is not only a customer-experience decision. It is also an operating decision.
If you are building real infrastructure, the platform needs a model that supports reliability, product development, support, and clear financial expectations without turning every active workload into a micro-billing event.
That matters even more when your goal is not just to rent compute, but to build a platform people can trust.
Raff today is already broader than just “a VM with a price tag.”
The current public platform includes:
And the broader direction includes more platform layers over time.
That kind of platform benefits from pricing that is simpler, more stable, and easier to reason about than pure raw usage billing.
Customer behavior taught us more than theory did
This is probably the biggest lesson.
In theory, developers say they want maximum freedom. In practice, many of them want something slightly different:
they want freedom without billing anxiety.
That is not the same thing.
They want to know:
- what they are paying for
- how long it will make sense
- what happens if usage grows
- whether the platform still feels affordable next month, not just today
That is why transparent pricing matters so much to me now.
Not as a slogan.
As a product standard.
The pricing page should make sense. The billing cycle should make sense. The upgrade path should make sense. The invoice should make sense.
That is a better customer experience than a model that sounds modern but becomes harder to interpret once the workload stops being temporary.
Why I still think the original instinct was useful
Even though we moved away from pure pay-as-you-go, I do not think the original instinct was wrong.
It taught us something valuable.
It forced us to ask:
“How do we keep infrastructure from feeling heavy, rigid, or commitment-driven too early?”
That is still the right question.
We just learned that the answer was not “charge everything in the most usage-granular way possible.”
The better answer was: build a pricing model that stays clear, supports different commitment levels, and still feels fair to the kinds of teams Raff is built for.
That is a more mature answer.
And honestly, a more useful one.
Where the current Raff model is stronger
I think Raff’s current public pricing model is stronger for a few reasons.
1. It matches how many real workloads behave
A lot of customer workloads are persistent enough that monthly or longer-term pricing is easier to plan around than raw pay-as-you-go.
2. It is easier to explain internally
Founders, developers, and small teams do not want to become infrastructure accountants. Clear terms are easier to communicate.
3. It creates better long-term trust
When pricing is simple, the platform feels more trustworthy. That matters a lot more than people think.
4. It still leaves room for flexibility
Monthly plans still exist. Longer terms simply reward predictability with better value.
That is a much more balanced model than pretending every workload should be priced like a short-lived experiment.
What This Means for You
If you are evaluating cloud infrastructure, I would encourage you to look beyond whether a provider says “pay-as-you-go” or “subscription.”
That label alone does not tell you enough.
Ask better questions:
- Will this pricing still make sense once my workload becomes real?
- Can I understand my billing model without overthinking it?
- Does the platform feel flexible in the right places?
- Am I buying freedom, or just buying uncertainty with a modern label?
That is the more useful filter.
At Raff, we started with one instinct, learned from how the platform and customers actually behaved, and changed direction. Today, the public model is much clearer: choose a term, know the structure, and build on infrastructure that is designed to stay understandable as you grow.
If you want to evaluate that model directly, start with the pricing page, then compare it with the practical infrastructure layers around it: Linux VMs, data protection, and private cloud networks.
That is where the current Raff story makes the most sense.
Not pure pay-as-you-go. Not rigid long-term lock-in.
A clearer middle ground that actually works.