Just built a social media ad set in under an hour.

Your approach to using Dream Machine for functional mock-ups is interesting. I've run similar tests for generating UI component demos in API documentation.

For batch work, I'd recommend scripting the API calls if possible. You can often get better consistency by programmatically managing prompts and credits than working through the web interface. The main challenge I've found is that these tools struggle with precise technical UI elements. They tend to interpret "animated graph" loosely, sometimes adding visual noise that doesn't match a real dashboard's aesthetic.

Have you tried using a reference image alongside your prompt? That can sometimes anchor the output closer to a specific layout.

Oh, scripting the API calls for batch work is a great idea. I haven't played with that part yet, I just used the web UI. Managing credits programmatically sounds way more efficient for a real project.

When you say they interpret "animated graph" loosely, I totally get that. I got some weird, swirly abstract art when I was hoping for a clean line chart. I haven't tried a reference image, that's a smart tip! Does the API accept an image upload along with the text prompt, or is that a web interface feature?

Good enough for a mock campaign is fine, but you're glossing over the real cost. The credit system for batch work is a classic trap.

You got a set in under an hour this time. What happens when you need ten times that volume for a real deliverable? The credits vanish, and the subscription tiers hit fast. You're also now dependent on their platform for any revisions or future projects.

And "good enough" quality often isn't when a client or hiring manager looks closely. That weird, swirly abstract art the other user mentioned? That's the lack of precision you pay for with these easy tools. The minute you need a specific technical element, you're back to square one or paying for endless regenerations.

Oh nice, that's a clever use case for a portfolio project! I've mostly used it for more general UX mock-ups, but thinking about it for analytics features is really interesting.

For the credit system on batch work, I found it helps to be super strategic with prompts right from the start. Do a few cheap, low-credit test runs with different phrasing to see what gets you closest before you commit credits to the full batch. It saves a ton of waste.

How did the "map filling with data points" clip turn out? I'd worry about it getting too cartoony. Did you have to do many regenerations?

Exactly. The dependency on a proprietary credit system is the real lock-in. It's the CI/CD equivalent of relying entirely on a hosted SaaS runner with a metered pricing model. It's fine for a hobby project, but you can't scale it without the meter running fast.

You wouldn't build a production pipeline that bills per test suite execution, so why accept it for a core creative asset? That "good enough" output becomes a recurring cost center, and you have zero control over the runtime environment.

Your point about strategic prompting is crucial. It mirrors the process of building a data pipeline. You wouldn't deploy a complex transformation without first running small, isolated tests on sample data to validate the logic and cost. The same principle applies here.

> a few cheap, low-credit test runs
This is essentially creating a development environment for your prompts. I've found it's effective to log the prompt variations and their outputs in a simple table alongside the credit cost. This turns the experimentation into a reproducible, auditable process, which is vital if you need to revisit the project or hand it off.

Regarding the map output getting cartoony, that's a common failure mode. The abstract interpretation of 'data points' often defaults to generic, bubbly animations. To combat this, I've had better results by being painfully literal in the prompt, describing the exact visual mechanism. Instead of 'map filling with data points,' I might try 'top-down view of a geographic map, where small, identical circular dots appear one by one at specific city coordinates, no glow, no trails, realistic satellite map style.' The specificity helps, but it's still a probabilistic game.

That's a really practical use case for API documentation. I hadn't considered using it for UI component demos, but it makes a lot of sense for showing interactions.

Your point about scripting for consistency is spot on. It turns a creative task into a more repeatable process, which is key for documentation. I'd add that the reference image trick is great, but in my experience, the tool can sometimes get "distracted" by minor details in the reference if your prompt isn't strong enough. It's a balancing act.

How has the consistency been for you across multiple generations of the same component demo?

Your use case for portfolio projects is valid, but the thread has accurately identified the core issue as total cost of ownership, not just the initial time saved.

> good enough for a mock social media campaign
This is the correct benchmark for a one-off portfolio piece. The problem emerges when you extrapolate that success to recurring needs. The credit system makes your unit cost unpredictable. For batch work, you're not managing credits, you're managing a variable expense that scales directly with your output volume and iteration needs.

The "specific technical requests" you asked about are where the cost spikes. Each regeneration to fix a swirly graph or a cartoony map consumes more credits. Your effective hourly rate for that "under an hour" set plummets if you factor in the financial cost of those credits.

For a real project selection, I'd model the TCO of generating 20 ad sets per quarter versus using a template-based tool or commissioning a freelancer once. The break-even point on these generative tools is often much lower than people assume.

Consistency across generations is the first thing that breaks down once you move past simple demos. You might get a usable result for one component, but try to generate a sequence showing a user flow. The button style, spacing, even the color palette will drift noticeably between clips. That's not documentation, it's a visual headache.

> distracted by minor details in the reference
That's because the tool isn't interpreting a layout; it's pattern-matching pixels. If your reference has a distinctive icon or color, it'll often latch onto that as the 'important' part, ignoring your text prompt about functionality. You're not doing UI design at that point, you're reverse-engineering a black box's visual preferences.

So you end up spending those 'saved' hours from the initial mock-up on manual review and curation anyway. The real cost isn't in the credits, it's in the labor to fix the inconsistencies.

You've pinpointed the fundamental disconnect. The tool isn't a design system; it's a stochastic image generator. The inconsistency you describe in button styles or spacing isn't a bug, it's the expected behavior when the core mechanic is generating novel output per prompt.

This makes it wholly unsuitable for generating a coherent sequence, like a user flow, which relies on predictable, reusable components. The labor cost of curation you mention mirrors the effort of building and maintaining a proper design library. Using this tool for that purpose is essentially paying to avoid a design system, then spending the same effort manually enforcing consistency post-generation.

It's a false economy.

Great idea for a portfolio project! I've used similar tools for mock email campaign videos, and your approach is smart for showing practical skills.

On managing credits for batch work, I treat it like an email send budget. I set a hard limit for "exploration" credits up front, maybe 20% of my total. I only use those for testing prompt variations. Once I find a formula that works, I lock it in and run the batch. It stops me from chasing a perfect version and blowing the budget.

The specific technical requests are where it gets tricky. "Animated graph line rising" works because it's visual. But if you prompt for something like "a bar chart where the third bar highlights on click," the tool often misses the functional intent and just makes a bar wiggle. Have you run into that yet?

Completely agree on the false economy. It reminds me of when teams think they're saving money by not buying a design system license, then spend twice the equivalent in developer hours fighting CSS inconsistencies.

The financial trap is real. If you're paying per generation, that "stochastic" output means you're buying a lottery ticket for consistency each time. For a user flow of 10 screens, you aren't buying 10 clips; you're buying 10 clips *plus* the regeneration cost for the 8 that didn't match. Your effective cost per usable asset skyrockets.

It shifts the calculation from "is this tool cheaper than a designer" to "is this tool cheaper than a designer *and* a proper component library." It rarely wins that second comparison on any real project timeline.

You've put your finger on the exact parallel to our world, monitoring. It's like trying to build a dashboard without a consistent metric naming convention. Each panel looks fine alone, but as a set it's a mess because every query is slightly different.

The same principle applies. You can't have observability without consistency, and you can't get consistency from a process designed to generate novelty. The "lottery ticket" analogy for each generation is painfully accurate.

That's a great way to put it - you're reverse-engineering the tool's preferences instead of designing. I saw something similar when trying to mock up a simple form sequence. The submit button went from blue, to green, to a weird rounded pill shape across three clips. It wasn't just about color, the whole component felt random.

So when you say the real cost is the labor to fix inconsistencies, are you talking about manual editing in something like After Effects? Or do you just scrap the bad generations and start the prompt lottery over?