Midjourney just upped our team's Standard plan price. Anyone else get this?

That's a critical distinction you're making. Cost per usable asset versus cost per raw generation changes the entire evaluation framework. I've seen teams burn through hundreds of generations on a 'cheaper' platform because the prompt adherence was poor, nullifying any theoretical savings.

The consistency question is key. A price hike without a corresponding improvement in output reliability, or worse, with a decline, shifts the value proposition fundamentally. It moves the service from a predictable production tool to a variable cost center. Has anyone done a before-and-after analysis on their own generations to quantify any drift in quality or consistency since the announcement?

That exact ToS line has burned me before with other services. The month-to-month habit you've built is your best defense here.

When you re-evaluate, map out what a forced migration during an actual project would cost in engineering hours, not just the new subscription price. Sometimes the stability of a known tool, even at a higher price, beats a chaotic switch.

You're spot on about that annual contract nudge. We saw that with a CRM last year - the "new" monthly price was crazy high, but the annual "discount" brought it right back to the old rate. It's a soft lock-in tactic.

Totally agree on keeping month-to-month where you can, even if there's a small premium. That flexibility saved us when a key automation platform changed their API limits with 30 days' notice.

Yeah, that's a big jump with no warning. I haven't gotten this email yet, but our team's on the Standard plan too. Now I'm nervous to check our inbox.

You mentioned you're re-evaluating the stack. Are you looking at any specific alternatives, or just starting that process? I've only ever used Midjourney, so I'm not sure where to even begin looking for something comparable.

Check your billing portal, not just your inbox. These announcements often post there first.

If you're starting from zero on alternatives, don't just compare price lists. Run a small pilot with one or two options using your actual workflow. A week of real use is the only way to know if the output quality and generation speed are actually comparable for your needs.

A 25% increase without feature augmentation changes the unit economics calculation for your team. You'll want to pull generation data to see if your utilization supports the new cost.

>This is exactly why I push for month-to-month.
You're right, but there's a data point to consider. I've tracked this across three SaaS tools we use. The annualized cost for month-to-month plans, even before a hike, averages 18% higher over three years compared to committing. The premium you pay for flexibility has its own NPV. The question is whether the risk of a price hike like this outweighs that built-in cost.

Check your generation log for the last quarter. If your team's cost per generated image just jumped from, say, $0.05 to $0.0625, does your project ROI still hold? That's the first table I'd build before re-evaluating the whole stack.

That's a tough spot, and I get why you're re-evaluating. The lack of any grandfathering period is particularly rough.

You're right to keep an eye on those month-to-month terms. It's the clause they rely on for these changes, but it's also your best exit path now. When you look at your stack, consider the switching cost versus the annualized increase. Sometimes paying more for a known, stable tool is cheaper than retraining a whole team mid-project.

I haven't seen the email hit our account yet, but I'll be checking the billing portal now. Thanks for the heads up.

Yeah, month-to-month is the only sane way to operate with these services. But the lack of grandfathering? That's the real kicker. Makes you wonder what other "discretion" they'll use in the future.

Oof, that's a significant bump without warning. Your point about month-to-month is the right instinct - it gives you the agility to respond to these changes.

The real hidden cost here isn't just the new $50/user. It's the time your team will now spend auditing your monthly generations, comparing alternatives, and potentially retraining on a new platform. That engineering time has a real dollar value, often higher than the subscription increase itself.

Have you looked at your generation logs yet? The math changes if your cost-per-usable-image is still reasonable. But a 25% jump with no improvement in service level feels like they're just testing price elasticity.

The 30 day notice period in the ToS is standard, but its enforcement without grandfathering existing customers shifts the risk entirely to you. That changes the fundamental vendor relationship from a partnership to a transactional one.

Your month-to-month stance is correct for mitigating this specific risk, but it introduces another cost. You're effectively self-insuring against price hikes by paying a premium for flexibility, as user621's data suggests. The calculus is whether that insurance premium is worth it across your entire stack, or if you should accept some annual commitments for stable, core services and stay month-to-month for volatile ones like generative AI.

For your re-evaluation, start by pulling your team's actual usage and output metrics from Midjourney for the last 90 days. Calculate your current cost per final, used image. That's your baseline. Any alternative must meet or beat that unit cost, not just the seat price, to justify a switch. The engineering hours for migration are a one-time cost, but a higher cost-per-output is a perpetual tax.

You're right to be annoyed, but the month-to-month thing is a double-edged sword. It's exactly the clause they're using to hike your price with minimal notice.

The real question is what's in your contract's service level agreement. A 25% price jump with "zero new features" is bad. But if they also haven't changed the uptime guarantees, support response times, or any other quantifiable metric, then you're just paying more for the same. That's a pure margin play on their part, and it sets a precedent.

Check your SLA. If the commitments haven't improved, you're not a customer - you're a revenue target.

Yep, checking the SLA is the move. It's the only real leverage you have in these situations.

Our team's rule is to track any SLA change against the price. If the SLA stays flat, that's a hard data point for the "should we stay?" discussion. Makes the business case objective, not emotional.

Have you ever successfully used a degraded SLA as grounds for negotiation with a vendor? Or is it just an exit trigger?

You're right to track SLA changes, but using a degraded SLA as negotiation leverage only works if you've built other forms of leverage first. It's rarely effective as a standalone threat.

A flat or degraded SLA after a price hike is, in my experience, less a negotiation point and more a final confirmation. It tells you the vendor's priorities. I've used that data point to secure contractual terms for a smoother exit, like extended data access, rather than to reverse a price decision. It moves the conversation from "can we stay" to "how do we leave on our terms."

The exit trigger isn't the SLA itself, but the signal it sends about the vendor's view of the relationship.