Samuel Jefroykin6 min read
How to turn a vibe coded tool into a paid service
If you built a tool with Lovable, Base44 or a similar builder that does one job well (converts a file, drafts a document, scores a list, builds a schedule), the fastest way to get paid for it is usually not to sell the tool. It is to sell the job the tool does, delivered by you, to one kind of customer, at a price per job. This is a productized service: a fixed outcome, a fixed price, delivered with your tool in the background. It skips the parts that make software slow to sell to strangers (trust, onboarding, support at scale) and keeps the part that makes it a business: someone paying for a result. It is also not easy: you become the delivery, and finding the first customers takes the same weeks it always does. This post is about which tools fit this route, how to package one, and what it costs you.
Which vibe coded tools fit a service, and which do not?
The ones that produce a finished thing for someone else. A generator, a converter, an analyzer, a checker, a planner: anything where the user puts something in and gets a usable output. If you can imagine a customer emailing you their input and getting the output back the next day, the tool fits a service.
The ones that do not fit are the ones where the value is in the user's own repeated use. A habit tracker, a social app, a game, a community. There is no job to deliver on someone's behalf; the product is the use. Those are software businesses or nothing, and how to turn a side project into a real business is the better guide for them.
A quick test: write the sentence "I will do X for you by Friday for Y." If X is a thing the customer wants done and does not care how, the service route is open. If X is "let you use my app", it is not.
Why sell the job instead of the software?
Because a stranger paying for software is making three bets: that it works, that they will figure it out, and that you will still be there next month. A stranger paying for a delivered result is making one bet: that you will deliver.
It also fixes the problem most side builders tell us about. One builder we interviewed put it this way: "I'm a builder and not much of a salesman." Selling software means selling a thing people have to understand. Selling a job means asking one question: do you want this done? Most people who are not salespeople can ask that.
The other reason is price. A tool priced as software competes with free; as one builder we interviewed said of their users, "they know what is free and what is not". A delivered result is compared to the cost of doing it themselves or hiring someone, a different and usually larger number, and the one how to price a side project says to anchor on.
How do you package the tool as a service?
Four decisions, written down before you talk to anyone.
The customer: one kind of person or business, named so narrowly it feels like you are leaving money on the table. Not "small businesses" but "independent estate agents who write listings". One builder we interviewed was told, after a broad launch, to "try not to be everything to everyone". A service for everyone is a service nobody can refer.
The outcome: what they receive, in their words, and when. "Your 20 listings rewritten and returned within two working days." Not a feature list.
The price: per job, or per month for a fixed number of jobs. One number, said out loud. A builder we interviewed reasoned their way toward a different model, "maybe something that is performance-based ... the price comes with results"; that can work later, but a first service needs a fixed price so that the first yes is clean.
The delivery: how the input reaches you, how the output goes back, and where your tool sits in between. The customer never needs to see the tool.
A fifth decision is whether the tool is the product or the bonus. One builder we interviewed attached their tool to an existing course, offering it "as a bonus for buying the course". If you already sell something, or know someone who does, bundling the tool into an existing offer can be the first paid use it gets.
What does the admin look like?
Smaller than a software business, because a service is the oldest business shape there is. Somewhere for the money to land, which in most countries means a simple sole-operator registration, cheap or free. An invoice. Terms that say what is delivered, by when, and what happens if the input is unusable. If the tool handles customer data, a sentence about where it goes and when you delete it. Do you need money to start a business has the real small numbers for this stage, and the gap between an app and a business is mapped in you vibe coded an app, here is what is still missing; the service route shortens that gap, it does not remove it.
What does it cost you?
Your hours, per job, every time. This is the honest trade. Software scales and does not sell; a service sells and does not scale, because you are in the loop. At some number of customers the hours you have are full. That is fine for a first business, and it is also the signal to watch: when the same request arrives from the fifth customer, you have found the piece of the tool worth selling as software, with proof that people pay for the result. Until then, the service is the research.
It also puts you on the hook. A delivered job has a deadline and a quality bar. If your week cannot hold that, say so in the offer: three jobs a week, two-day turnaround, no rush orders. We wrote about running support around a day job; a service is support with a deadline, and the same rules hold.
Where do the first customers come from?
The same place they always do, and it is the slow part. One builder we interviewed said: "I think the most unknown thing is how to get users. It's really the biggest of everything." The service route changes what you ask, not whom you have to find. List twenty named people or businesses who have the job to do. Write to each one with the outcome and the price, and offer to do the first job at full price with a refund if it is not usable. Expect most to say nothing. Expect weeks. Where a side project's first users come from is the detailed version, and it applies unchanged.
What should you do this week?
Pick the customer, write the outcome sentence, set the price, register what your country asks of a sole operator, and send the sentence to five people by name. If a job comes in, deliver it by hand, with your tool, and write down how long it took. None of that is building. All of it is the business.
The setup is days. Finding the five people who say yes, and the twentieth, is weeks to months, and no tool shortens that part, ours included. What the service route does is let you get paid for the tool you already built without first turning it into a product strangers trust. The four jobs in how to start a business with no experience still apply; this route just spends the hours where they count.
The tool exists. Describe the job it does in one sentence and baget's agents build the service around it: the offer, the price page, the admin and the first customer outreach. It costs nothing to look.