Should your AI build the feature, or install a service?

First, where I stand

I run a small SaaS that sells one of the options in this decision (more on that at the end, so you can weigh what I say). So I’ve tried to make this a fair framework rather than a pitch, and I tested both routes on the same feature.

Building is cheap. Owning isn’t.

Every feature your AI writes becomes code you own. It works on the day it’s generated. After that it needs someone to notice when it breaks, fix it, keep it secure, and keep it working when the next AI session “improves” a file it doesn’t remember writing.

For a lot of features that’s fine, because there’s very little to look after. For others, most of the work is in things you never see on the screen.

Five questions that decide it

• Is it what your product is about? If the feature is your product, or close to it, build it. That’s where your time should go, and you’ll want full control.
• Do strangers use it? Anything that takes input from anonymous visitors attracts spam, abuse and people gaming it. Handling that well is most of the work, and it’s the part a quick build usually leaves out.
• Does it need to run when you’re not looking? Emails, scheduled jobs, webhooks, payments and uptime are boring until they fail at 2am.
• Would you notice if it broke? A broken settings page gets reported. A broken email notification fails quietly for weeks.
• Does your app have a backend at all? Many sites built with AI tools or site builders are mostly front end. If the feature needs a database and a server, building it means adding both.

If you answered “core”, “no”, “no”, “yes” and “yes”, build it. The more answers go the other way, the more a service earns its keep.

Good things to let your AI build

• Admin and settings screens over data you already have
• Calculators, filters, forms that save to your own database
• Internal tools only your team uses
• Anything that’s your product’s reason to exist

These are mostly plain code over your own data, used by people you already know. AI tools are very good at them.

Good things to install instead

• Login and accounts (security reviews, password resets, account recovery)
• Payments and subscriptions
• Transactional email (deliverability is its own job)
• Anything public-facing where strangers can post or vote

The pattern: the visible part is small, and the invisible part is large and keeps changing.

A worked example: a feature request board

A feature request board fits right in the middle, which makes it a good test. Visitors suggest features, vote on them, and see a public roadmap. It looks like a simple list. The hard parts are less visible: stopping one person from voting fifty times without making everyone sign up, keeping spam off, approving ideas before they’re public, and telling you when something new comes in.

Route 1: ask the AI to build it

I opened a landing page in Lovable and asked: “Add a feature request board where visitors can suggest features and upvote them, plus a public roadmap page.” No mention of any service.

It did a good job. In one go it added a Requests page and a Roadmap page, linked from the top of every page, and set up a database for them (Lovable Cloud). Visitors can suggest an idea and upvote the ones they want without signing in, ideas are sorted by votes, and the roadmap shows Planned, In progress and Shipped columns. It even tested itself: it submitted an idea and checked that an upvote raised one idea from 19 to 20 votes. The whole thing took two prompts and about five minutes, and used roughly three-quarters of my daily Lovable credits.

Its own summary was refreshingly honest about what it hadn’t done:

• No admin screen. To move an idea onto the roadmap, you change its status in the database yourself. I couldn’t find anywhere to review new suggestions either.
• No approval step. New ideas start as “Under review” and appear on the public Requests page straight away.
• Easy to vote twice. “Each browser can upvote an idea once. Someone could still vote again from another browser or after clearing their data.” I tried it: in a private window on the published page, the same idea took a second vote straight away.
• Made-up numbers. It “made up six ideas and their vote counts so the pages aren’t empty”, and left its own “Test idea from check” on the board. Both need deleting before anyone sees the page, or your roadmap opens with invented demand.

I asked it directly whether the one-vote rule was enforced on the server and whether there was any spam protection. Again, a straight answer. Votes are checked in the database (one vote per voter ID per idea, and the count is raised by a trigger, so nobody can type in a made-up total), but the voter ID is just a random code the browser makes up, so clearing your data or sending a different code gets you another vote. On new ideas: “no rate limiting and no spam protection at all. Anyone, signed out, can post as many ideas as they like as fast as they like.” It added that the backend has no built-in rate limiting, so any limit would be a custom rule with trade-offs, and offered to build a sign-in requirement, a wait between posts, or an admin page.

Nothing it described would tell you when a new idea (or a pile of spam) arrives, so you’d find out by going to look.

So route 1 gave me a working board in minutes, and it’s genuinely fine for a small, friendly audience. What’s left is exactly the invisible list from earlier: an admin screen, approval, stronger duplicate-vote protection, spam limits and notifications. Each one is another prompt, more code to own, and more to test.

Route 2: ask the AI to install a service

Then I gave Lovable, v0 and Cursor the same short install prompt for a hosted board. It asks the AI to add a Feedback button to every page and a /roadmap page, and tells it not to build its own storage for feedback.

All three got it right the first time: the button on every page, a working roadmap page, voting and submitting working, no console errors. Lovable and v0 both added a script tag. Cursor did it in a fresh Next.js app. The parts missing from route 1 come with the service instead of being code in your project: an approval queue, a dashboard to move ideas through the roadmap, email notifications, spam limits, and votes checked on the server (one per browser, with per-network limits on top). No login-free board can make double voting impossible, this one included; the aim is to make it slow and pointless.

The trade-off is the usual one for any service: it costs money beyond a free plan, your data lives somewhere else, and you depend on someone else’s uptime. Check that you can export your data and leave.

If you do build it, ask for the invisible parts

If you decide to build, put the hard parts in the prompt instead of hoping for them:

• “Limit how often one visitor can vote or post, and explain how you stop duplicate votes.”
• “Add a honeypot field and rate limits to the public form.”
• “New submissions should wait for my approval before they’re public.”
• “Email me when something new is submitted.”
• “Write tests for the voting rules.”

Then read what it wrote for those parts. That’s where problems hide.

If you install a service, check these

• Can you export everything (CSV or an API) and leave?
• Does the price grow with something you can predict?
• Does it work with your stack and your Content Security Policy?
• Does it give your AI tool clear install instructions (a prompt, or an llms.txt file), so the AI installs it instead of reinventing it?

The short version

Let the AI build what makes your product yours. Install what strangers can abuse, what has to run while you sleep, and what you’d never notice breaking. The building is cheap either way; the owning is what you’re really choosing.

Disclosure: I build UserNote, a hosted feedback board and public roadmap, which is the service I used for route 2. It has a free plan, and the install prompt works the same in Lovable, v0 and Cursor. I’ve tried to keep this useful whichever route you pick.

• The install prompt for Lovable →
• v0 →
• Cursor and Claude Code →