13 Essential Examples of PaaS

When you’re build­ing a SaaS com­pa­ny, plat­form as a ser­vice (PaaS) is one of the biggest infra­struc­ture deci­sions you’ll make—and most founders get the analy­sis wrong. Here are exam­ples of PaaS com­pa­nies and frame­works to help you choose the right one for your stage.

PaaS sits between infra­struc­ture as a ser­vice (IaaS) and soft­ware as a ser­vice (SaaS). The provider man­ages the under­ly­ing hard­ware, oper­at­ing sys­tem, and mid­dle­ware, while you man­age appli­ca­tions and data. But here’s what most SaaS founders miss: choos­ing the wrong PaaS does­n’t just slow down development—it affects your gross mar­gin, locks you into a ven­dor you can’t leave, and cre­ates a risk dis­count when you try to sell.

I’ll walk you through the major plat­forms, the eco­nom­ics of each choice, and a frame­work to decide which one actu­al­ly makes sense for your com­pa­ny.

---

Why This Choice Matters More Than CEOs Realize

If you’re run­ning a B2B SaaS com­pa­ny at $5M–$15M ARR, your host­ing bill prob­a­bly shows up in COGS (cost of goods sold). Most founders think plat­form choice is pure­ly a tech­ni­cal deci­sion. It’s not.

Here’s what changes every­thing: your cloud provider is part of your cost struc­ture. A cheap PaaS ear­ly on that’s easy to scale with feels great until you hit a pric­ing inflec­tion point around $5M–$10M ARR—the exact moment you’re try­ing to improve gross mar­gin for exit. Bad ven­dor choice at scale costs you $500K–$2M annu­al­ly in unnec­es­sary COGS.

Worse, switch­ing costs are bru­tal. If your data­base schema is locked into Heroku Post­gres, your app is deployed across AWS Elas­tic Beanstalk, and your team knows only that stack, rip­ping it out is a 3–6 month engi­neer­ing project. Acquir­ers see that as key-per­son risk and ven­dor lock-in—both cut your mul­ti­ple.

This mat­ters for your eco­nom­ics, your option­al­i­ty, and your exit.

---

PaaS vs IaaS vs SaaS vs FaaS — One Table, Decided

Before div­ing into spe­cif­ic plat­forms, let’s clear the def­i­n­i­tions. These cat­e­gories over­lap in con­fus­ing ways.

Lay­er	Provider Con­trols	You Con­trol	Respon­si­bil­i­ty	Unit Eco­nom­ics	Best For
IaaS	Hard­ware, OS, mid­dle­ware	Appli­ca­tion, data, run­time	You man­age scal­ing, patch­ing, uptime	You pay for com­pute hours (no dis­count on scale)	Ear­ly-stage star­tups, exper­i­men­tal projects
PaaS	Hard­ware, OS, mid­dle­ware, some run­time	Appli­ca­tion, data	Plat­form han­dles scal­ing & patch­es; you deploy code	Vol­ume dis­counts kick in; COGS declines per cus­tomer	$1M–$50M ARR; sta­ble prod­uct; repeat­able work­load
SaaS	Every­thing	Just use it	Ven­dor man­ages all ops	Per-seat licens­ing; pre­dictable cost	Depart­ments buy­ing from you, not build­ing
FaaS	Hard­ware, OS, mid­dle­ware, run­time	Indi­vid­ual func­tions	You write code; plat­form invokes & scales on demand	Pay-per-invo­ca­tion; true vari­able cost	Event-dri­ven work­loads, spiky traf­fic, APIs

The key insight: PaaS sits in a sweet spot for scal­ing SaaS com­pa­nies. You get oper­a­tional lever­age (the plat­form han­dles deploy­ments, mon­i­tor­ing, scal­ing) with­out the com­mit­ment of rolling your own infra­struc­ture. But you’re also more locked in than IaaS—which is why the lock-in risk mat­ters.

---

The 4 Questions to Ask Before Picking a PaaS

Don’t start with “Which plat­form is coolest?” or “Which one does my CTO know?” Start here:

1. Does This Decision Show Up in COGS or R&D?

Cloud host­ing goes in COGS. That means it direct­ly affects your gross mar­gin, which is the #1 met­ric acquir­ers look at.

If you’re at $5M ARR with 75% gross mar­gin and your PaaS bill climbs to 20% of rev­enue (instead of 10%), you’re now at 65% gross mar­gin — a mul­ti­ple killer. That 10pp gross-mar­gin swing costs you rough­ly $500K in annu­al gross prof­it, which at a 5× EBITDA mul­ti­ple is $2.5M+ of enter­prise val­ue. At growth-pre­mi­um mul­ti­ples (8–10×), it’s $4M–$5M gone.

Ask your­self: as I scale from $5M to $20M ARR, does this plat­for­m’s per-cus­tomer cost stay flat, decrease, or increase? Spot instances and vol­ume dis­counts exist, but only if you engi­neer for them.

2. What’s My Switching Cost If I Need to Leave?

Switch­ing cost has two parts: engi­neer­ing (how long to migrate?) and oper­a­tional (how risky is the re-plat­form?).

Heroku is easy to leave (you’re just mov­ing a Dock­er con­tain­er). AWS Elas­tic Beanstalk locks you into AWS-spe­cif­ic RDS, VPC, and net­work­ing fea­tures. Sales­force Light­ning binds you to the entire Sales­force ecosys­tem.

Your switch­ing cost is: (esti­mat­ed engi­neer­ing weeks) × (loaded cost per engi­neer) + (rev­enue risk dur­ing migra­tion) + (unplanned down­time cost if some­thing breaks).

If that num­ber is > $500K, the plat­form has ven­dor lock-in pow­er over you. That mat­ters when you’re nego­ti­at­ing with an acquirer—they’ll dis­count your val­u­a­tion because they might need to rip-and-replace your infra­struc­ture.

3. Does This Platform Force Me to Run More Engineers or Fewer?

Man­aged plat­forms (Heroku, Dig­i­talO­cean App Plat­form) reduce head­count. You don’t hire a DevOps engi­neer.

Roll-your-own plat­forms (Kuber­netes-based, like Open­Shift) add head­count. You now need some­one who under­stands orches­tra­tion, scal­ing poli­cies, net­work­ing.

If you’re sub-$5M ARR and lean on engi­neer­ing head­count, a man­aged plat­form is a force mul­ti­pli­er. If you’re $15M ARR with an ops team, the over­head of self-man­aged infra­struc­ture might be worth the cost con­trol.

The ques­tion isn’t “Which is cheap­er?” It’s “Which lets my engi­neer­ing team ship faster?”

4. Would an Acquirer See This Lock-In as a Risk?

Buy­ers of SaaS com­pa­nies run a tech­ni­cal due dili­gence process. Part of it is: “If we had to migrate this prod­uct off the cur­rent plat­form, how painful is that?”

Plat­forms that are easy to migrate away from (and don’t offer any unique advan­tage) are neu­tral. Plat­forms that lock you in (and don’t offer com­pen­sat­ing val­ue) are lia­bil­i­ties.

Exam­ple: If you chose Heroku because “it was easy to get start­ed,” but Heroku does­n’t offer any­thing unique your acquir­er could­n’t repli­cate in AWS in 2 weeks, you picked wrong. The lock-in is a cost with no ben­e­fit.

But if you chose a plat­form like Sales­force Light­ning because your entire prod­uct is an exten­sion of Sales­force (and your ICP is Sales­force-first), then the lock-in is insep­a­ra­ble from the prod­uct val­ue. An acquir­er gets that and does­n’t dis­count.

---

The 13 Leading PaaS Companies

I’ve eval­u­at­ed these plat­forms across the four ques­tions above. Here’s what you need to know about each.

1. AWS Elastic Beanstalk

AWS Elas­tic Beanstalk is a ful­ly man­aged appli­ca­tion deploy­ment ser­vice with­in AWS. You upload your appli­ca­tion code, and Beanstalk han­dles the infrastructure—servers, load bal­anc­ing, autoscal­ing, and mon­i­tor­ing. It sup­ports Python, Java, PHP, C++, .NET, Ruby, Go, and Node.js.

What it’s best for: Teams already in the AWS ecosys­tem. If you’re using RDS, S3, Lamb­da, and oth­er AWS ser­vices, Beanstalk is the nat­ur­al host­ing lay­er. It’s also sol­id for teams with ops expe­ri­ence who want to avoid man­ag­ing Kuber­netes but want fine-grained con­trol over their infra­struc­ture.

Pric­ing & cost real­i­ty: Elas­tic Beanstalk itself is free—you pay for the under­ly­ing EC2 instances, RDS data­bas­es, and data trans­fer. A typ­i­cal small work­load (2–4 t3.medium instances) runs $200–$500 month­ly. At scale, the cost advan­tage appears if you have vari­able traf­fic (autoscal­ing down dur­ing off-hours). But unlike man­aged plat­forms, you still need to opti­mize instance types and ter­mi­na­tion policies—or you’ll over­pay.

CEO-lev­el trade­off: Lock-in is high. You’re using AWS-native fea­tures (VPC, secu­ri­ty groups, IAM roles, RDS) that don’t port else­where. Switch­ing to Azure or GCP requires rewrit­ing net­work lay­er and data­base con­nec­tiv­i­ty. Switch­ing cost is 4–8 weeks of engi­neer­ing work. But the upside is cost con­trol and fine-grained secu­ri­ty. Acquir­ers don’t dis­count for Elas­tic Beanstalk specifically—it’s table stakes in SaaS.

---

2. Microsoft Azure

Azure is Microsoft­’s pub­lic cloud plat­form, offer­ing PaaS through App Ser­vice (man­aged web host­ing), SQL Data­base, and inte­grat­ed devel­op­ment tools. It’s tight­ly cou­pled with Visu­al Stu­dio, .NET, and Microsoft­’s ecosystem—but it also sup­ports Node.js, Python, Java, and Go.

What it’s best for: Enter­prise com­pa­nies with exist­ing Microsoft deploy­ments (Active Direc­to­ry, Exchange, Office 365, Dynam­ics). If your cus­tomer base is Enter­prise and requires com­pli­ance with Microsoft­’s data res­i­den­cy or secu­ri­ty stan­dards, Azure has native inte­gra­tions that reduce fric­tion. Also strong for com­pa­nies build­ing hybrid deploy­ments (on-premis­es + cloud).

Pric­ing & cost real­i­ty: App Ser­vice starts at $12–$100+ month­ly depend­ing on tier (free tier avail­able for test­ing). Data­base costs scale with size and through­put. A mid-mar­ket work­load (B2 app ser­vice tier + SQL Stan­dard) runs $300–$1,000 month­ly. Azure’s pric­ing is more opaque than AWS—the cal­cu­la­tor can be con­fus­ing, so watch for sur­prise over­ages in data egress and data­base back­ups.

CEO-lev­el trade­off: Medi­um lock-in. You’re not locked into Azure-spe­cif­ic for­mats like Beanstalk is locked into AWS ser­vices, but switch­ing off Visu­al Stu­dio tool­ing and Azure-native ser­vices (AD, Key Vault) is annoy­ing. Medi­um switch­ing cost (2–4 weeks). Acquir­ers appre­ci­ate the Microsoft inte­gra­tion if your cus­tomer base is also Microsoft-heavy, but don’t oth­er­wise view it as a strate­gic advan­tage.

---

3. Google App Engine

Google App Engine is a server­less plat­form (autoscal­ing, no servers to man­age) that runs Node.js, Python, Java, Go, and PHP. It auto-scales from zero to thou­sands of instances based on traf­fic. You deploy code, and App Engine han­dles the rest.

What it’s best for: Star­tups at $2M ARR with spiky or unpre­dictable traf­fic. The “scale to zero” mod­el is per­fect for ear­ly-stage workloads—you pay only for traf­fic you actu­al­ly han­dle. Also ide­al if you’re heav­i­ly using Google Cloud ser­vices (Big­Query, Fire­store, Pub/Sub) and want a cohe­sive ecosys­tem.

Pric­ing & cost real­i­ty: Pay-per-request pric­ing. A typ­i­cal ear­ly-stage app (10–50 requests per sec­ond) costs $100–$500 month­ly. The advan­tage is you don’t pay for idle capac­i­ty. The trap: as you grow beyond ~500 requests per sec­ond, the per-request cost becomes inef­fi­cient com­pared to reserved instances on AWS or Azure. Switch point is usu­al­ly around $1M–$2M ARR.

CEO-lev­el trade­off: Low switch­ing cost ear­ly (you’re just mov­ing a con­tainer­ized app). But as you grow, you hit Google Cloud’s pric­ing inflec­tion where server­less becomes expen­sive and you’ll want to migrate to Com­pute Engine or anoth­er provider. Medi­um lock-in to Google Cloud’s ecosys­tem (Big­Query, Pub/Sub). Acquir­ers don’t see this as a risk—just a rou­tine migra­tion.

---

4. Heroku

Heroku is a con­tain­er-based PaaS where you push a Git repos­i­to­ry and Heroku builds and deploys your appli­ca­tion. It abstracts away infra­struc­ture entirely—no servers, secu­ri­ty groups, or load-bal­anc­ing con­fig­u­ra­tion. Sup­ports Node.js, Python, Ruby, Java, Go, PHP, Scala, and Clo­jure.

What it’s best for: Boot­strapped or ear­ly-stage SaaS com­pa­nies ($3M ARR) with small to medi­um work­loads. The 10-minute onboard­ing and “deploy with a Git push” mod­el is unbeat­able for speed. Also strong for teams with lim­it­ed ops experience—you get a work­ing prod­uct in pro­duc­tion in hours, not weeks.

Pric­ing & cost real­i­ty: This is where Heroku becomes con­tro­ver­sial. Dynos (appli­ca­tion con­tain­ers) start at $7/month for hob­by tier (lim­it­ed) or $25+/month for pro­duc­tion tier. A small work­load (1x web dyno + 1x work­er dyno + Post­gres) costs $100–$200 month­ly. But at scale, Heroku becomes expen­sive. The same work­load on AWS costs $30–$50 month­ly. At $5M ARR, switch­ing off Heroku to AWS saves $500K–$1M annually—and founders real­ize they over­paid for 3 years.

CEO-lev­el trade­off: High switch­ing cost to per­for­mance. You’re pay­ing a 5–10x markup on com­pute hours for sim­plic­i­ty. That’s fine at $1M ARR. It’s a mate­r­i­al COGS leak at $5M+ ARR. Lock-in is low (migrat­ing a Heroku app to AWS is straight­for­ward). Acquir­ers don’t penal­ize you for Heroku—they just add “re-plat­form” as a line item in their 100-day plan. If you stay on Heroku past $3M ARR, you’re leav­ing mon­ey on the table.

---

5. IBM Cloud Foundry

IBM Cloud Foundry is an enter­prise-grade open-source PaaS based on the Cloud Foundry frame­work. It runs on-premis­es or in the cloud, han­dles appli­ca­tion deploy­ment, and pro­vides mid­dle­ware (data­bas­es, mes­sage queues, caching). Sup­ports Java, Python, Node.js, Go, and oth­ers.

What it’s best for: Enter­prise com­pa­nies with strict data res­i­den­cy or com­pli­ance require­ments (finan­cial ser­vices, health­care). If you need to run your appli­ca­tion in a pri­vate data cen­ter and still get PaaS ben­e­fits, Cloud Foundry is the stan­dard. Also strong for hybrid deploy­ments (some work­loads on-premis­es, oth­ers in cloud).

Pric­ing & cost real­i­ty: If you’re using IBM Cloud’s man­aged Cloud Foundry, pric­ing is sim­i­lar to Azure (pay for com­pute and stor­age). If you’re run­ning it on-premis­es, you pay licens­ing costs + infra­struc­ture. Hard to generalize—talk to IBM. Small work­loads: $200–$500/month man­aged. Large work­loads with hybrid require­ments: $5K–$20K/month.

CEO-lev­el trade­off: This is enter­prise-grade infra­struc­ture. You get com­pli­ance, secu­ri­ty, and oper­a­tional maturity—but at the cost of com­plex­i­ty and inflex­i­bil­i­ty. Lock-in is very high (you’re deeply inte­grat­ed with Cloud Foundry inter­nals). Medi­um switch­ing cost (4–8 weeks to migrate out). Acquir­ers respect Cloud Foundry in reg­u­lat­ed indus­tries, but view it as a strate­gic neces­si­ty, not a dif­fer­en­tia­tor.

---

6. Red Hat OpenShift

Red Hat Open­Shift is a Kuber­netes-based con­tain­er plat­form that can run on-premis­es, on AWS, Azure, GCP, or hybrid. It abstracts Kuber­netes com­plex­i­ty away—you deploy con­tain­ers and Open­Shift han­dles orches­tra­tion, net­work­ing, and scal­ing. Sup­ports any con­tainer­ized work­load.

What it’s best for: Mid-mar­ket com­pa­nies ($10M–$50M ARR) with cloud-agnos­tic require­ments. If you want to avoid sin­gle-cloud lock-in, Open­Shift lets you run the same Kuber­netes clus­ter across mul­ti­ple cloud providers. Also ide­al for com­plex, con­tainer­ized appli­ca­tions with strict net­work­ing or com­pli­ance needs.

Pric­ing & cost real­i­ty: Open­Shift is sold as a sub­scrip­tion ($0–$5K per month man­aged, varies by sup­port tier). You pay on top of the under­ly­ing cloud provider’s com­pute costs. A medi­um work­load on Open­Shift: $2K–$5K/month total (cloud provider + Open­Shift sub­scrip­tion). More expen­sive than bare Kuber­netes, but the oper­a­tional sim­plic­i­ty and porta­bil­i­ty jus­ti­fy it for large teams.

CEO-lev­el trade­off: Lock-in is medi­um (Kuber­netes is portable; Open­Shift-spe­cif­ic fea­tures are not). Switch­ing cost is low if you stick to stan­dard Kuber­netes fea­tures, high­er if you use Open­Shift-spe­cif­ic tool­ing. Acquir­ers don’t view Kuber­netes-based deploy­ments as a risk—it’s the indus­try stan­dard for scale. Major advan­tage: you’re not locked into AWS or Azure’s pro­pri­etary ser­vices.

---

7. Oracle Cloud Platform

Ora­cle Cloud Plat­form offers PaaS through Ora­cle Data­base Cloud, Appli­ca­tion Con­tain­er Cloud, and var­i­ous man­aged ser­vices. It’s built for com­pa­nies already invest­ed in Ora­cle tech­nolo­gies (Data­base, Enter­prise apps).

What it’s best for: Enter­prise com­pa­nies run­ning Ora­cle data­bas­es and ERP sys­tems who want a cloud-native path for­ward. If your core appli­ca­tion is Ora­cle Data­base-depen­dent, Ora­cle Cloud offers tight inte­gra­tion. Also strong for busi­ness­es with long-term Ora­cle licens­ing agree­ments who can con­sol­i­date on Ora­cle infra­struc­ture.

Pric­ing & cost real­i­ty: Ora­cle uses a com­plex con­sump­tion mod­el. A basic work­load (Ora­cle Data­base + Appli­ca­tion Con­tain­er) might cost $500–$2K month­ly. Enter­prise agree­ments can be much high­er. The pric­ing advan­tage comes if you’re con­sol­i­dat­ing Ora­cle licens­es (on-premis­es + cloud) onto a sin­gle Ora­cle Cloud contract—potentially sav­ing 20–30% ver­sus run­ning sep­a­rate­ly.

CEO-lev­el trade­off: Very high lock-in. You’re deeply embed­ded in Ora­cle’s ecosys­tem. Switch­ing to anoth­er data­base or cloud provider requires a full re-archi­tec­ture. Switch­ing cost is 6–12 weeks of engi­neer­ing. But this lock-in is only a risk if you’re not hap­py with Oracle—and most com­pa­nies choos­ing Ora­cle Cloud are hap­py because they’re already Ora­cle-depen­dent. Acquir­ers expect this and don’t dis­count.

---

8. SAP HANA Cloud

SAP HANA Cloud is a cloud-native data­base and appli­ca­tion plat­form. It’s designed for in-mem­o­ry ana­lyt­ics and trans­ac­tion­al pro­cess­ing. You deploy appli­ca­tions that work with SAP HANA’s data­base engine, gain­ing sub-sec­ond query per­for­mance on mas­sive datasets.

What it’s best for: Com­pa­nies with high-vol­ume ana­lyt­ics work­loads or real-time report­ing require­ments. If your appli­ca­tion involves ingest­ing 100+ GB of data dai­ly and run­ning com­plex joins instant­ly, HANA’s in-mem­o­ry archi­tec­ture is unmatched. Also strong for com­pa­nies extend­ing exist­ing SAP ERP sys­tems with cloud-native appli­ca­tions.

Pric­ing & cost real­i­ty: SAP HANA Cloud pric­ing is based on data vol­ume and com­pute tier. A starter con­fig­u­ra­tion: $1K–$3K month­ly. Enter­prise deploy­ments: $10K–$50K+ month­ly. It’s expen­sive because the in-mem­o­ry stor­age is cost­ly. But if you need real-time ana­lyt­ics at scale, the speed jus­ti­fies the cost.

CEO-lev­el trade­off: Extreme lock-in to HANA’s archi­tec­ture. The data­base schema and query log­ic are HANA-spe­cif­ic and don’t port to Post­gres or MySQL. Switch­ing cost is 8–12 weeks (requires rewrit­ing appli­ca­tion data lay­er and ana­lyt­ics log­ic). But if you have a ana­lyt­ics-first prod­uct, this lock-in is insep­a­ra­ble from the prod­uct value—an acquir­er expects it.

---

9. DigitalOcean

Dig­i­talO­cean is a devel­op­er-friend­ly cloud plat­form offer­ing sim­pli­fied IaaS (Droplets—VMs), man­aged data­bas­es, and a con­tain­er reg­istry. More recent­ly, it launched App Plat­form, a man­aged PaaS for deploy­ing con­tainer­ized appli­ca­tions. Sup­ports Node.js, Python, Go, Ruby, and cus­tom con­tain­ers.

What it’s best for: Star­tups and small teams ($5M ARR) who want sim­plic­i­ty with­out com­plex­i­ty. Dig­i­talO­cean’s UI and doc­u­men­ta­tion are the best in the industry—significantly clear­er than AWS’s. Also ide­al for devel­op­ers who want to avoid cloud provider lock-in while still get­ting man­aged ser­vices (data­bas­es, load bal­anc­ing).

Pric­ing & cost real­i­ty: Droplets start at $5/month (for tiny work­loads, not pro­duc­tion). A real­is­tic small pro­duc­tion work­load (2x $12 Droplets + Man­aged Post­gres) costs $60–$100 month­ly. App Plat­form pric­ing is $0–$500 month­ly depend­ing on com­pute. Dig­i­talO­cean’s pric­ing is typ­i­cal­ly 30–50% cheap­er than AWS for equiv­a­lent work­loads at small scale.

CEO-lev­el trade­off: Low lock-in. Dig­i­talO­cean uses stan­dard Lin­ux, Post­gres, and containerization—nothing pro­pri­etary. Switch­ing to AWS or anoth­er provider is straight­for­ward. Switch­ing cost is low (2–4 weeks). Acquir­ers don’t view Dig­i­talO­cean as a strate­gic problem—it’s sim­ple enough to migrate. The trade-off is that Dig­i­talO­cean does­n’t offer the advanced ser­vices (machine learn­ing, advanced ana­lyt­ics) that AWS does.

---

10. Pivotal Cloud Foundry (Now VMware Tanzu)

Piv­otal Cloud Foundry (now rebrand­ed as VMware Tanzu) is an enter­prise-grade Kuber­netes-based plat­form. It sim­pli­fies Kuber­netes man­age­ment and pro­vides pre-built appli­ca­tion ser­vices. Owned by VMware, used pri­mar­i­ly in reg­u­lat­ed indus­tries.

What it’s best for: Enter­prise com­pa­nies (>$20M ARR) with com­plex Kuber­netes require­ments and strict oper­a­tional gov­er­nance. If you need to run con­tain­ers at scale with cen­tral­ized secu­ri­ty, com­pli­ance, and resource man­age­ment, Tanzu pro­vides the abstrac­tion lay­er. Also strong for com­pa­nies with exist­ing VMware infra­struc­ture.

Pric­ing & cost real­i­ty: Tanzu is sold as a sub­scrip­tion ($300–$3K+ per month) plus cloud provider costs. A medi­um deploy­ment: $2K–$5K/month total. Expen­sive, but the oper­a­tional sim­plic­i­ty and com­pli­ance automa­tion jus­ti­fy it for large orga­ni­za­tions.

CEO-lev­el trade­off: Medi­um lock-in to Kuber­netes and Tanzu-spe­cif­ic tool­ing. Switch­ing away requires mov­ing to plain Kuber­netes or anoth­er orches­tra­tion plat­form (3–6 months of work). But Kuber­netes itself is portable. Acquir­ers view Tanzu neutrally—it’s enter­prise infra­struc­ture that does­n’t solve a busi­ness prob­lem by itself, just enables oper­a­tions.

---

11. Mendix

Men­dix is a low-code/no-code appli­ca­tion devel­op­ment plat­form (owned by Siemens). Instead of writ­ing code, you build appli­ca­tions visu­al­ly, drag­ging and drop­ping com­po­nents. It’s designed for non-devel­op­ers and cit­i­zen developers—enabling busi­ness teams to build apps with­out a large engi­neer­ing depart­ment.

What it’s best for: Enter­prise cus­tomers and gov­ern­ment agen­cies who need rapid appli­ca­tion deliv­ery with min­i­mal engi­neer­ing head­count. Men­dix reduces time-to-mar­ket for CRUD appli­ca­tions (forms, work­flows, report­ing) from weeks to days. Also strong for com­pa­nies build­ing mul­ti­ple inter­nal tools or depart­ment-spe­cif­ic appli­ca­tions.

Pric­ing & cost real­i­ty: Men­dix is usage-based. Pric­ing starts around $1K–$5K per month for small appli­ca­tions and scales to $10K–$50K+ for enter­prise deploy­ments. The cost advan­tage: you need few­er engi­neers (or no engi­neers). A typ­i­cal busi­ness team might deliv­er 5–10 appli­ca­tions with 1 FTE instead of need­ing 5 FTEs to write cus­tom code.

CEO-lev­el trade­off: Very high lock-in. Appli­ca­tions built in Men­dix are Men­dix-pro­pri­etary and require Men­dix to run. Switch­ing cost is not mea­sured in engi­neer­ing weeks—it’s a full rewrite in a dif­fer­ent plat­form. But this lock-in is by design. If you’re using Men­dix, you’re in it for the long term. Acquir­ers know this and price it in. The ques­tion is: does the appli­ca­tion built in Men­dix solve a core busi­ness prob­lem? If yes, the lock-in is accept­able. If no, it’s a lia­bil­i­ty.

---

12. Engine Yard

Engine Yard is a man­aged PaaS specif­i­cal­ly designed for Ruby on Rails, Node.js, and PHP appli­ca­tions. It han­dles deploy­ment, mon­i­tor­ing, scal­ing, and oper­a­tional over­head. Acquired by Rem­e­dy but still oper­at­ing, it serves devel­op­ers who want a Rails-native plat­form with­out the Heroku pre­mi­um.

What it’s best for: Star­tups with Ruby on Rails appli­ca­tions who want Heroku-like sim­plic­i­ty at 50% the cost. Also good for teams that need more cus­tomiza­tion than Heroku allows but less com­plex­i­ty than rolling your own infra­struc­ture.

Pric­ing & cost real­i­ty: Engine Yard pric­ing starts around $100–$300 month­ly for small deploy­ments. At scale (10+ instances), costs are typ­i­cal­ly 40–60% low­er than equiv­a­lent Heroku work­loads. For a start­up at $1M–$5M ARR with a Rails app, Engine Yard saves $50K–$200K annu­al­ly com­pared to Heroku.

CEO-lev­el trade­off: Low to medi­um lock-in. Engine Yard uses stan­dard Ruby, Node, and PHP—so switch­ing away is straight­for­ward. But you’re still depen­dent on Engine Yard’s plat­form for deploy­ments and scal­ing, so mov­ing to self-man­aged infra­struc­ture requires work (3–6 weeks). Acquir­ers view Engine Yard as equiv­a­lent to Heroku—a con­ve­nience cost that you’ll elim­i­nate post-acqui­si­tion.

---

13. Salesforce Lightning

Sales­force Light­ning is a low-code plat­form for build­ing cus­tom appli­ca­tions with­in the Sales­force ecosys­tem. You drag and drop com­po­nents to build cus­tom apps, busi­ness process­es, and automa­tions. It’s tight­ly inte­grat­ed with Sales­force CRM, Ein­stein AI, and Sales­force data.

What it’s best for: Com­pa­nies sell­ing to Sales­force-native cus­tomers. If your prod­uct is an exten­sion of Sales­force or requires Sales­force CRM data to func­tion, Light­ning lets you build inside Sales­force and reach cus­tomers direct­ly. Also strong for build­ing inter­nal Sales­force apps (sales tools, mar­ket­ing automa­tion, sup­port work­flows).

Pric­ing & cost real­i­ty: Light­ning devel­op­ment is includ­ed in Sales­force licens­es. If you’re build­ing an app for inter­nal use, you’re just pay­ing Sales­force’s base license (~$100–$500 per user month­ly). If you’re build­ing an app for exter­nal cus­tomers, you can sell it via Sales­force AppEx­change and pay Sales­force a com­mis­sion (typ­i­cal­ly 10–20%).

CEO-lev­el trade­off: Extreme lock-in—by design. A Light­ning app is a Sales­force app and can’t run out­side Sales­force. But this lock-in is strate­gic for the right busi­ness. If your entire mar­ket is Sales­force cus­tomers and you’re try­ing to inte­grate with their work­flows, Light­ning is the right choice. Acquir­ers acquir­ing a Sales­force-native prod­uct expect this lock-in and pay accord­ing­ly. The risk only appears if you’re build­ing on Light­ning and your mar­ket isn’t actu­al­ly Sales­force-cen­tric.

---

Picking the Right PaaS Category — A Decision Tree

You now have exam­ples of PaaS com­pa­nies across dif­fer­ent cat­e­gories. But which cat­e­go­ry fits your stage?

---

The 5 Types of PaaS, and When Each Makes Sense at Your Stage

1. Public PaaS

Pub­lic PaaS (AWS Elas­tic Beanstalk, Heroku, Dig­i­talO­cean App Plat­form, Google App Engine) runs on the ven­dor’s pub­lic cloud. The ven­dor man­ages all infra­struc­ture. You con­trol your appli­ca­tion and data.

When to use: Default choice for star­tups at $15M ARR. You get fast deploy­ments, autoscal­ing, and cost-effi­cient com­pute. No on-premis­es com­plex­i­ty.

Trade-off: You’re depen­dent on the ven­dor’s pric­ing, uptime, and API com­pat­i­bil­i­ty. But that’s accept­able at ear­ly stage because switch­ing cost is low (2–4 weeks of migra­tion).

At what stage to recon­sid­er: Around $5M–$10M ARR, as you grow, revis­it whether the PaaS ven­dor’s pric­ing is still cost-effec­tive. Heroku becomes expen­sive. AWS Elas­tic Beanstalk becomes opti­miz­able. Dig­i­talO­cean stays com­pet­i­tive.

---

2. Private PaaS

Pri­vate PaaS (IBM Cloud Foundry, Open­Shift run­ning on-premis­es) runs inside your own infra­struc­ture or a pri­vate cloud. The ven­dor pro­vides the plat­form; you pro­vide the hard­ware. You get PaaS ben­e­fits (auto­mat­ed deploy­ment, scal­ing, mon­i­tor­ing) while con­trol­ling data loca­tion.

When to use: When com­pli­ance or data res­i­den­cy man­dates that data nev­er leave your infra­struc­ture. Finan­cial ser­vices, health­care, gov­ern­ment agen­cies. Also used when you have exist­ing on-premis­es infra­struc­ture and want to cloud-ify it grad­u­al­ly.

Trade-off: You man­age the under­ly­ing hard­ware, secu­ri­ty patch­es, and dis­as­ter recov­ery. You also need more ops head­count. Not cost-effec­tive unless you have strict reg­u­la­to­ry require­ments or are con­sol­i­dat­ing exist­ing infra­struc­ture.

At what stage to recon­sid­er: Only use this if you have no choice (reg­u­la­to­ry require­ment) or are already run­ning sig­nif­i­cant on-premis­es infra­struc­ture.

---

3. Hybrid PaaS

Hybrid PaaS (Open­Shift, Azure Stack, AWS Out­posts) runs across both pub­lic cloud and on-premis­es infra­struc­ture. You deploy once and scale across both envi­ron­ments. Use­ful when you’re grad­u­al­ly migrat­ing from on-premis­es to cloud.

When to use: Dur­ing a long migra­tion from data cen­ter to cloud. You run pro­duc­tion on-premis­es today but want to grad­u­al­ly move work­loads to the cloud. Hybrid PaaS lets you do this with­out re-archi­tect­ing.

Trade-off: Com­plex oper­a­tional mod­el. You’re man­ag­ing two infra­struc­ture stacks instead of one. Requires sig­nif­i­cant ops invest­ment.

At what stage to recon­sid­er: Typ­i­cal­ly a 3–5 year strat­e­gy for large enter­pris­es. Not rel­e­vant for star­tups unless you have inher­it­ed on-premis­es infra­struc­ture you’re stuck with.

---

4. Mobile PaaS

Mobile PaaS (Fire­base, AWS Ampli­fy) is opti­mized for mobile and web appli­ca­tions. Built-in authen­ti­ca­tion, real-time data­bas­es, push noti­fi­ca­tions, and ana­lyt­ics. Designed for teams build­ing con­sumer or mobile-first apps.

When to use: If your prod­uct is pri­mar­i­ly mobile (iOS/Android) or you’re build­ing a con­sumer app. Mobile PaaS han­dles push noti­fi­ca­tions, offline sync, and authen­ti­ca­tion out of the box.

Trade-off: Opin­ion­at­ed toward mobile use cas­es. Not great if you’re build­ing com­plex serv­er-side log­ic or need cus­tom infra­struc­ture.

At what stage to recon­sid­er: Start on Mobile PaaS for con­sumer apps. By $5M ARR, you may want to tran­si­tion to a more flex­i­ble plat­form if you’ve out­grown the opin­ion­at­ed defaults.

---

5. Open PaaS

Open PaaS (Cloud Foundry, Kuber­netes, Open­Stack) are open-source plat­forms you can deploy your­self. You main­tain the plat­form, not a ven­dor. Use­ful when you want to avoid ven­dor lock-in or run across mul­ti­ple clouds.

When to use: Mid-mar­ket com­pa­nies ($10M–$50M ARR) who want cloud-agnos­tic infra­struc­ture. Also used by com­pa­nies build­ing inter­nal plat­forms for many appli­ca­tion teams.

Trade-off: You own the oper­a­tional bur­den. You’re respon­si­ble for secu­ri­ty patch­es, upgrades, and per­for­mance tun­ing. Requires expert ops head­count.

At what stage to recon­sid­er: Don’t adopt Open PaaS until you have 2–3 engi­neers ded­i­cat­ed to infra­struc­ture. Before that, use man­aged plat­forms.

---

Common Mistakes Founders Make with PaaS Decisions

Most of these mis­takes cost $100K–$1M by the time you real­ize them. Here’s how to avoid them:

1. Picking the Platform Your CTO Knows Instead of What Matches Your Economics

Your CTO might love Kuber­netes because they learned it at Google. But if you’re at $3M ARR with a small team, Kuber­netes is overkill—you’re spend­ing 0.5 FTE on infra­struc­ture that a man­aged plat­form han­dles. Pick the plat­form that match­es your stage, not your tech bias.

The test: If you need to hire a new engi­neer to oper­ate the plat­form, you picked the wrong plat­form.

2. Underestimating Egress Fees and Per-Service Costs

AWS has made a for­tune on egress charges (data leav­ing AWS). Azure charges for out­bound data trans­fer. These fees are real and com­pound at scale.

If your appli­ca­tion streams 10 TB of data month­ly from AWS S3 to a third-par­ty ana­lyt­ics tool, you’re pay­ing $900/month in egress. Over 3 years, that’s $32K.

The test: Cal­cu­late your esti­mat­ed data trans­fer before com­mit­ting to a plat­form. Use the cloud provider’s cal­cu­la­tor.

3. Picking “Free Tier” When Your Scale Will Destroy You at Pricing Cliff

Google App Engine has a gen­er­ous free tier. Heroku has a free tier. Fire­base has a free tier. All of them have pric­ing cliffs—the moment you exceed the free tier, costs jump 10–100x.

If you build on the free tier, get trac­tion, and then hit the pric­ing cliff at $3K/month when you expect­ed $300/month, you’ve under­es­ti­mat­ed your go-to-mar­ket costs.

The test: Do paid capac­i­ty plan­ning from day 1. Don’t build on free tiers.

4. Letting Your CTO Lock You Into Kubernetes Complexity You Don’t Need

Kuber­netes is pow­er­ful and can scale infi­nite­ly. But you don’t need it at $10M ARR. You need sim­plic­i­ty.

If your CTO insists on Kuber­netes because “it scales,” but you’re run­ning 3 instances of a rel­a­tive­ly sim­ple appli­ca­tion, you’re pay­ing for com­plex­i­ty that does­n’t serve you. You’ve hired an ops engi­neer who’s under­uti­lized.

The test: If you can’t artic­u­late why Kuber­netes solves a busi­ness prob­lem (not a tech­ni­cal pref­er­ence), don’t use it.

5. Not Revisiting the Decision as You Scale

You picked Heroku at $0 ARR, and it was per­fect. At $2M ARR, it’s still good. At $5M ARR, it’s cost­ing you $1M annu­al­ly more than AWS. You’ve just been pay­ing the pre­mi­um on autopi­lot.

The test: Every 18 months (or at major rev­enue mile­stones), run a cost-ben­e­fit analy­sis on your plat­form. Would it save more to migrate than to stay?

---

How PaaS Choice Shows Up in Your Exit

This is the part most founders miss until they’re in the M&A process.

When a buy­er eval­u­ates your com­pa­ny, they run finan­cial mod­els to esti­mate post-acqui­si­tion prof­itabil­i­ty. Part of that mod­el is COGS.

If your COGS is 25% of rev­enue due to inef­fi­cient PaaS pric­ing, the buy­er mod­els 15% COGS post-acqui­si­tion (after they opti­mize on their infra­struc­ture). The difference—10 per­cent­age points—is worth 15–25% of your com­pa­ny’s val­u­a­tion.

Here’s a con­crete exam­ple. Com­pa­ny A and Com­pa­ny B both have $10M ARR and 75% gross mar­gin.

• Com­pa­ny A: Chose Heroku ear­ly. At scale, costs $1.5M annu­al­ly. Gross mar­gin: 70%.
• Com­pa­ny B: Chose AWS Elas­tic Beanstalk ear­ly. At scale, costs $500K annu­al­ly. Gross mar­gin: 75%.

Both com­pa­nies are at $10M ARR, but the buy­er sees:

• Com­pa­ny A: $10M × 70% = $7M gross prof­it today. Post-migra­tion off Heroku (saves ~$1M/yr): $10M × 80% = $8M gross prof­it. Upside: $1M of annu­al­ized gross prof­it.
• Com­pa­ny B: $10M × 75% = $7.5M gross prof­it today. Post-opti­miza­tion (tighter instance siz­ing, reserved pric­ing): $10M × 77% = $7.7M gross prof­it. Upside: $200K.

Com­pa­ny B gets a high­er val­u­a­tion because there’s less oper­a­tional arbi­trage left for the buy­er to cap­ture. The buy­er pays for effi­cien­cy — they won’t pay twice for sav­ings they have to deliv­er them­selves.

At a 5× EBITDA mul­ti­ple, the $1M gross-prof­it upside for Com­pa­ny A is worth rough­ly $5M of enter­prise val­ue to the buy­er — but the buy­er keeps most of that because they’re the ones exe­cut­ing the migra­tion. Com­pa­ny B’s already-opti­mized state is worth $2M–$5M more in enter­prise val­ue because the buy­er does­n’t have to dis­count for migra­tion risk. On a $10M ARR busi­ness like­ly trad­ing at $40M–$80M, that’s a 5–10% swing in sale price.

Beyond COGS, acquir­ers also look at ven­dor lock-in risk. If you’re on Heroku and need to migrate post-acqui­si­tion, they dis­count your val­u­a­tion because they’re buy­ing an inte­gra­tion project, not a sta­ble busi­ness. If you’re on AWS with no ven­dor-spe­cif­ic fea­tures, there’s no lock-in risk and they don’t dis­count.

The PaaS choice you make at $500K ARR shows up in your exit at $10M ARR. Choose care­ful­ly.

---

FAQ

Is PaaS cheaper than IaaS?

At ear­ly stage ($1M ARR), PaaS is typ­i­cal­ly cheap­er because you’re pay­ing for sim­plic­i­ty, not raw com­pute hours. But at scale (>$5M ARR), IaaS (AWS EC2, Azure VMs) often becomes cheap­er per unit of com­pute. The trade-off is oper­a­tional com­plex­i­ty: IaaS requires ops head­count; PaaS is more hands-off.

The real ques­tion isn’t “Which is cheap­er?” but “What’s your total cost of own­er­ship?” If PaaS saves you a half-time ops engi­neer, and that engi­neer costs $80K annu­al­ly, then pay­ing $100K/year on PaaS is a win.

What’s the difference between PaaS and SaaS?

PaaS is a plat­form you use to build appli­ca­tions. You write code, deploy to the plat­form, and the plat­form runs it.

SaaS is a fin­ished appli­ca­tion that end-users buy. You use SaaS (e.g., Sales­force, Slack); you build on PaaS (e.g., Heroku, AWS Elas­tic Beanstalk).

As a SaaS founder, you’re both build­ing on PaaS and sell­ing SaaS. You might deploy your appli­ca­tion to Heroku (PaaS) and sell access to it as a SaaS prod­uct.

Can you migrate from one PaaS to another?

Yes, but the effort depends on which plat­forms you’re migrat­ing between.

Easy migra­tions (2–4 weeks): Heroku → AWS, Dig­i­talO­cean → AWS, Engine Yard → AWS.

Medi­um migra­tions (4–8 weeks): Google App Engine → AWS (requires rewrit­ing server­less log­ic), Sales­force Light­ning → cus­tom app (major rewrite required).

Hard migra­tions (8–16 weeks): Ora­cle Cloud → AWS, SAP HANA Cloud → dif­fer­ent data­base (requires data lay­er rewrite), Kuber­netes → AWS (requires re-archi­tect­ing orches­tra­tion).

The rule: low­er lock-in means faster migra­tion.

Is Heroku still worth it?

Heroku is worth it only if you’re at $2M ARR and your engi­neer time is the con­straint (not cloud spend). At that stage, Heroku’s sim­plic­i­ty is a 10x pro­duc­tiv­i­ty mul­ti­pli­er.

But if you’re >$2M ARR and not grow­ing engi­neer­ing head­count faster than rev­enue, move to AWS or Dig­i­talO­cean. Heroku’s pre­mi­um becomes hard to jus­ti­fy.

Do enterprise SaaS companies use PaaS or roll their own?

Sub-$5M ARR: Most­ly use PaaS (Heroku, AWS Elas­tic Beanstalk, Dig­i­talO­cean). Speed and sim­plic­i­ty mat­ter more than cost opti­miza­tion.

$5M–$20M ARR: Mix of PaaS and man­aged Kuber­netes (EKS on AWS, AKS on Azure). Some plat­forms still use Heroku, but they’ve often start­ed think­ing about a migra­tion.

$20M+ ARR: Often on bare Kuber­netes or self-man­aged infra­struc­ture (rolling their own). At this scale, they have enough engi­neers to man­age the com­plex­i­ty and jus­ti­fy the cost sav­ings.

But there are excep­tions. If your prod­uct has unique infra­struc­ture require­ments (real-time ana­lyt­ics, com­plex state man­age­ment), you might roll your own at any scale.

---

Conclusion

The 13 PaaS com­pa­nies I’ve out­lined serve dif­fer­ent stages and use cas­es. There’s no uni­ver­sal­ly “best” platform—only the best plat­form for your eco­nom­ics, team, and stage.

Start with the 4 ques­tions:

1. Does this deci­sion show up in COGS or R&D?
2. What’s my switch­ing cost if I need to leave?
3. Does this plat­form force me to run more engi­neers or few­er?
4. Would an acquir­er see this lock-in as a risk?

Answer those first. The plat­form choice will fol­low.

And one more: revis­it the choice every 18 months. The plat­form that’s per­fect at $1M ARR might be cost­ing you $500K annu­al­ly at $5M ARR. The best time to migrate was yes­ter­day; the sec­ond best time is today.