Cloud-Based Software: Four Takeaways from Vendors That Got It Right

I have had a front-row seat for roughly 20 years of cloud-based software buying. I have watched customers fall in love with a product, sign a three-year contract, and quietly start planning their exit 18 months later. I have also watched customers adopt a product, expand their usage every year, and still be happy with the vendor a decade later. The difference between the two outcomes is almost never the initial feature set. It is almost always about four things the vendor got right — or failed to get right — and that the buyer should have been looking at on day one.

Here they are, in order of how much they actually matter.

1. The Vendors Who Win Treat Data Portability as a Feature

You can tell a lot about a cloud software vendor's confidence in their product by asking them one question: "If we decided to leave in three years, how would we get our data out?"

The honest answer sounds like this: "Here's our export API. It's documented. Here's the format — it's standard JSON or CSV or Parquet or whatever your destination needs. You can run it yourself whenever you want, and there's no throttling limit that would prevent you from extracting a decade of data over a weekend." Vendors who answer this way tend to be the ones you still want to be working with in five years, because they are competing on product quality rather than on lock-in.

The dishonest answer sounds like this: "Well, you can submit a request to support, and they can generate an export, but it takes 30 to 60 days, there's a fee, and some of the metadata and relationships don't come out cleanly." That is a vendor who knows their retention rate depends on data being hard to move, and it is a vendor who will raise your prices the moment they realize you cannot leave.

What good looks like

The best cloud software we have worked with provides a raw dump of your data on a regular schedule — daily or weekly — to a storage target you control. Some call it "bring your own bucket." Your data lands in your S3 or Azure Blob account, in an open format, with or without the vendor having a say. If the vendor goes out of business or gets acquired by a company you do not trust, you still have your data. That is worth paying a premium for.

2. The Best Vendors Have a Real API and Actually Use It Themselves

"API-first" is one of those phrases that has been abused into meaninglessness. Almost every cloud vendor claims to be API-first. Very few actually are. The test is simple: does the vendor's own web UI use the same API that they expose to customers? If yes, the API is a first-class product, because every feature that ships to the UI has to be supported by the API first. If no — if there is a "customer API" that lags the UI by months and is missing half the features — then the API is an afterthought, and you are going to hit walls every time you try to automate something the vendor did not anticipate.

Why it matters even if you're not a developer

Even if nobody on your team writes code against the API today, the existence of a real API means that the ecosystem around the product is healthy. Integration vendors can build connectors. Zapier and Make and n8n can automate workflows. When your team has a custom reporting need, someone on the finance team can solve it with a spreadsheet connector instead of filing a ticket. The product becomes a platform rather than a silo, and platforms outlast silos by a lot.

3. Pricing Is Transparent and Doesn't Punish You for Success

Cloud software pricing games are a red flag. When a vendor refuses to publish prices on their website, when the price depends on a sales call, when the price goes up dramatically the moment you grow — those are all signs that the vendor is optimizing for maximum extraction rather than long-term customer health.

The pricing patterns that work

• Published prices with a simple structure. Per user, per month, a few tiers. Anyone on your team should be able to forecast next year's bill on the back of a napkin.
• Linear scaling with usage, not step functions. If your team grows from 100 to 105 users, the bill should go up by 5 percent, not by 50 percent because you crossed a tier boundary.
• Discounts for multi-year commits that are honest about what they cost. A three-year lock-in at 15 percent off is a real deal. A three-year lock-in at 40 percent off, where the price resets to list at renewal and the new list is 60 percent higher, is a trap.
• No surprise line items. API call counts, storage, bandwidth, "premium support" — these should all be disclosed up front, not discovered on the invoice three months in.

The pricing patterns that fail

Usage-based pricing that scales with a metric you can't control is a time bomb. If the vendor charges per log line ingested, per event processed, per active user on any given day — pick a metric and watch what happens when your product has a viral week. We have seen customers get hit with surprise bills that were 10x their monthly average because they hadn't realized the pricing metric was unbounded. Good vendors offer a cap or a credit system that lets you put a ceiling on the blast radius.

4. Security Posture Is Documented, Not Asserted

Every cloud software vendor claims to be secure. The ones who actually are can show you the evidence without a 90-day paperwork cycle. They publish a SOC 2 report. They publish the scope of that report. They have a public security page that describes their encryption at rest, their key management, their backup retention, their incident response process, and their subprocessors. They have a bug bounty program, and they pay out on it, and the payouts are public.

Questions that separate the good from the bad

• Where is our data encrypted, and who holds the keys? "AES-256 at rest" is a good start but not enough. Ask whether you can bring your own keys, and what happens if those keys are revoked.
• Who has access to our data internally? The right answer is "nobody by default, and access is granted per incident with audit logs that we will share with you." The wrong answer is "only our support team." Both are roughly the same sentence; the first one is actually checkable.
• What is the breach notification timeline? Regulations in most jurisdictions require 72 hours. Good vendors commit to less than that in the contract.
• Can we run a pen test? Good vendors say yes, with some reasonable constraints. Bad vendors say no, or make the process so painful that nobody ever completes it.

A Small Warning About Feature Checklists

The feature checklist is where most cloud software evaluations start and stop. This is backwards. Features can be added in a quarter. Architectural decisions take years to change. A vendor who is missing a checkbox you want today but who has all four of the things above is a vendor worth betting on, because the checkbox will get added eventually. A vendor who has every checkbox but fails on data portability or API maturity is a vendor whose product is going to fight you in year two and bleed you dry in year three.

The Pattern That Actually Matters

The cloud software vendors who build durable businesses do it by aligning their incentives with the customer's. They make money by the customer succeeding and renewing, not by the customer being trapped. Every one of the four practices above is a way of signaling "we are betting on the product, not on the contract." When you see a vendor signaling that way, weight them heavily in your evaluation. When you see a vendor signaling the opposite, run — no matter how good the demo looks.