Discover ideas with demand & design them using AI
Hey there! I've been building dxmax, which is a precision edit, non-tokenmaxxing UI/UX agent.
Launched Lodestart Engine yesterday, which pulls together a bunch of demand signals to give you an exhaustive list of SaaS/AI ideas that you can design in a click on the product and then export out to your favorite coding agent to finish & deploy.
Cheggitout here: https://dxmax.cc/find-startup-ideas
Would love some feedback, reach out for free Pro access, got some licenses reserved for you indies.
Trending on Indie Hackers
Industry data helps filter the field. The signal I trust most is simpler: has this pain already cost someone money? If yes, skip the rubric and just talk to them.
💯
The "validate cost structure as part of idea validation" point is underrated. Most founders treat model costs as an ops problem that comes after PMF. By then they've sometimes built a pricing model that doesn't survive the actual usage patterns.
The layering approach — cheap models for classification and extraction, stronger models for reasoning steps — works well when you can make the decision points explicit in your pipeline. The failure mode is when the high-reasoning step expands to cover more of the workflow over time because edge cases get patched with model calls instead of logic.
The credit model is probably the right way to start for exactly the reason you mentioned: it reveals what users actually do, not what you predicted they'd do. Burn rate per user session is the number you want in week 2 of real usage, not week 10.
Totally aligned with this! We aid in demand discovery but that doesn't mean its easy to capture the demand reliably with a high number of returning users. That's art that is going to vary from builder to builder :)
I made something similar to this. What I did was gather industry data on many industries in the world, then I use a rubric to see which industries the ease of making a solo dev product in each industry. I use that data as a factor in judging which of my ideas have a strong potential to build solo using AI.
Curious if you use industry data to judge what ideas have strong/weak potential.
Really glad to hear that you tried something like this. I use a mix of signals including industry data. Would love to hear your thoughts if you give the product a spin given your experience building something like this!
Interesting direction. I like the idea of connecting demand signals directly to product design, especially now that coding agents make the build step much faster for indie builders.
One thing I’d be careful about is that “demand exists” and “this can become a healthy SaaS business” are still different conclusions. For AI SaaS ideas specifically, the validation layer probably needs to include workflow value, willingness to pay, and unit economics from day one.
That last part matters a lot with AI products. If the generated idea depends on heavy model usage, long-context workflows, image/video generation, or agentic automation, the model/API cost structure can change whether the idea is actually viable. I’d love to see tools like this help founders think not only about what to build, but also which parts of the workflow need strong models, which parts can run on lower-cost models, and how that affects pricing before they start building.
Fair enough. But that is more the execution model, which is where the spaces we've identified are not a sure shot way to the projected MRR. For instance, a strat to mitigate the token cost risk is to start with some credits and then use data to switch to an open weights model over time to save token costs?
That’s a fair mitigation path. I’d just be careful not to treat “switch to open weights later” as a universal cost fix.
For AI SaaS ideas, the question is usually: which part of the workflow can tolerate lower reasoning quality, and which part can’t?
Starting with credits makes sense because it buys real usage data. But once usage appears, I’d separate the workflow into layers: low-risk steps like classification, extraction, rewriting, or first-pass design suggestions can often move to cheaper/open-weight models. Higher-context steps — like deciding whether the idea is actually viable, interpreting demand signals, or generating product direction — may still need stronger hosted models or at least much stricter evaluation.
So I’d probably validate three things before calling the idea healthy:
That way the cost strategy becomes part of the idea validation, not something founders discover only after scaling.
That is where the builder's gut feel comes in once they discover, design, build and deploy the product. Intuition is the key differentiator between multiple builders who pick the same idea/problem space to work on.
I agree with that. The builder’s judgment is probably the real differentiator, especially when multiple people discover the same problem space.
I’d think of the product less as replacing gut feel and more as giving that gut feel better inputs.
For AI SaaS ideas, two builders can start with the same demand signal and still make very different decisions depending on what they notice: who has urgency, which workflow creates value fastest, where trust is needed, and whether the usage cost fits the pricing model.
That’s why I think the interesting layer is not just “this idea has demand,” but “what should the builder pay attention to before committing?”
Things like expected workflow depth, model/API cost risk, time-to-value, pricing pressure, and whether the product needs strong reasoning or lightweight automation could all help founders make better judgment calls earlier.
So yes, intuition stays central — but the best demand/design tools probably make the builder’s intuition sharper, not less important.
Great reply. This is true! And the design phase does exactly that. once the idea is discovered and designed in dxmax, the founders prompts help put in place the look & feel and everything else from there onwards, including deeper features, the exact flows etc. The guide.md allows you to carry that across the product as well.
I'd be careful with one thing.
The interesting question may not be whether the ideas show signs of demand.
It may be what conclusion deserves confidence once those signals appear.
Those sound similar, but they can lead to very different decisions about what gets built, validated, and prioritized next.
The danger isn't lack of validation.
It's false validation.
I wouldn't make that call casually from the current signals.
Very fair Aryan, which is why a lot of the product spaces we've identified already have incumbents, the idea is that all these incumbents are going to be pushed by new entrants now that Claude Code etc have made building SaaS so much easier.
Possibly.
The reason I'd still be careful is that I don't think the interesting part is whether incumbents get pressured.
I think it's the decision that gets made once that starts looking true.
That's where founders can end up feeling validated while quietly optimizing around the wrong conclusion.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.
Hmm, demand -> product -> validate unit economics -> scale? Whats missing there?
This is ofc a hard journey, we merely enable it via data-backed demand intelligence and AI-aided design.
Possibly.
The reason I stopped short is that I don't think the interesting part is the sequence itself.
I think there's a more important decision sitting underneath it.
That's the kind of thing that can make two founders follow the same process and end up learning completely different lessons from it.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.
Yep and those diff learnings can create 2 products that look different and take on different growth routes/slightly different product roadmap too, but whether users pain is addressed or not will objectively reflect in the paid conversion funnel. Email is [email protected]
Sent you a note by email.
I think the interpretation layer matters more than the validation layer in this case.