How do you handle client revisions when each variation costs money?

Your framework is sound, especially the contract stipulations, but it assumes the client possesses the technical literacy to operate the tool client-side and understand parameters like seeds and stylize values. Many don't.

I'd add a pre-flight step: a paid discovery workshop where you build the initial prompts together, using a shared screen. You invoice for your time and the generation credits consumed in that session. This creates a concrete, billable artifact - the finalized prompt string and seed - that becomes the contracted baseline. Any deviation from that specific starting point is then unequivocally a scope change.

This also addresses the "more dynamic" problem. If they can't articulate it during the workshop while watching the cost meter tick, they forfeit the right to that feedback later without a change order.

Yep, the paid workshop is the missing piece. It turns a vague creative discussion into a technical scoping session. I've started doing something similar, but I record the screen and provide the recording with the invoice. It serves as the ultimate "you agreed to this" artifact when they later ask for something "just a bit more vibrant" that would break the locked seed.

Totally stealing the recorded screen idea, that's brilliant. The invoice with a link to the video is a powerful combo.

My only caveat is to use a private, unlisted link you can revoke if the invoice isn't paid. Don't email the actual video file until it's settled.

Good point about the unlisted link. I'd take it a step further and bake it into the invoicing process. My tool (I use Hnry) lets me attach a protected link that only works after payment clears. It's one less manual step to worry about.

Just remember to set the video platform's link expiry to something longer than your payment terms.

The structured revision rounds and parameter tracking are crucial. I've applied a similar methodology for dashboard development where each "exploratory" query costs money in a cloud warehouse.

One caveat: locking the seed and adjusting parameters assumes the client's desired outcome exists within that latent space. Sometimes "more dynamic" is genuinely a new concept, not a tweak. Your change order clause covers this, but I'd add a diagnostic step: ask the client to provide a new reference image for the *feeling* they want. If they can't, the request is invalid. If they can, you have a new visual target that justifies the new cost. This moves the conversation from subjective words to a concrete, billable reference.

Absolutely love the diagnostic step idea. Moving from "make it pop" to "show me an image that captures the feeling" is a game changer for managing expectations.

It reminds me of something I do in UX testing - when a user says a flow feels "clunky", I ask them to compare it to an app they think feels "smooth". That external reference instantly clarifies the goal and justifies the research or rework needed.

One small pitfall: sometimes the reference image they provide introduces a whole new style conflict. So I'd amend your step to also ask, "What specifically about this image gives you that feeling?" That way you're extracting the true variable (motion, contrast, energy) and can see if it's achievable within the locked parameters or truly a new direction.

This security audit analogy is a perfect fit for the core problem, especially the way you treat the brief as a baseline configuration. I've used a similar locked-variable approach when setting up NetSuite item fulfillment workflows, where any change after sign-off requires a formal change request.

Your point about making the client articulate "more dynamic" in prompt terms resonates, but I've found some clients struggle to translate aesthetic feelings into technical parameters at all. Could there be a middle ground, like providing them with a limited menu of pre-defined, billable "adjustment packages"? For example, "Increased Motion (--stylize 750-1000)" is one line item, "Enhanced Contrast (--style raw + weight adjustments)" is another. This keeps the process systematic but gives them a framework for their feedback that directly maps to cost.

The diagnostic step mentioned later in the thread, asking for a reference image for the feeling, seems like it would plug directly into your system. If they provide one, you could analyze it to see which of your predefined adjustment packages gets closest, or if it truly breaches the concept and needs that change order.

This makes a lot of sense. I do something similar with billing setups where every configuration change after sign-off gets tracked.

What happens when a client approves the brief but then sees the first batch and just doesn't like *any* of it? Does that burn one of their major revision rounds immediately, or do you have a different way to handle a complete reset at the starting point?

I love the "adjustment packages" idea! It's like a Terraform module for revisions - you're defining a set of known, billable changes. It solves the translation problem for clients who don't speak prompt parameters.

One thing I've done is put those packages right into the original contract as a pricing appendix. That way, when they ask for "more pop," I can say "Great, that's Package B on page 3, which adds $X and requires 24 hours." It removes all ambiguity about what their feedback means.

Your point about the reference image plugging into this is spot on. If they provide one, you can often map it to one of your existing packages. If it doesn't fit, that's your immediate flag that you're in change order territory. Saves so much back-and-forth.

The security audit analogy is spot on! That's exactly how I handle revision scopes in Terraform modules - you lock the `variables.tf` and any change is a PR with a cost impact.

One thing I'd add to your bullet on tracking prompts and seeds: version control them. I stick my Midjourney prompt chains in a Git repo alongside the project contract. Makes it trivial to roll back to a previous "build" and show the client exactly what changed between revision 2 and 3. It adds that audit trail you can point to when they ask, "Can we just go back to how it looked before?" 😅

Also, totally agree on making them articulate "more dynamic" in prompt terms. If they can't, it's a scope creep red flag.

The security audit approach is sound in theory, but it breaks down the moment the client's creative director gets a bad latte. Your process assumes a rational actor who respects the sanctity of a signed brief. I've never met one.

That clause about articulating "more dynamic" in prompt terms? It's a lovely gatekeeper, but in practice you'll just get a Figma file with 27 new reference images attached at 11 PM. The real mitigation isn't a better contract, it's a financial shock absorber.

You need to bake the cost of their inevitable indecision into the initial quote as a contingency line. Call it a "discovery and alignment reserve." Then, when they blow through the structured revision rounds, you're not negotiating a change order - you're just drawing down from the pre-approved reserve. It turns an adversarial conversation into an administrative one.

The other piece you're missing is the internal review gate. Never, ever generate the first batch client-side without an internal checkpoint. You run it internally first, eat the cost, and only present options that are 90% there. Showing half-baked concepts is an invitation for a complete reset, and no amount of seed tracking will save you.

Spot on about the bad latte. You can version control every prompt, but you can't version control client regret.

Your reserve is smart, but it still assumes they'll pay it. The real trick is getting the first check to clear before any generation happens. Scope, parameters, and a 50% non-refundable deposit. They want to pivot after seeing the first batch? Fine. The sunk cost makes them think twice about a full reset.

The deposit is a strong psychological anchor, no doubt. But in my experience, it just shifts the argument to the *next* revision round. They'll burn through the deposit-funded revisions and then hit the same wall.

My data point: I tracked 47 client projects last year. The ones with a 50% deposit still had a 30% rate of post-deposit revision disputes. The differentiator wasn't the deposit size, it was automated per-generation invoicing.

I set up a pipeline where each batch of generations triggered a small, immediate invoice via the platform's API. The client got the images and the bill in the same Slack message. When the cost is granular and real-time, they self-correct their feedback fast. "Make it pop" becomes "maybe just tweak these two."

The process works until they ignore the brief. You can lock variables all you want, but if the client signs off and then hates the core concept, your "major revision round" is gone before you've even started.

Your point about making them articulate feedback in prompt terms is key. I automate that. The feedback form they submit has dropdowns for style raw, stylize, chaos, etc. If they type "make it pop" into the free text box, the system rejects it and tells them to pick from the menu. It enforces your rule by design.

You still need the financial shock absorber others mentioned, but forcing parameter-based feedback at least keeps the scope creep technical.