I built an AI app builder because I was frustrated with how hard it still is to turn an idea into a real working product. No code tools feel limiting very fast and full code feels too slow when you just want to test something.

The product works. People describe what they want to build and they get an actual usable app, not a mockup. They can iterate on it and make changes without starting over.

People are signing up on their own. They build things. Some even message me saying it’s useful or cool.

Then they leave.

No one upgrades. No one pays.

From the outside it looks like things are going fine. There is usage. There is interest. But it feels like I built something people enjoy trying, not something they feel a strong enough need to pay for.

I’m trying to understand where I went wrong. Is the problem not painful enough? Is the audience wrong? Do builders just avoid paying for tools like this? Or does the value only show up at a scale most users never reach?

I think your final questions can't really be answered by people here. They take actual market research.

As a very strong rule of thumb, though, the reason why people may use a thing when it's free but not be willing to pay for it is because of the cost/benefit ratio. The product doesn't produce enough value to pay the price being asked.

The tricky part is figuring out what the cost is. It's not just money, it's the accumulation of all user costs, including ancillary ones such as, for instance, how much hassle the product brings with it.

It's also tricky to figure out what the benefit is. It's not at all rare that the manufacturer of a product doesn't actually know what the product's benefit is, and only knows what the intended benefit is.

You need to talk to actual people in your target market and gather more data to illuminate these things.

Hi HN,

I’m the solo founder of Zolly, a tool that lets you generate a full app from a prompt and then visually edit it (no templates, no boilerplate).

I launched recently and got ~75 signups in the first week. People use it, generate apps, and explore the editor — but no one converts to paid.

I’m trying to understand where the gap usually is:

Is the value not clear enough?

Is “AI app builders” already a saturated / mistrusted space?

Do developers prefer DIY even if tools save time?

Or is this just expected at this early stage?

If you’ve built or used similar tools, I’d really appreciate your honest perspective on:

what would make you pay, or

what would immediately turn you off.

Not here to pitch — genuinely trying to learn before deciding whether to pivot, persist, or shut it down.

Thanks for reading.

True. Thanks for the feedback.

Honestly I planned it to keep Starter but it was only for a week. So thought for better understanding to change it to weekly.

But the feedback noted it would be better I guess to change it to Starter from Weekly

Yup, I am getting this complaint a lot. Pushing an update by this week with credit usage details. Which model eats how much credit to generate a specific project.

Thanks for the feedback

That's a great point. I will be updating the credit page with details like how many credit gives you which project.

Why it is better to use Zolly is simple. We provide you with Visual Editor. Where you can drag n drop images, click to edit text, click to add link.

On other AI builders you need to give prompt to even change a basic text which will eventually eat up your credits but with Zolly AI builds your website and You design it.

I’m a solo founder building an AI app builder that lets people generate web apps and websites from a prompt, then visually edit the output.

People are signing up. They’re building things. Usage looks healthy.

But almost no one converts to paid.

I’m trying to understand what’s actually stopping people from paying in cases like this.

Is it trust in AI-generated code? Fear of using it in production? Too much value in the free tier? Or the tool feeling useful but not yet “mission critical”?

For those who’ve built or paid for similar tools: What finally pushed you to upgrade — or what kept you from doing it?

Why don’t you ask them? Customer feedback is the only indicator, we would only be guessing.

Totally agree. I’ve talked to a handful, but responses tend to be vague “just testing”, “not ready yet”.

I posted here to learn how others ran those conversations and what signs helped them tell casual interest apart from real intent to buy.

Have you checked where do your paid tier offerings stack up to free tier offerings of your competitors?

Honestly, I have been through some of my competitors pricing. I noticed free tier are really good these days. I'm just curious to know what finally made others to upgrade from free tier to paid tier.

Ask your customers

Honestly, I did

And few of my early users replied.

They were like " We got almost everything for free from building application to edit and then download or publish everything for free" Why would we upgrade to a paid plan.

I like the focus on real world factors rather than specs. One question: how do you plan to handle subjectivity and sample size early on? For example, durability or comfort can vary a lot by use case—will there be weighting or reviewer context?

The “knife fight” framing resonates. It feels like once a market shows leverage, Big Tech optimizes for control rather than coexistence, even if it reduces overall innovation. Curious whether you think regulation actually changes that incentive structure, or just shifts where the knife fight happens.

This is a nice take on a very real workflow pain. I like the idea of fixing the viewport once and keeping capture + edit in the same context.

Curious how you handle edge cases like sticky headers, lazy-loaded content, or pages with dynamic resizing—do those affect capture accuracy?

Thanks! Good questions on the edge cases.

For full-page captures, I'm using Chrome's native DevTools screenshot API (the same one you get with Cmd+Shift+P → "Capture full size screenshot"). So the behavior for sticky headers, lazy-loaded content, and dynamic pages essentially matches what DevTools does—both the benefits and limitations.

Sticky headers: Captured in their fixed position throughout the scroll, as DevTools does.

Lazy-loaded content: Depends on how Chrome's capture handles it. Generally works well for standard lazy loading, but infinite scroll or heavily JS-dependent dynamic content can be hit-or-miss. That's a Chrome limitation rather than something I can work around in the extension.

Dynamic resizing: The viewport setting works well here since it's part of the DevTools protocol. Pages render at the specified dimensions during capture.

For visible area captures (not full-page), I have more control and it's straightforward—basically a direct screenshot of what's rendered in the viewport.

I've confirmed the bug in the full page capture feature and will fix it in the next version. Due to the Chrome Web Store review process, it will take approximately 3 days. Thank you for your feedback.

Nice resource. Is this aimed more at beginners getting started with Claude, or does it cover advanced patterns like tool use and prompt chaining as well?