Comment by Ascendra Ventures on "Should your AI build the feature, or install a service?"

"Building is cheap. Owning isn't" is the right way to frame this now. The question used to be whether you had time to build something, and now it is who looks after it once the AI has written it.

Question four is the one I would underline. A broken settings page gets reported the same day, while a broken notification email can fail quietly for weeks. Anything that runs when nobody is looking needs monitoring, and that cost is invisible on the day the feature is generated.

The feature request board is a fair test because the visible part is a list and the hard parts are vote limits, spam and moderation. That pattern of a small visible surface over a large invisible one shows up in auth, payments and email too.

I also appreciated you saying up front that you sell one of the options. At Ascendra Ventures we use a similar test when a client asks for a custom build, and sometimes the honest answer is to install a service and spend the budget elsewhere. Did the Lovable build handle duplicate votes at all without being asked?

Thanks, and yes, partly. Without being asked, it limited each browser to one vote per idea, and it enforced that in the database rather than just in the page: one vote per voter ID per idea, with the count raised by a trigger so nobody can post a made-up total. The weak point was the voter ID itself, a random code the browser makes up. In a private window on the published page, the same idea took a second vote straight away. So it stopped accidental double clicks, but not anyone who wanted to stuff the count. It was upfront about that in its own summary, which I appreciated.

Your point about the quiet failures is the one I'd add to the article if I rewrote it. The Lovable build had no notifications at all, so a pile of spam would sit there until you happened to look. Email that silently stops arriving is worse, because you think you'd hear about it.

Search Hashnode