Last week I wrote about intent drift: a user asks for “a simple todo app,” the pipeline returns a calendar tab, a settings tab and a profile screen, and nothing crashes. No stack trace. No failing test. Every agent reports success.

This week I stopped guessing about who that matters to and started talking to them - solo freelance mobile developers.

I walked in confident and wrong

One of them has been freelancing since 2019 - Fiverr, Upwork, then referrals - and works Flutter-only these days. I went into that call certain her biggest problem was the backend. That’s the wall I hit for years as a mobile engineer, so obviously it was hers too.

She rated backend 3 out of 5. Solved enough. Firebase and FCM for a solo client, a proper Node backend once the client’s team is two or three people - a sizing rule she applies without thinking about it. Move on.

Her actual number one problem, on every project she takes:

The client says “simple app.” Nothing gets written down. Three weeks in, they remember a feature they had always assumed was included - same deadline, same budget. On one project the support window she had priced as business hours was something the client had assumed meant 24/7. It had never been written down anywhere.

Nothing crashed. No test failed. Everyone believed the project was going fine.

That is the same bug. The only thing that changes is the wire format. Between my agents it’s English. Between a client and a freelancer it’s a WhatsApp thread.

The half of the job nobody can see

Then the part I had not considered at all.

Local storage. Offline screens. Error states. Update handling. The notification pipeline. She reckons 80 to 90 out of every 100 clients see only the UI. Nobody counts that as work, so nobody pays for it - and she can’t even produce a list of it to show them.

That last clause is the interesting one. It isn’t that clients refuse to pay for invisible work. It’s that the invisible work has no artifact. There is no line item to point at, no name for it, nothing that survives the conversation. Scope you can’t enumerate is scope you can’t charge for, and it’s also scope you can’t defend when the deadline slips.

I have spent months building exactly that artifact for agents - a written-down list of what’s in scope, what’s fenced off, and what “done” means for each row. I built it because agents can’t be trusted to remember. It turns out humans can’t either, and for the same structural reason: the thing was never written down in a form you can point at later.

She has lost clients for not being a designer as well as a developer. She has had a client turn angry over a cloud bill at ten test users. None of that is a coding problem.

The feature that is the whole point is the one that breaks the estimate

The other pattern she described: the single feature that makes an app worth building at all is reliably the one that eats a disproportionate share of the time. Connection rules on a social-style app. Medical data handling. A maps-and-directions integration.

One project built around routing and maps ran three or four months and then ended without shipping.

This one stung, because it’s the exact shape of the problem in my own system. The generic surface - lists, forms, auth, tabs - is the part that’s cheap for a human and cheap for an agent. The differentiating feature is expensive for both. Any tool that gets great at the cheap 80% and hands back the expensive 20% unchanged has automated the part that was never the bottleneck.

She had already built the harness

The thing I keep coming back to is that she isn’t missing the concept of a spec. She’s assembled one by hand, in pieces, from scar tissue:

• A full cost sheet handed over before anyone signs - Play’s $25, Apple’s $99, OTP charges, the AWS bill - because of the client who got angry at ten test users.
• Delivery phase by phase as APKs, so “done” gets defined repeatedly and in public rather than once at the end.
• One month of free bug support after launch. Small tweaks as goodwill; anything larger quoted per item.
• A handover pack: builds, the GitHub repo, Figma, the account and password list.
• A hard line about not hosting client apps on her own store accounts.

Every one of those is a fence around scope, written down, agreed before the work starts. That’s a cost sheet, an approval gate, a support boundary and a change-order process - the same four things I built for my pipeline, except hers are in a spreadsheet and a WhatsApp thread, and each one exists because a specific project went badly first.

So the gap isn’t that freelancers don’t know intent needs pinning down. It’s that every one of them is rebuilding the same harness alone, from their own worst projects, and the invisible-work list - the one thing that would let them charge for half the job - is the piece nobody has managed to write down at all.

The thing that argued against my own pitch

One more, because it cuts the other way.

Her flagship project - a commodity-exchange broker app, chatbot signup, GST verification, tender feature, yearly subscription - took about two years across versions, with heavy internal testing. Not because she was slow. Because the client wanted a rigorous rollout to a community of roughly a thousand traders, and explicitly did not want a fast launch.

I sell speed. That client wouldn’t have bought it. Two years wasn’t a failure of tooling, it was the requirement - and it’s worth me noticing that the projects with real money in them are sometimes the ones where “ship it faster” is the wrong offer entirely.

What this changes for me

I built acceptance criteria, approval gates and reconciliation to stop my agents drifting mid-run. Reading my own notes back after that call, the uncomfortable read is that the more valuable version might be stopping the drift that happens before a single line of code exists - between two people, in the week where everything is still “simple app” and nobody has written anything down.

I’m not going to pretend I know yet what that turns into. One conversation is one conversation, and I’ve already been confidently wrong once this month. The next few calls will tell me whether the invisible-work list is a real, repeatable pain or one person’s very good spreadsheet - and whether the differentiating-feature problem is the thing worth attacking instead.

But I know which assumption I no longer hold. I spent years believing the hard part of mobile freelancing was the backend, because that’s what was hard for me. It cost me nothing to check. It would have cost me a year to keep assuming.

Talk to five people. It costs you a week. Being confidently wrong costs you a year.

Building Naapy in public, wrong turns included - na-apy.com.