Going Freelance as a Vibe Coder: What Clients Actually Buy

You can now build in a weekend something that would have taken you six weeks in 2022, and the obvious conclusion is that you should go independent and sell that. The conclusion is right. The reasoning is wrong, and if you carry the wrong reasoning into your first client conversation you will end up competing on the one axis where you cannot win.

Nobody buys code. They never did, but it was easy to believe otherwise when producing code was hard and slow, because the difficulty was visible and it looked like the product. Now that a competent developer with an agent can produce a working CRUD application with authentication, a dashboard and a deployment pipeline in two days, the illusion has gone. What is left is what was always actually being purchased.

The four things on the invoice

Strip a client engagement down and you find the same components underneath, in different proportions.

A decision, made. Most clients do not have a specification. They have a frustration, a spreadsheet that has outgrown itself, and a vague sense that software should fix it. The work of turning that into "we are building these seven screens and explicitly not building the other four" is the work. It is also the part the agent cannot do for you, because it requires sitting in a room with someone and noticing that the thing they keep circling back to is not the thing they asked for.

A risk, absorbed. When a company hires you, a named person there has staked some of their credibility on you. What they are buying is the ability to say "it is handled" in a meeting. Every reassurance you provide — a demo on the promised date, a status note before they have to ask for one, a bug fixed before they noticed it — is the actual product.

Accountability that survives the handover. An agent has no phone number. When the thing breaks at 4pm on a Friday in March, the client needs a human who will answer, and who cannot say "I only pasted it in". You are on the hook, permanently and personally, for code you did not type character by character. Price and behave accordingly.

A problem removed from a list. Not solved elegantly. Removed. Clients are far less interested in your architecture than you would like them to be.

Three kinds of client, three different purchases

The small business owner or non-technical founder is buying translation and certainty. They cannot evaluate your code, so they evaluate everything else: whether you turned up on time, whether you explained a trade-off in language they understood, whether the thing you showed them last Thursday still works today. With this client your speed is invisible unless you convert it into a date, and your technical decisions are invisible unless they fail. Half of the engagement is deciding on their behalf and then being able to justify it.

The agency or established dev shop subcontracting to you is buying throughput with low management overhead. They can evaluate your code, and they will. What they want is to hand you a ticket, hear nothing for three days, and receive a pull request that does not need a conversation. This is the fastest route to your first steady income as an independent, it pays less per day than direct client work, and it is worth taking anyway for the first six months because the feedback is real and the sales cost is zero.

The company with an existing codebase is buying risk containment. They have heard about agents. They are nervous, and their nervousness is well founded, because they know what happens when someone confident and fast is let loose in a system with fourteen years of undocumented behaviour in it. What they are paying for is your judgement about where an agent can safely go and where it cannot, and your willingness to say "I would not automate that part". Being the person who declines to move fast is a genuine market position now.

Positioning: the trap that catches nearly everyone

The instinctive pitch is "I build software fast with AI". Do not use it. It has three problems. It invites a price comparison with the next person who says the same sentence more cheaply. It makes the tool the hero and you the operator of the tool, which is a weak position to negotiate from. And it is a claim about your process, which no client cares about, rather than a claim about their outcome.

Position on a domain or on a problem shape instead. "I build internal tools for logistics companies" is defensible, because the second engagement is genuinely better than the first in ways a competitor cannot shortcut. "I take a spreadsheet that six people are fighting over and turn it into an application in a month" is defensible, because you are describing the client's situation back to them. Your speed is your margin. It is not their benefit, and you should not hand it over for free.

Where the first three clients actually come from

Not from cold email. Not from the freelancing marketplaces, where you will be bidding against a global floor for exactly the commodity work that agents have made abundant. Your first clients come from three places: people who already know you can do the job, the unglamorous niche where you have some incidental knowledge, and subcontracting from an agency that is currently turning work away.

The unglamorous niche deserves emphasis. Nobody with an agent and a portfolio site wants to build a compliance-reporting tool for waste haulage. The people who need one have money and very few options. The work is not exciting and it renews.

The awkward question

At some point a client asks whether you use AI. Answer plainly, without a speech. It is a question about tooling, and it deserves the same register as a question about which framework you use. Something like: yes, I use AI coding tools for a large part of the implementation, I review and test everything that ships, and I am responsible for all of it.

Do not lead with it as a selling point. Do not hide it. Both readings — the evangelist and the person who goes quiet — are worse than the matter-of-fact one.

Two hard rules. First, read the contract. Some corporate master service agreements now contain clauses prohibiting AI-assisted development or requiring disclosure, sometimes buried in an IP or confidentiality section, and some prohibit sending client code to third-party services at all. Signing one and then breaching it is not a grey area, it is grounds for non-payment and worse. If you cannot comply, negotiate the clause before signing or walk away. Second, never let anything resembling "the agent wrote that part" leave your mouth when something breaks. You authored it. That is not a technicality, it is the entire basis on which you are being paid.

What actually gets you rehired

Not the code quality, which they cannot assess. Not the speed, which they will normalise to within one project. It is the absence of surprises: a note every Friday whether or not there is news, a flag raised the moment a date is at risk rather than the day it slips, and the boring things done properly — backups that have been restored at least once, errors that reach you before they reach the client, an invoice that arrives when you said it would.

The strange consequence of all this is that going independent as a vibe coder rewards the least technical parts of the job more than it ever did. The agent compressed the part you are good at and left the rest at full size. Whatever fraction of your week used to be conversations, estimates and follow-up, expect it to roughly double as a share of your time, and treat that as the job rather than the overhead.