DEV Community: Mark Fulton

Get Your First 10 Customers for an AI Product: A Blunt Checklist

Mark Fulton — Wed, 14 Oct 2026 13:39:30 +0000

You built the thing. Nobody has seen it. That is the real problem with most AI products.

I used to be a domain reseller and blogger, so I know the feeling of hitting publish and hearing nothing. The product was fine. Nobody knew it existed.

Here is how to get your first 10 customers without an ad budget.

Free stuff to grab first

The open source AI Employees. Eight roles, all MIT licensed, free to hire on every plan including Free. A Social Media Employee, a Sales Employee, an SEO/AEO Employee and five more. Handy for drafting launch posts and outreach. Grab the AI Employees
Product Hunt. The launch guide says it is "100% free to use." You submit from your personal account, since company accounts are not allowed. Product Hunt launch guide
Show HN. Free, and it has rules. Your thing has to be something people can try. Landing pages and sign-up pages do not qualify. Show HN rules
BetaList. A directory for early-stage startups. The page shows a "Submit startup" button but does not state a price, so check before you commit. BetaList

I only link what I opened today.

Customers 1 to 3: people you already know

Skip the launch. Message people who have the problem.

Pick 20 people who would plausibly use it
Send a short note. What it does, one link, one question
Offer to set it up for them. Do the first run yourself

Three yeses is a win. You are not scaling. You are learning what they say back.

Customers 4 to 7: communities, by the rules

Post where builders hang out. Follow the rules or get removed.

Product Hunt says: don't ask people to upvote. Ask them to visit and comment. Show HN says the same, and it excludes "requests for friends to upvote or comment."

If your plan needs a vote ring, your plan is the problem.

Product Hunt also says to launch when you are ready, not on a magic day. Believe it.

Customers 8 to 10: let other founders push you

This is where I built something.

Favors.dev is a marketing co-op for founders. You do small tasks for other founders, like a testimonial, a share or feedback. You earn points. You spend points to get help with your own launch.

What the live site says:

Joining is free. No card required.
250 starter points: 50 on signup, 200 after your first favor.
Points are earned, never bought.
Nothing mints until the work is verified. Fraudulent points get clawed back.
Rallies. Bundle launch-day shares, feedback rounds and testimonials into one request.
A public project page with a backlink. Paste your URL and the AI writes the listing.

Examples of what favors are worth: an upvote is +5, a review +50, a testimonial +500, a featured article up to 2,500.

It is the tool I wished I had when I was the one posting into silence.

The 10-customer checklist

Message 20 people you know
Set up the first three by hand
Submit to one directory
Post one honest Show HN if it is truly try-able
Join Favors.dev and trade for launch-day help

Start with number one today.

If you build with AI agents, come hang out in the Vibe Coding is Life community on Skool. Drop your project in there.

Domain Flipping With AI: Find Undervalued Names Before Everyone Else

Mark Fulton — Tue, 13 Oct 2026 11:33:51 +0000

Domain flipping is not dead. It just stopped being a game for people who refresh a page.

I used to be a domain reseller and blogger. I know the feeling of seeing a good name an hour too late. The names that sell are rarely the hidden ones. They are the ones somebody saw first.

AI agents are good at exactly that job: looking at everything, all day, and telling you about the few things worth your time.

Free stuff to grab first

The open source AI Employees. Eight roles, MIT licensed, free to hire on every plan including Free. A GTM Engineer, an SEO/AEO Employee, a Social Media Employee and five more. Handy when you want someone to write your listing copy and post it. Grab the AI Employees
ExpiredDomains.net. A search engine for expired and deleted names. It tracks pending-delete domains across 676 TLDs and shows backlink counts and Archive.org birth dates. Sign up is linked from the home page, and the page does not state what is free, so check before you pay. ExpiredDomains.net

That is the whole list. I only link what I opened today.

What flipping actually is

Buy a name for less than it is worth. Sell it for more. That is it.

The work sits in three places:

Finding names early enough to matter
Judging whether a name has a buyer
Tracking what you paid, what it earns, and when it renews

Most beginners fail at the second one. They buy a name they like. Nobody else likes it.

Where an agent helps (and where it does not)

Job	Agent does it well?
Watching auctions around the clock	Yes. It does not sleep.
Pulling age, backlinks, search demand	Yes. Boring, repeatable, fast.
Comparing against past sales	Yes.
Deciding you actually want the name	No. That one is yours.
Writing the sales copy	Yes, then you edit it.

The agent narrows 10,000 names to 10. You still choose.

The tool I built for the finding part

I built PounceDomains because I wanted the watching done for me.

Here is what the live page says it does:

Discovery. It keeps scanning Namecheap Market auctions and scores matches under seven lenses: pronounceable, brandable, keyword, short premium, dictionary, two-word, and custom.
Enrichment. Authority, backlinks, search demand, domain age and last-sold comps, plus an AI resale estimate and a suggested max bid.
Alerts. Email and in-app notices for new matches, outbids, wins and runner-ups.
Closeouts. A lane of no-bid auctions re-listed at low prices, some with minimums as low as $1 depending on the TLD.
Drop monitoring. It tracks no-bid expired names and tells you when they open up to register at standard price.
Portfolio. Cost basis, profit and loss, sell links to several marketplaces, and renewal reminders.

Bidding is one click by default. Auto-bid exists, but it is off until you turn it on, and it comes with budget guardrails and a dry-run mode. I would start without it.

What it costs

From the live page:

Plan	Price	What you get
Free	$0 a month	1 config, hourly scans
Pro	$39 a month	5 configs, 10 minute scans, up to 50 drops monitored
Elite	$99 a month	20 configs, 5 minute scans, up to 250 drops monitored

New accounts get a 14 day Pro trial, no credit card. Annual billing includes two months free.

One honest note. Placing bids needs your own Namecheap Market account, and that has its own subscription and deposit costs. PounceDomains does not cover that.

A sane way to start this week

Make a free account and set up one config around a theme you understand.
Let it run for a few days. Do not bid yet.
Read the alerts. Ask yourself which names you would genuinely pay for.
Place one small bid you can afford to lose.
Log it in the portfolio so you learn your own numbers.

I will not tell you what you will earn. I do not know, and anyone who says they do is selling something.

Try it

If you want the watching off your plate, start the free PounceDomains plan. The Pro trial needs no card.

I hang out with builders in the Vibe Coding is Life community. Come say hi on Skool or in the Facebook group. Tell me the weirdest name you ever almost bought.

How to Sell AI Agents to Local Businesses Without a Sales Team

Mark Fulton — Mon, 12 Oct 2026 11:57:01 +0000

Local businesses do not want an "AI agent." They want the inbox answered, the leads followed up and the ads watched. If you can hand them that, they pay.

I was a domain reseller and blogger before I built software for a living. Selling agent work without a sales team is possible, but only if you sell the right thing.

Grab these first (free)

Open source AI Employees: eight roles under an MIT licence. The page says you can install them, customize them and hand them to clients, with no revenue share. Free account, no card.
n8n: workflow automation you can build visually or in code, and the site says you can deploy on your own infrastructure.
Make pricing: the Free plan is $0 a month with up to 1,000 credits, and the page says no time limit.
SBA: the US Small Business Administration. Counseling and loan info, useful when you talk to owners in their own terms.

Stop selling "AI"

Owners buy outcomes. Here is the pitch that works, in plain words:

"I answer your support inbox." Hardest ticket first.
"I find people ready to buy and write the first message."
"I read your ad results and prepare the next ones to test."
"I keep your leads moving until they close or clear."

Those are real roles on the AI Employees page: Customer Satisfaction, GTM Engineer, Ad Manager, Sales. You do not need to invent a service menu. Pick one.

One role. One business. One monthly fee.

Why no sales team works

A sales team exists to find buyers and keep conversations going. That is a job description, and it is one of the eight roles. Let the agent do the first message and the follow-ups. You do the call.

Short list of what stays human:

The first conversation. Walk into the shop, or send the message yourself.
The approval step. Web Dev Employee finds what broke and the owner approves the fix. Keep that shape.
The invoice. You set the price. Nobody sets it for you.

What you can charge

I will not invent a number. The page for the open source employees says you can "charge whatever you like for installing, customizing, or running them." That is the whole pricing rule. The market sets the rest.

An install fee plus a monthly run fee is one simple shape. Test it on one friendly owner first.

Licence check before you resell

Open source employees (MIT): redistribute and hand to clients, keep the MIT notice intact.
Premium employees: you can install in a client's environment under your own brand and run it as a managed service. You cannot hand over the kit itself or list it as a product. You sell the deployment, not the package.

Read the full terms on the page before you sign anyone.

The first week, no team

Pick one local business you already know.
Pick one role from the list.
Install it for them from the free repo.
Run it for a week and show them what it did.
Quote a monthly fee.

That is it.

If you want the premium library

I built the Agent Ops Club for people doing this. Free gets you the eight open source employees, the walkthrough and Masterclass Part 1. Pro adds the premium library with a resale licence. Lifetime is $499 one time until October 31 at 11:59 PM Eastern, then $999 from November 1. Start free, upgrade only if you use it. The link is the AI Employees one above.

One small ask

If you sell agent work to local shops, I want to hear what they actually asked for. Come tell the Vibe Coding is Life community: Skool is free to join.

AI Startup Domain Names: What to Check and What a Fair Price Looks Like

Mark Fulton — Fri, 09 Oct 2026 12:10:21 +0000

AI startup domain names are a mess right now. Everyone wants a clean name and everyone thinks the good ones are gone.

They aren't. But you have to know where to look and what a fair price looks like.

I used to flip domains. I was a domain reseller and blogger, never a broker, and I still check names before I ship anything.

Free stuff to grab first

Open source AI Employees: eight roles, all open source under the MIT license. The page says "No revenue share" and that you set your own charges for installing, customizing or running them. Free to take.
IANA root zone database for .ai: the official record. It lists .ai as a country-code top-level domain managed by the Government of Anguilla. Read it before you assume .ai is "just a tech extension."
ICANN on registrars: says gTLD names are registered through ICANN-accredited registrars, with several hundred around the world. Know who you are actually buying from.

Now the names.

The extension question

You have three honest options for an AI startup.

.com: still the default people type.
.ai: a ccTLD, per IANA. Popular with AI products. Check the registry's own rules and renewals.
.app or .dev: signals software.

On the .app side, the 199.domains app collection calls it "the extension people read as 'this is software'" and notes that .app sites must use HTTPS.

What a fair price looks like

Here is a number from a live page, not a guess.

That .app collection has 31 names "priced from $69 to $189 (median $139)." Prices are fixed and "never above $199."

Fixed. No haggling. No "make an offer and wait three weeks."

That's the whole bet behind the marketplace I run: $199 or less, a $29 to $199 ladder, one price on the tag.

Before you buy any name

A quick checklist. Boring. Do it anyway.

Say it out loud. Would you spell it to a stranger on a call?
Check the extension rules. Registry, renewals, restrictions.
Check you can actually get it. Fixed price beats a negotiation you'll lose.
Check transfer terms. On the 199.domains app page, the seller starts the transfer to your registrar within 72 hours, and you get a full refund if it doesn't finish.
Buy it before the logo. Names go. Logos don't.

Spotlight: 199.domains

I built 199.domains for people who need a real name without a four-figure invoice.

Per the live pages:

Prices are fixed and never above $199.
Each name passes a quality review.
Ownership is checked through DNS before a listing goes live.
Pay by card. Transfer to your registrar.

It's not for everyone. If you want a one-letter .com, this is not the place.

If you want a clean brandable name for an AI product this week, start there.

What I'd do today

Write down 10 names. Cut to 3.
Check each against the extension rules above.
Buy one. Ship the product on it.

Come hang out

I run the Vibe Coding is Life community. Tell me what name you landed on in Skool or the Facebook group.

AI Passive Income: 4 Real Ways and 3 Marketing Traps

Mark Fulton — Thu, 08 Oct 2026 10:40:18 +0000

AI passive income is mostly a sales pitch. Some of it is real. Here's how I tell the difference.

Short version: nothing is passive on day one. You build, you ship, you support it. Some things get cheaper to run after that. That's the honest ceiling.

And no, I can't promise you income. Nobody can.

Free stuff to grab first

Open source AI Employees: eight roles (GTM Engineer, SEO/AEO, Web Dev, Social Media, Ad Manager, Sales, Customer Satisfaction, Chief of Staff), MIT licensed. The page says: charge whatever you like for installing, customizing or running them, no revenue share. Free to take.
Apify Store: a marketplace of ready-to-run tools. Browse it to see what people already pay for.
Apify monetization docs: describes pay per event and pay per usage pricing for tools you publish.
Gumroad pricing: direct sales are 10% plus $0.50 per transaction. Sales through their discover marketplace are 30%. That gap is big.
Product Hunt: watch it for a week. See what gets attention.

Now the sorting.

The real ones

1. A small tool that sells while you sleep

One narrow agent or app. One problem. Listed where buyers already look.

You still build it. You still answer the emails. But the sale doesn't need you online.

2. A template or starter kit

Built once with a coding agent, sold many times. Cheap to deliver. Cheap to support if it's small.

3. A recurring report

An agent gathers one market every week. People pay monthly for the result.

The agent isn't the product. The numbers that matter are.

4. A managed service you set up once

You install an agent for a business and run it. This one is not passive. But it pays on a schedule, and the open source roles above are a legal place to start.

The marketing ones

"Set it and forget it" income. Anything with no support, no updates, no customers is a store that nobody walks into.
Courses that sell you the dream of the course.
Anything quoting an income figure with no live page behind it.

Rule of thumb: if the pitch has a screenshot of earnings and no link to the product, close the tab.

The part nobody puts in the thumbnail

The moment someone pays you for a setup, a report or a managed agent, you need to send an invoice.

I know. Not glamorous. But a good chunk of "AI income" is just freelance work with a better toolset. And freelance work ends in an invoice.

Spotlight: billable.dev

I built billable.dev for exactly that moment.

Per the live page, it's a browser-based invoice generator for developers. You paste your git log and get line items grouped by day, described by your commit subjects. Then you print it to PDF.

Free tier with the full tool. No account, no trial, no watermark.
The page says your data never leaves your machine. There is no server.
Pro is $4 a month billed every six months, or $79 lifetime, and adds branding, extra templates and estimates.

I build some things for people I know need them, even when I'm not the customer. This is one of those.

What I'd do this week

Pick one real one from the list above.
Grab a free role from item one and see if it fits a trade you know.
Ship something rough. Charge before it feels ready.

Come hang out

I run the Vibe Coding is Life community. Tell me which of the four you'd try on Facebook or Skool.

How to Make Money With AI Agents: 6 Things People Actually Pay For

Mark Fulton — Wed, 07 Oct 2026 11:59:50 +0000

You can make money with AI agents. Plenty of people are doing it. Plenty more are selling you a course about it.

I'll skip the course. Here are six things people actually pay for, and where to start on each.

I'll also be blunt about one thing up front: nobody can promise you income. I can't. The club page I link below says it too. What follows is what the market sells, not a forecast of what you'll earn.

Free stuff to grab first

Open source AI Employees: eight roles (GTM Engineer, SEO/AEO, Web Dev, Social Media, Ad Manager, Sales, Customer Satisfaction, Chief of Staff), MIT licensed. The page says you can charge whatever you like for installing, customizing or running them, with no revenue share. Free to take.
Apify Store: the page calls itself a marketplace of 83,000+ ready-to-run tools. Read what sells before you build anything.
Apify monetization docs: lists pay per event and pay per usage as ways to price a tool you publish.
Gumroad pricing: direct sales are 10% plus $0.50 per transaction. Sales through their discover marketplace are 30%. Read it before you pick where to sell.
Product Hunt: new launches daily. Watch it for a week and see which agent products get attention.

Now the six.

1. Install and run an agent for a business

Small businesses don't want to learn agents. They want a social post to go out and a lead to get a reply.

You set it up. You connect the accounts. You charge for installing, customizing or running it.

That's the whole job. And the open source roles above are a legal starting point.

2. One role for one trade

Don't sell "AI". Sell one role for one kind of business.

A social media employee for dentists
An SEO employee for roofers
A sales follow-up employee for real estate agents

A narrow offer is easy to explain. Easy to explain is easy to sell.

3. A tool on a marketplace

Build one narrow agent. List it where buyers already shop.

The Apify docs describe pay per event and pay per usage pricing. You build once. The marketplace has the traffic.

Check the fee page before you commit. A 30% cut (Gumroad's discover rate) changes your math.

4. Watching things with a clock on them

Auctions. Prices. Listings. Expiring anything.

An agent that watches around the clock and alerts a buyer is a product. People pay for the alert, not for the agent.

5. A scheduled report

An agent gathers one market every week. You sell the report as a subscription.

Pick a market you already know. Your edge is knowing which numbers matter.

6. Digital products built with a coding agent

Templates, starter kits, small apps. Build them in a desktop agent app, sell them on a storefront.

I build some things for people I know need them, even when I don't use them myself. That's a perfectly good reason to build.

What I'd do this week

Pick one of the six.
Take the free roles from item one above and look for the one that fits.
Ship something rough. Charge before it feels ready.

The spotlight: Agent Ops Club

The free tier is real. Per the live page, Free is $0 and includes the eight open source AI Employees, Masterclass Part 1 (9 lessons, about 32 minutes) and a certificate.

If you want the full set, Pro is $349 a year and adds 28 premium systems with a resale license, plus the other Masterclass parts. Lifetime is $499 one time and the page says it ends October 31 at 11:59 PM Eastern. After that it's $999.

The page also says no income or results are promised. I'll say it again. Take the free tier first. Start from the link in item one above.

Come hang out

I run the Vibe Coding is Life community. Tell me which of the six you picked on Facebook or Skool.

AI Agent Business Ideas: 7 You Can Launch This Month

Mark Fulton — Tue, 06 Oct 2026 09:13:17 +0000

Let's skip the theory. You want an AI agent business you can start this month and charge for.

Here are seven. Some are boring. Boring pays.

Free stuff to grab first

Open source AI Employees: eight roles (GTM Engineer, SEO/AEO, Web Dev, Social Media, Ad Manager, Sales, Customer Satisfaction, Chief of Staff), rebuilt as 60 scheduled routines. The page says all eight are open source under the MIT license. Free to take.
Apify Store: a marketplace with 82,000+ ready-to-run tools. Study what sells before you build.
Product Hunt: launches go up daily. Read the front page for a week.
Indie Hackers: founders talking about building profitable online businesses. Steal their questions.
Gumroad pricing: read the fee page before you pick where to sell. Direct sales are 10% plus $0.50 per transaction. Their discover marketplace takes 30%.

Now the ideas.

1. A monitoring agent people pay to not think about

Pick one thing that expires, drops or changes. Watch it around the clock. Alert the buyer.

People pay for the alert, not the agent.

Auctions, prices, listings, filings. Anything with a clock on it.

2. A packaged "AI employee" for one trade

Do not sell "AI". Sell one role for one kind of business. A social media employee for dentists. An SEO employee for roofers.

You can start from the open source roles above, then customize them for a niche.

3. A tool you list on a marketplace

Build one narrow agent. List it where buyers already shop. The Apify Store is one such place, and its docs describe pay per event and pay per usage pricing for tools.

You do the build once. The marketplace brings the traffic.

4. A done-for-you setup service

Small businesses do not want to learn agents. They want it running.

Set it up
Connect their accounts
Hand it over
Charge a flat fee

Boring. Works.

5. A niche report on a schedule

An agent gathers, scores and summarizes one market every week. You sell the report by subscription.

Pick a market you already know. Your edge is knowing which numbers matter.

6. A digital product built with a coding agent

Templates, starter kits, small apps. Build them with a desktop coding agent app, sell them on a storefront. Check the fee before you pick one. A 30% marketplace cut changes your math.

7. Domain discovery

I used to be a domain reseller and blogger. The work is mostly finding the good names before everyone else does. That is exactly what an agent is good at.

I built something for it. It is the spotlight below.

The one I shipped for idea 1 and 7

PounceDomains watches the Namecheap Marketplace around the clock. Per the live page:

AI scores every auction across seven strategies
It enriches names with authority, backlinks, search demand, age and comparable sales
Won auctions log to a portfolio with cost basis and P&L
Drop monitoring for expired domains
580,000+ domains scored
Free plan, Pro at $39 a month, Elite at $99 a month
14-day Pro trial, no credit card

Start with the trial. See what the scoring finds in your niche.

Pick one

Do not build all seven. Pick the one closest to something you already know. Ship a rough version this week. Charge before it feels ready.

If you want people to build alongside, come hang out in the Vibe Coding is Life community on Facebook or Skool. Tell me which of the seven you picked.

Product Hunt and Show HN Launch Rules: What the Pages Say and a 4-Week Prep Plan

Mark Fulton — Wed, 30 Sep 2026 09:14:11 +0000

Two of the most popular places to launch a side project publish their rules in plain language. Almost nobody reads them before launch day, and both rule sets are short enough to read over a coffee.

I read them again this week. The interesting part is not any single rule. It is that the two platforms, built for different audiences, land on the same handful of constraints, and those constraints tell you exactly how to spend the four weeks before you launch.

What the Show HN page says

Show HN's own guidelines open with the test: "Show HN is for something you've made that other people can play with." Then they list what does not qualify, in the page's words: "blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out."

Three more lines matter for anyone planning a launch:

"Please make it easy for users to try your thing out, ideally without barriers such as signups or emails."
"Don't post landing pages or fundraisers."
"Please don't ask friends to upvote or comment. That's not ok on HN."

So the unit of a Show HN launch is a working thing a stranger can use in under a minute, with no gate in front of it. A waitlist page fails the first test before anyone reads your title.

What the Product Hunt page says

Product Hunt's launch guide is stricter about who you are and softer about when. The page states that "Company accounts are prohibited", so a launch runs from a personal account. It says launching is "100% free to use", that you can launch "as often as you have new significant product iterations", and that there is "no discernible advantage to using a third-party hunter", so you can self-hunt.

On timing, the guidance is that "12:01 am Pacific Time is the best time to launch for makers that are planning ahead", followed straight away by "The best day to launch is the day on which you're most prepared."

On help from friends, it is direct: don't ask directly for upvotes. The page tells makers to ask people to "visit and comment" instead.

The pattern under both rule sets

Put the two side by side and the shared logic is easy to see.

Both ban the shortcut. Neither wants a launch that is mostly an audience pressed into voting. The rules are written against manufactured momentum.
Both reward a thing that can be used. HN wants something people can try. Product Hunt's own wording about significant iterations points the same way: a real change, not a re-announcement.
Both leave a legitimate door open. HN welcomes curious questions and specific feedback. Product Hunt says to invite visits and comments. What is left after the shortcuts are removed is real attention from real people.

That is the useful reading. The rules do not say "do not get help". They say the help has to look like what it is: someone looked at your product and told you something true about it.

What to do with the four weeks before launch

If the rules push everything toward real use and real comments, then the work before launch day is collecting the people who will give you both, and it has to happen before the clock starts, because the launch day itself is too late to recruit.

Week 4: get the thing usable with no gate. Remove the signup wall from the first experience. If a stranger cannot get a result in a minute, HN is closed to you and Product Hunt visitors will bounce.

Week 3: get five strangers to use it and write down what they say. Not friends who will be kind. Their sentences become your first comments, your launch copy, and your list of what to fix.

Week 2: fix what they hit, then ask for specific feedback, not votes. "Tell me where this confused you" is a request you can make in public. "Please upvote" is the request both platforms wrote a rule about.

Week 1: line up people who will visit and comment honestly on the day. This is the step most solo builders skip, and it is the only one that cannot be done alone.

The bit that is hard to do alone

That last step is where a solo founder runs out of road. You have no team to send a message to. Your friends are precisely the group the rules warn you off. So the supply of honest early comments comes from people who are also launching and who know what a useful comment looks like.

That is the reason I built Favors.dev. Founders help each other's launches with a testimonial, a share, or real feedback, earn verified points for the work, and spend those points to bring people to their own launch. Points are earned by doing the work, not bought, and the work is verified before points release. If you point the help at feedback and comments rather than votes, it sits inside what both rule pages describe. Read the rules of whichever platform you launch on and ask for the kind of help they permit.

Before you launch anywhere

Read the rules page of the exact platform, the week before, not the night before.
Make the first minute of use gate-free.
Get five honest strangers on the thing while there is still time to fix what they find.
Ask for visits, comments and specific feedback. Never for votes.
Collect the people who will show up on launch day before launch day.

If you have launched on either platform, tell me which rule surprised you most. And if you want a place to swap ideas with other builders, come and say hello in the Vibe Coding is Life community on Skool.

Freelance Developer Rates in 2026: How to Price Work an AI Agent Can Half-Do

Mark Fulton — Wed, 23 Sep 2026 09:54:32 +0000

A client asks for a CSV import feature. Two years ago you would have quoted 20 hours. Today an agent writes a working first draft in the first afternoon, and you spend the rest of the week making it correct.

So what do you bill?

That question is quietly rewriting freelance developer rates in 2026, and the public numbers already show where it is going. I want to walk through them, then price that same CSV job three different ways, because only one of the three still pays you properly when a machine does half the typing.

What the rate surveys actually say

Three surveys with real sample sizes, all published this year or last:

Arc surveyed 5,302 freelance developers worldwide for its 2026 freelance developer rates guide. The global bands run $20 to $50 an hour for juniors, $40 to $90 for mid-level, $75 to $150 for seniors, and $120 to $220 for staff and principal engineers. US and Canada sit at roughly $82 to $130. The line worth underlining is their explanation for the top of the range: AI "increased demand for experienced engineers", because someone still has to architect the system, review the generated code and own the security decisions.

freelancermap's Freelancer Study 2026 surveyed over 5,400 freelancers, mostly in the German-speaking market. The average hourly rate came in at €103, down from €104 in 2025. A one euro dip is small. It still broke a climb that started at €96 in 2022, and it landed in the same study where 85% of respondents said they actively use AI tools for writing, coding and images.

Stack Overflow's 2025 Developer Survey drew 33,662 responses to its AI questions. 84% use or plan to use AI tools. 66% name "AI solutions that are almost right, but not quite" as their top frustration, and 45.2% say debugging AI-generated code takes more time.

Put those side by side and you get a split market. The price of producing code is flattening. The price of judging code is rising. Your rate card has to decide which one you are selling.

One job, priced three ways

Back to the CSV import. Assume a $110 rate, which sits inside Arc's North American band, and an honest breakdown of the new week:

3 hours: agent drafts the parser, the mapping UI and the tests
5 hours: you find the "almost right" parts (encoding edge cases, a date column that silently swaps day and month, a memory spike on a 200 MB file)
2 hours: you rewrite the error handling so a client's customer sees which row failed and why

Ten hours of your time for the same outcome that used to take twenty.

Priced hourly: $1,100. You delivered the same feature, with better tests than you would have written by hand, and you were paid half. Every productivity gain you make flows straight to the client. Keep billing this way and the rate surveys above stop describing your ceiling and start describing your future.

Priced fixed: $2,200 for "CSV import with row-level error reporting, files up to 250 MB, tested against the three sample exports you supplied." You keep the margin. You also carry the risk, and that 66% "almost right" figure is exactly that risk. A fixed price works only when the scope line is sharp enough that "almost right" has a definition.

Priced on the outcome: the client's ops team spends a day a month re-keying spreadsheets. The import removes that. You price against the day, with a written acceptance test. This is the hardest conversation and the best-paid one, because the client is buying a result, not your calendar.

Only the first model punishes you for getting faster. That is the whole argument in one line.

Four rules for pricing work an agent can half-do

1. Stop selling hours you no longer spend. If the agent drafts in three hours what used to take ten, an hourly invoice hands your client the entire gain. Move repeatable work to fixed scope with a written acceptance test. Keep hourly for genuinely open-ended work: debugging someone else's production incident, discovery, advisory calls.

2. Price the review, not the typing. Arc's own explanation for rising senior rates is review, architecture and security. That is the scarce part of the job now. Name it on the quote. "Implementation and review of generated code against your data" tells a client what they are paying a senior for. "20 hours development" invites them to ask why a tool cannot do it.

3. Do not trust your own sense of speed. METR ran a controlled study of 16 experienced open source developers on 246 real issues in early 2025. With AI tools they took 19% longer, while believing afterwards that they had been 20% faster. METR itself calls that result a snapshot and says newer tools have moved on since, so do not quote the number as a law. Quote the lesson: the feeling of speed and the measured speed can point in opposite directions. Measure a few of your own jobs before you reprice anything.

4. Keep a record a client can check. When a feature arrives in two days instead of two weeks, a client's first question is what they paid for. A dated list of what changed each day answers it better than any explanation. Your commit history already is that list, if you keep messages readable. Line items that map to visible work end the "why so much for something the AI wrote" conversation before it starts.

Where freelance rates go from here

My bet: by the end of 2027 the phrase "hourly rate" will mean two different numbers. One is the rate for supervised implementation, and it will keep drifting down as the tools improve, the way freelancermap's series just flattened. The other is the rate for judgment: scoping, review, security sign-off, owning the outcome when it breaks at 2 AM. That number is the one Arc already sees climbing.

The freelancers who do well will not be the ones who refuse the tools or the ones who hide them. They will be the ones who price the outcome, show the record and stop apologising for being fast. The client does not care how many hours the parser took. They care that row 4,812 tells their customer exactly what went wrong.

Turn the record into the invoice

Rule four is the one most freelancers skip, because turning a week of commits into clean line items is tedious. That is the job I built billable.dev for. It is a free invoice generator for developers that runs entirely in your browser: import your git log, it groups the commits by day, you edit them into line items, add your rate or your fixed fee, and print a clean PDF. Nothing goes to a server. Your client sees dated, checkable work instead of a single "development" line.

If your next invoice covers work an agent helped with, try it on that one and see whether the conversation about the number gets shorter.

Want to compare rate cards with other builders? The Vibe Coding is Life community on Skool is free to join, come say hello.

Multi-Agent Systems: 4 Tests for When One Agent Beats Five

Mark Fulton — Tue, 22 Sep 2026 11:35:56 +0000

A team at Anthropic built a research system where one lead agent hands work to several subagents running in parallel. On their internal research eval it beat a single agent by 90.2%.

In the same write-up they said it burns about 15 times the tokens of a plain chat, and that token usage by itself explained 80% of the variance in performance on the BrowseComp benchmark.

Put those two numbers next to each other and the headline changes. Five agents did not win because five heads think better than one. They won largely because the job let them spend more compute in parallel on pieces that did not need each other.

That distinction decides whether a multi-agent design pays for itself or quietly fails. And there is now published data on how it fails.

The failure data

In 2025 a group of researchers from UC Berkeley and collaborators published Why Do Multi-Agent LLM Systems Fail?. The abstract opens bluntly: the performance gains of multi-agent systems on popular benchmarks "are often minimal."

So they went and looked at why. They collected more than 1,600 annotated traces across 7 popular multi-agent frameworks, labelled them with an inter-annotator agreement of 0.88 kappa, and ended up with 14 failure modes in 3 categories:

System design issues, roughly four failures in ten. Disobeying the task specification, repeating steps, and not knowing when to stop are the big ones.
Inter-agent misalignment, about a third. The single largest mode here is a reasoning-action mismatch: the agent says one thing and does another. Failing to ask for clarification and drifting off task follow.
Task verification, about a quarter. No verification, wrong verification, or stopping before the work is done.

Read that list again and notice what is missing. "The model was not smart enough" is not a category. The authors say it directly: failure "is not merely a function of challenges in the underlying model." Most of what goes wrong is structure. Who owns what, what counts as done, and who checks.

They also tried the obvious fixes on one framework. Clearer role specifications lifted the success rate by 9.4%. Adding a high-level verification step lifted it by 15.6%. Real gains, and the authors still concluded those isolated fixes were not enough and that reliability needs deeper redesign.

Four tests before you split one agent into five

Here is how I read the combined evidence as an operator. Before a job gets more than one agent, it has to pass four tests. Fail any one and a single agent with a good brief will usually win on cost, speed and reliability.

1. Does the work actually split?

Anthropic's own post names the poor fit: domains where every agent needs the same context, or where there are many dependencies between agents. They add that most coding tasks have fewer truly parallelizable pieces than research does.

The test is simple. Write the subtasks down. If subtask B needs the output of subtask A before it can start, you do not have parallel work. You have a pipeline, and a pipeline run by five agents is one agent with four extra handoffs, each one a chance for context to get lost.

Research splits well: ten sources can be read by ten readers who never talk to each other. Refactoring a module does not.

2. Is the job worth 15x the tokens?

If multi-agent runs cost roughly 15 times a chat, the output has to be worth that. A question someone asks once a quarter that saves a day of reading clears the bar easily. A routine task run a hundred times a day almost never does.

Price it before you build it. Take the cost of one good single-agent run, multiply by fifteen, and ask whether a person would pay that for the better answer. If the honest answer is no, the architecture is decided.

3. Can each agent be told exactly what done looks like?

System design issues were the biggest failure category, and the top modes inside it were ignoring the task specification, repeating steps and missing the termination condition. Those are all brief problems.

Every agent in the system needs its own written job: the input it gets, the output it returns, the format, and the condition that means stop. "Research the competitors" is not a job. "Return the pricing page URL and the lowest paid tier for each of these six companies, as a table, and stop when all six rows are filled" is a job.

If you cannot write that for every agent, you are not ready for more than one.

4. Who checks the work before it leaves?

A quarter of the failures were verification failures, and adding a verification step was the single biggest fix the researchers measured. That is the cheapest lesson in the paper.

A multi-agent system without a named checker is a group chat. Someone, human or agent, has to hold the definition of correct and compare the output against it before anything ships. Not "looks good", but a check against the spec from test 3.

Where this is heading

The paid skill is moving away from choosing the model and toward designing the roles.

Models will keep getting better, and the failure data says that will not fix most of this. Step repetition, missing stop conditions, one agent ignoring another, nobody verifying: those survive a model upgrade because they live in the design, not the weights.

So the operators who win the next two years will think less like prompt writers and more like managers. One agent per job. A written brief per job. A clear owner for the check. And the discipline to keep a job on a single agent when it does not split, even when the five-agent diagram looks better in a demo.

That also changes what you can sell. A client does not want "a multi-agent system." They want a job done on a schedule that they never have to think about. The builder who can say "this role handles your outreach, this one handles support, and this one reviews both every morning" is selling something a business already understands how to buy: staff.

Start from roles, not agents

That is exactly how the AI Employees are built. There are eight of them, each a named role with its own job: a GTM Engineer, an SEO/AEO Employee, a Web Dev Employee, a Social Media Employee, an Ad Manager, a Sales Employee, a Customer Satisfaction Employee, and a Chief of Staff for oversight. Each one is a complete routine set for a job you would otherwise hire for, and the whole set is open source and MIT licensed on GitHub.

It is the four tests above, already applied: one job per role, work that genuinely splits by function, and a role whose whole job is the check. Hire the one that matches the job you keep doing yourself and read how its brief is written.

If you want to talk through where your own work splits and where it does not, come hang out in the Vibe Coding is Life group on Facebook. Bring the job you are thinking of splitting.

App Directory SEO: 5 Rules for Getting an Indie App Found in 2026

Mark Fulton — Mon, 21 Sep 2026 09:13:02 +0000

Google's own spam policy has a list of link spam examples. Fourth on that list, word for word: "Low-quality directory or bookmark site links."

That one line kills the reason most indie developers submit to app directories. The plan usually goes like this. Ship the app, find a list of 100 directories, paste the same tagline into all of them, and wait for the backlinks to lift the domain.

Google's definition of link spam is "the practice of creating links to or from a site primarily for the purpose of manipulating search rankings." A directory you joined only for the link is that, by definition.

So are directories dead? No. The job they do has changed, and most submissions are still aimed at the old job.

What the documentation actually says

Three things from Google Search Central are worth knowing before you fill in another submission form.

Directory links are named as a spam pattern. The spam policies page lists low-quality directory links next to buying links, excessive link exchanges, and "using automated programs or services to create links to your site." Blast submission tools sit in that last bucket.

User-submitted links are usually qualified. Google's guidance on outbound links recommends marking user-generated content links with rel="ugc", and says links marked that way "will generally not be followed." A directory that takes public submissions is exactly the kind of site that should be using it. Check the source of a listing before you assume it passes anything.

Indexing is not a promise. Google's How Search Works doc says it plainly: "Google doesn't guarantee that it will crawl, index, or serve your page." Pages are discovered by following links from known pages and through sitemaps, and the same doc lists low-quality content and duplicate pages among the reasons a page is processed but never indexed.

Put those together. The link from a random directory is likely discounted or qualified, and the listing page itself may never be indexed if it carries the same copy as forty other listings.

What survives is the part people skip: a listing is a page that a person reads, on a site where people go to find software.

5 rules for app directory SEO that still hold

1. Submit for the reader, not the link

Ask one question before any submission. Would someone looking for an app like yours actually browse this site? If the only visitors are other developers dropping their own links, the listing does nothing for you and the link may do less than nothing.

A good directory is one where the traffic is people trying to find software, not people trying to be found.

2. Prefer directories with a gate

The cheapest signal that a directory is not a link farm is that something stands between your form and a live listing. A human review. A requirement that the app actually works. A category it has to fit.

A gate cuts both ways. It means your listing takes a few days. It also means every other listing next to yours passed the same check, so the page reads as a curated set rather than a dump. That matters to human visitors, and it is exactly the property a search system is trying to detect.

3. Write a different listing for every directory

Forty identical taglines are forty near-duplicate pages. Google clusters duplicates and picks one canonical, and the rest are candidates for never being indexed at all.

You do not need forty essays. You need the first sentence to change with the audience. A dev tools directory gets the technical hook. A general software directory gets the outcome. Keep a short file of three or four variants and rotate them.

4. Put the try path in the first line

People browsing a directory decide in seconds. The question in their head is not "what does it do" but "can I try it right now without talking to anyone."

Say it up front: free, free trial, or freemium. If a visitor has to click through to your pricing page to learn whether they can even start, most will not.

5. Measure try-clicks, not backlinks

Tag every directory URL with its own UTM parameters so your analytics can tell you which listing produced a signup. After a month you will know which three directories are worth maintaining and which thirty you can forget.

Backlink counts from a directory sweep tell you nothing about whether anyone arrived. A single listing that sends five people who try the app beats a hundred that send none.

Where this is heading

The reader of a directory is changing. Search engines were already discounting directory links. Now the systems that answer "what is a good free tool for X" are models and agents that retrieve pages, read them, and summarise. They do not care about link equity. They care about whether a page states clearly what the app is, who it is for, and how to try it, and whether the site it sits on is the kind of place that checks.

That flips the directory's job. It stops being a source of ranking juice and becomes a trust filter: a small set of curated, human-checked listings that a person or a model can read and act on. The developers who win discovery over the next few years are the ones who treat every listing like a small product page on a site that deserves it.

The practical move today is small. Pick five directories that pass rule 1 and rule 2, write five different listings, tag the links, and check the numbers in thirty days. That is an afternoon, and it beats a hundred-directory sweep.

Where I list apps

This is the reason I built TryMy.App. It is a free directory for apps people can actually try: every listing is free, has a free trial, or is freemium, so the try path is the whole point of the page. A human checks that each app is real, that the URL works, and that it is not a scam before it goes live. Paid-only apps, dead links and anything that is not yours do not get in.

Submitting takes about two minutes: the URL, a tagline, two or three sentences of description, and how people can try it. Free listings are the default and do not expire.

If you shipped something this year that people can try without a sales call, submit it there. Then go apply rule 5 and see whether it sends anyone.

I hang out with a big crowd of builders shipping things like this every week in the Vibe Coding is Life group. Come show what you are launching: facebook.com/groups/vibecodinglife.

AI Agent Security: 4 Failure Modes That Are Not Prompt Injection

Mark Fulton — Fri, 18 Sep 2026 11:46:10 +0000

Prompt injection is one item on a list of ten.

That is worth sitting with, because if you read the agent security conversation online you would think it was the whole list. The OWASP Top 10 for LLM Applications 2025 opens with LLM01:2025 Prompt Injection, and then names nine more things that will take your system down: Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption.

Nine of the ten are not about someone typing something clever into your chat box.

Here is why that matters more every month. Prompt injection is an input problem, and the model vendors are working on it with resources you do not have. The other nine are architecture problems, permission problems, budget problems and dependency problems. Those are yours. They do not get fixed by a better model, and in my experience they are the ones that actually cost a business money, because most of them do not require an attacker at all.

Four of them are the ones I would check first on any agent that is allowed to act. Each one below is quoted from the standard, then translated into what it looks like on a Tuesday when the agent is working exactly as designed.

1. Excessive Agency: the agent did what you let it do

OWASP defines this as a system that has been "granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions", and then does damage through unexpected or manipulated output. The important clause is the last one: regardless of cause. No adversary required.

The standard breaks it into three root causes, and they are worth memorizing as three separate questions:

Excessive functionality. Capabilities beyond what is operationally necessary. The classic version is handing an agent a shell tool because it was easier than writing four narrow ones. OWASP says it plainly: avoid open-ended extensions in favour of granular functionality.

Excessive permissions. Broader access rights than the role needs. The agent runs as a service account that can write to every table because that is the credential you had lying around.

Excessive autonomy. High-impact actions executed without independent verification. The agent sends, refunds, deletes or publishes with nothing between the decision and the effect.

Most teams I talk to have all three, and none of them were decisions. They were defaults.

The control is not clever. It is a written list of what this job may touch, scoped to that job, plus a human approval gate on anything consequential. One line from the mitigation guidance is the part people skip: implement authorization validation in downstream systems rather than relying on the LLM to police itself. The model is not your access control layer. It never was.

2. Improper Output Handling: your systems trusted a sentence

LLM05 covers "insufficient validation, sanitization, and handling" of model output before it reaches something else.

This is the failure mode that feels least like security and most like plumbing, which is exactly why it survives review. An agent emits a string. The string gets interpolated into a query, or a shell command, or a rendered page, or a config file. Nothing was injected from outside. The model simply produced a plausible sentence in a context where a sentence is executable.

The test I use is a single question: where does this agent's output stop being text and start being an instruction to another system? Every one of those boundaries needs the same validation you would apply to a form field filled in by a stranger, because in terms of trust, that is what it is.

3. Unbounded Consumption: the invoice is the incident

LLM10 is the one I think is most underrated, and the standard gives it a name I like: "Denial of Wallet (DoW)". OWASP describes it as attackers initiating high-volume operations to exploit pay-per-use cloud AI service models, imposing an unsustainable financial burden.

The agent version does not need an attacker. It needs a retry.

An agent that fails, retries with its full context appended, fails again and retries again is a cost loop that nobody wrote and nobody sees until the bill arrives. Multi-turn agent runs already grow context faster than most people expect, and a retry loop multiplies whatever that per-turn cost had already become. The failure is silent, it looks like normal usage in every dashboard, and the alert is an invoice at the end of the month.

The mitigations are unglamorous and they are the same ones you already know from API design: rate limits and per-user quotas, timeouts and throttling on intensive operations, resource monitoring, anomaly detection, and graceful degradation under load. The only new part is remembering that the agent is a user of your system, and a poorly behaved one.

4. Supply Chain: you did not write most of your agent

LLM03 covers vulnerabilities inherited through the chain: models, training data, deployment platforms, and the third-party components around them.

An agent's real surface area is rarely code you wrote. It is a model you did not train, a tool server you installed last month, a package that wraps an API, and a prompt template you copied. Every one of those is something that can change under you without a deploy on your side.

The question I would put on every agent review is uncomfortable and cheap to answer: if each third-party component in this agent were replaced tomorrow with a subtly worse version, which one would we notice, and how? If the answer for most of them is "we would not", you do not have a supply chain, you have a collection of assumptions.

The thing all four have in common

None of them requires a villain.

Excessive agency is a permission you granted. Improper output handling is a boundary you did not name. Unbounded consumption is a loop with no ceiling. Supply chain risk is a dependency you did not review. Prompt injection gets the attention because it has a narrative, an attacker doing something sneaky. The other four just sit there and behave like ordinary engineering debt until the day they do not.

This is where I think agent work is heading, and it is a good thing for the people reading this. Building an agent that demos is now table stakes. The scarce skill is running one: bounding what each job can touch, naming an owner for every action with a consequence, putting a ceiling on spend, and keeping a record you can actually check afterwards. That work looks a lot more like change management than like red teaming, and it does not get commoditized by the next model release.

If you want to be paid for agent work in a year, get good at the boring half. Anyone can make one run. Making one run for nine months without a surprise is the job.

Where to start if you want the operator side

I put the whole operator layer I use into the Agent Ops Club, and the free tier is genuinely free: the eight AI Employees on GitHub under an MIT licence, the Hire Your First AI Employee walkthrough, Masterclass modules 1 and 2 in full, the free public trainings and calendar, and Agent Ops Chat. No card required.

Each one is a named role with a named job, which is the whole point of this post. The next step is small. Open one of them on GitHub, read what it is allowed to do, and check it against the first failure mode above. If you cannot name the boundary of a job, that is the work.

If you build or run agents and want to compare notes with other builders, come and find us in Vibe Coding is Life on Facebook.