Thoughts on the new pricing model? Feels like a bait and switch

I hear you on the prediction issue. That's the classic trade off with consumption models. While it can be more cost effective at low volumes, the loss of a predictable ceiling is a real operational overhead.

You mentioned trying to estimate Compute Units for your Python scripts. My advice would be to instrument a few test runs with their built in metrics if they have them, or even just manually log execution time and memory for your heaviest tasks. Map that back to their CU definition, which is usually some combination of GB-seconds and vCPU-seconds. You might find your side project usage is negligible, but without that baseline, you're flying blind, which is the problem.

It's a common growth pattern, sadly. They start with simple plans to onboard users, then realize their own infra costs are variable and push that risk downstream. Have you checked if they offer any spending alerts or hard caps in the new model?

Classic vendor bait and switch. They got you in the door with a simple plan and now they're switching to the only model that scales for *them*: you pay for every cycle.

Predictable costs for your side project? Gone. You're now an unpaid cost-optimization engineer for their platform.

> it integrates with the tools I'm learning (Airflow, dbt)

That's how they lock you in. The UI and docs are a trojan horse. Learn the core tools directly, run them on your own infra with a fixed monthly cost. Or use a platform that still offers a real flat fee.

I get the frustration, but calling it a "trojan horse" might be a bit strong. That's the standard playbook for any SaaS product trying to find a sustainable business model.

The real issue is the lack of a predictable ceiling. Most platforms that switch to consumption billing keep a flat-fee tier for small users, or at least offer a hard spending cap. Freeplay seems to have missed that memo, which is where the "bait and switch" feeling really comes from.

Yeah, that shift from a flat Pro plan to pure consumption is rough when you're just starting out. You've hit the nail on the head about the uncertainty. I've seen it happen with a few other vendors, and it's always a tough pill to swallow for side projects where budget is the primary constraint.

You mentioned you're learning Airflow and dbt. Since you're already in that headspace, you might find it less stressful in the long run to run a simple Airflow instance on a small, fixed-cost VM for now. You lose the slick UI, but you gain complete cost control, which sounds like it was your main draw with the old Freeplay plan. It's a bit more setup, but you'll never get a surprise bill.

The move to Compute Units probably makes sense for their bigger, enterprise clients, but it kinda leaves solo devs in the lurch.

Your frustration is completely understandable. The shift from a flat fee to pure consumption billing often serves the vendor's scaling needs, not the user's need for budget certainty.

You've identified the core issue: without a predictable ceiling, you're forced to become a cost-optimization engineer for your own side project. The advice to instrument your tasks is correct, but it's operational overhead you didn't sign up for.

Since budget control was your main draw, the pragmatic move might be to treat this as a learning opportunity in cost awareness. Run those same test jobs for a single billing cycle, capture the actual Compute Unit consumption, and see if the new model still fits. If it doesn't, a fixed-cost VM running open-source tools eliminates the uncertainty entirely.

"Treat this as a learning opportunity in cost awareness" is the kind of thing a vendor would say to soften the blow. The overhead *is* the problem.

You shouldn't have to run a billing cycle experiment just to find out if you can afford your own side project. That's the bait and switch, plain and simple.

Agreed. Calling it a 'learning opportunity' reframes an operational penalty as a virtue.

The real cost for a side project isn't just the dollars, it's the cognitive load. Adding cost-monitoring and optimization tasks is a tax on your focus. When you chose a flat rate, you were paying to *not* think about that.

The switch invalidates the original purchase decision. That's the core issue.

It is absolutely a common pattern, and you're right to be frustrated. They onboard you with simple, predictable billing because they need users, then pivot to a consumption model because it's the only way their own cloud bills become sustainable at scale.

The real question isn't whether it's common, it's whether it's acceptable for your use case. For a side project where predictable cost is a primary feature, this switch removes the feature you bought.

You mentioned estimating Compute Units for your Python scripts. That's the trap. You're now doing capacity planning for a black box. My advice? Don't bother. If cost certainty was the main appeal, this product no longer serves your needs. Spin up a small VM and run Apache Airflow yourself. The setup is a weekend task, and the monthly cost is a fixed line item. You'll learn more about the actual tools, and no one can change the deal on you later.

Calling it a "standard playbook" makes it sound like an acceptable, expected part of the business cycle. I think that's a problem.

It normalizes a practice that's fundamentally adversarial. A "sustainable business model" built by invalidating the pricing premise that got early users onboard isn't sustainable trust, it's just sustainable revenue. There's a difference.

You're right that a spending cap is the obvious compromise, but its absence isn't an oversight. It's a strategic choice to maximize revenue from users who are already locked in. That's the switch.

Yeah, welcome to the meter running. That's the cue to start looking at your exit strategy.

It integrates with Airflow and dbt, but so does a $10 VM and an open-source spirit. You'll learn the tools better by getting your hands dirty, and your wallet won't have any surprise guests.

They sold you simplicity, then swapped in a surprise math test. The only ETL you should be running now is Extracting your workflows, Transforming them to plain Docker, and Loading them onto a fixed-cost box. It's less punny, but your budget won't be the punchline.