How (not) to vibecode a product

Yes, building apps has never been easier thanks to ~~vibe coding~~ agentic engineering. Frontier coding agents can scaffold apps, write tests, debug weird framework issues, wire APIs together, and produce an amount of working software that would have felt absurdly fast a few years (months?) ago.

But does it make building good products easier?

That is a harder question. To think about that, I will use one of my own projects: CineCause, an app where you can donate to charities when you are inspired by a movie or TV show. The code is public at lukasugar/cinecause.

It’s built around one simple emotional moment: you watch something, it makes you care about a cause, and you want to turn that feeling into action.

When a film hits hard, it can briefly change what you care about. A documentary about climate change, a war movie, a show about addiction, a drama about poverty, a story about refugees, a medical thriller, a film about animal welfare: all of these can create a moment where the viewer is unusually open to doing something real.

Usually that moment disappears - you finish the movie, talk about it for a few minutes, maybe Google the story behind it, maybe read the Wikipedia page, and then life continues. The emotional momentum is real, but there is no obvious next step. Streaming platforms are very good at recommending the next thing to watch, but are not designed to help you act on what you just watched.

CineCause tries to fill that gap. The product lets you browse or search for movies and TV shows, open a title page, and donate to a nonprofit through Every.org. The donation is connected back to the title that inspired it, so the app can show impact around movies, shows, and causes.

The optimistic version of the product is:

You watch a movie or show.
It makes you care about a topic.
CineCause makes the donation path obvious.
The donation becomes part of a visible impact trail.

There is also a second motivation, which is more personal: I wanted to build a complete product with modern coding agents and see where the actual friction is.

So CineCause was both a product idea and an experiment in product building.

How tough was building it?

Building the app was much easier than it would have been before agentic coding, but not effortless.

The easy part was turning clear implementation tasks into code. Once I knew what I wanted, an agent could move fast. It could create pages, refactor components, add tests, connect API calls, clean up styling, and fix many obvious bugs. For a solo developer, this changes the feeling of building software. You spend less time typing and more time deciding what should exist.

That sounds like a small shift, but it is not. It changes the bottleneck.

Before, a lot of product ideas died somewhere between “this would be cool” and “I do not have three weekends to build the boring parts.” Now, the boring parts are cheaper. Authentication, settings pages, database migrations, form states, loading states, API wrappers, deployment config: none of these are free, but they are much less painful when an agent can do a large share of the mechanical work.

For CineCause, the main pieces were:

discovery, search, and title pages
charity selection and donation checkout through Every.org
accounts, privacy settings, and donation history
leaderboards and impact tracking
a public landing page and deployment

Without AI assistance, I would probably have cut scope aggressively or stopped after a prototype (or not have worked on this at all). With agents, it became reasonable to push toward a complete version.

Also, I should be honest here: I do have frontend experience. But somehow it still feels easier for me to train a billion-parameter model than to center a div.

The idea was still the hard part

Coding agents are helpful when the task is specific. They are much weaker when the product question is vague.

“Build a page where users can search for movies” is a feasible task, but “Make people want to donate after watching movies” is a product problem that can’t be one-shotted.

That distinction matters. The agent can implement the screen, but it cannot reliably decide whether the screen should exist. It can suggest flows, but it does not know whether users will trust them. It can make a donation button prominent, but it does not know whether the user is emotionally ready to click it. It can write copy, but it cannot give the product real cultural timing.

This was the main lesson from building CineCause: agentic coding compresses implementation time, but it does not remove product uncertainty. If anything, it exposes it earlier. You can get to the point where you have to answer the difficult questions faster.

Who is this for?

When do they use it?

How do they find it?

What movie or show creates enough motivation to donate?

Do they trust the donation flow?

Do they want the donation to be public?

Would they rather donate directly to a charity?

Skills still matter

There is a tempting story that agentic coding means anyone can build anything. Coding agents help a lot, but you still need to understand what you are asking for.

Engineering taste still mattered: keeping the flow simple, noticing missing states, reviewing sensitive account and donation logic, and just knowing when generated code seemed off.

This is especially true when a product touches real money, accounts, and privacy. Even if the donation processing is handled by Every.org, the surrounding experience still has to be reliable. I was most nervous about that “money processing” part.

Agentic coding made me faster, but it did not let me stop being responsible for the result.

Testing - the best way to gain trust in AI-generated code

The biggest practical improvement was having a solid testing workflow.

I used TDD-style development through obra/superpowers, and I highly recommend this style of working with agents when building product features. Tests give the agent a target and give me a way to know whether we are moving forward.

Without tests, code can become a pile of plausible diffs. The app looks like it is improving, but you are not always sure if something is broken. With tests, the work becomes more controlled. You can ask for a small behavior, watch the test fail, implement the fix, and keep going.

I am less sure how to apply this style properly for model development. Product features usually have crisp behavior: click this, save that, show this state, reject this invalid input. Model work is messier, the feedback loop is slower, success is often statistical, and a “failing test” does not always map cleanly to the next implementation step. For apps, though, TDD with agents felt very natural.

Debugging was different, not gone

I would go through the app manually, and if I noticed any bugs - misplaced UI, slow performance… - I would tell the agent what I did and what the bug felt like to the user.

If the agent proposed a very small, one- or two-line fix, I would usually trust it, but if it proposed rewriting longer chunks of code, I’d make sure to understand the problem better, as a bigger change is a strong indicator that some bad decisions were made in the planning phase. Coding agents have a tendency to just keep adding stuff, and I wanted to at least not amplify that behavior with “quick fixes”.

Results: is anybody using it?

The short answer: no, not really.

CineCause has had some visits, but at the time of writing it has produced 0 donations.

That is the uncomfortable but useful part of the story. The app works, has a real concept, a real donation path, and a reasonably polished interface - but no adoption.

This is the part that agentic coding does not solve.

The hard question moved from “can I build this?” to “why would anyone care, trust it, remember it, and use it at the right moment?”, and I probably should have tackled it first.

CineCause has several possible problems.

Product fit

The most likely issue is product fit.

The emotional idea makes sense to me: stories inspire action. But that does not automatically mean users want a standalone website for it. The moment of inspiration may be real, but it may be too weak, too brief, or too private to turn into a donation flow. I have done no analysis of this.

There is also a timing problem. When exactly should someone use CineCause, and what would the call to action look like?

Right after watching a movie?
While browsing for something meaningful to watch?
After seeing a recommendation on social media?
After reading about a film’s real-world topic?
During a campaign connected to a specific release?

Each of these is a different use case. A generic movie-to-charity app may be too broad. The stronger version might need to be attached to specific campaigns, communities, creators, or events. For example, a film festival, a documentary campaign, a nonprofit partnership, or a post-screening QR code could create a much clearer use case than “remember this website after watching something.”

Trust

Donations, like any “money handling”, require trust.

Even if the app itself is harmless and the payment flow goes through a legitimate provider, a new user still has to understand what is happening. Why should they use CineCause instead of going directly to a nonprofit? What happens after they click donate? Is the charity real? Does CineCause take a cut? Is their donation public? Do they need an account?

Every extra question reduces conversion.

For normal apps, a bit of confusion might mean the user leaves and maybe comes back later. For donations, hesitation is more dangerous because the emotional window is short. If the user has to think too much, the moment is gone.

The app’s UI does give the “vibe-coded” feel, and that might be reducing trust.

Marketing

Another obvious issue is marketing.

I did not seriously market CineCause. I built it, deployed it, and let my LinkedIn and Twitter followers know about it. That is not a launch strategy - at least not with the number of connections/followers I have.

SEO might help over time, especially for pages around specific movies, shows, and causes. A user searching for a movie title is probably looking for cast, reviews, streaming availability, trailers, or plot explanations. “Donate because of this movie” is not yet an established search intent.

Social distribution might be more natural. The product makes more sense when attached to a specific emotional moment:

“If this documentary moved you, here are three organizations you can support.”
“After watching this film, donate to groups working on the issue.”
“This week’s most impactful movies and the causes connected to them.”

That sounds less like a generic app and more like editorial work. Which again points to the same lesson: the product may need taste, curation, and a point of view more than it needs more features.

What is missing?

If I continued working on CineCause, I would not start by adding (m)any more technical features, but by working on distribution.

I would spend time on marketing, getting some feedback, analyzing user behavior, and finding partnerships with streaming platforms or, more realistically, some small festivals.

Is this AI slop?

We are going to see many more apps like this: specific, niche, fully deployed, mostly unused. Some people will call all of them slop, but I do not think low usage is enough to earn that label. A tool can be valuable to a tiny audience, useful for one person, or thoughtful and still fail to find distribution.

To me, slop is software that exists without care: generated, published, and abandoned without responsibility or without a serious attempt to solve a real problem. By that definition, I do not think CineCause is slop. It is a real attempt at a coherent product, with a specific idea, a working donation flow, and enough polish that somebody was clearly there. But being “not slop” is not the same as having demand.

Nice idea, no demand

This is the part I find most interesting. I started with the feeling that I had a great idea. After building it, the more honest version is probably: I had a nice idea that I wish existed, but not demand that I had proven.

Agentic coding made the idea real much faster, which is great. Everybody is using these tools for a reason, from solo developers to large organizations. But that speed also exposes the next problem faster: once the app exists, you still have to find out whether people actually want it, whether they trust it, and whether it fits into a real moment in their life.

Conclusion

CineCause is probably the kind of app we will see much more often: a complete product for a very specific use case, built by one person with the help of coding agents.

That is exciting, as it means more ideas can become real. The cost of experimentation is lower and even weird, niche, personal software has a better chance of existing. But it also means the internet will contain many more products that are technically real and socially invisible.

My takeaway from CineCause is that agentic coding changes the build phase much more than the product phase. It made it dramatically easier to create the app. It helped me move faster, test more, debug better, and ship something complete. But it did not solve the central product question:

Why should this become part of someone’s life?

For CineCause, I still like the idea. Movies and shows do inspire people and some of that inspiration could become real-world impact. But the current version probably needs sharper positioning, stronger trust, and better distribution before it can become more than a polished experiment.

The good thing is that LLMs can surely help with that part as well - analyzing sentiment, researching pain points, drafting campaigns… But that’s a topic for another post, if/when I dig deeper into it.

So, can you vibecode a product? Yes.

Can you vibecode product-market fit? Not yet.

If you’ve come this far through my blog, you might as well sign up for CineCause. Or tell your Netflix CEO friend to send me an offer.

Thanks!