You Already Built It. Nobody Came.

The qualifying profile can belong to the applicant’s own business or to a client they manage. It must have a website representing the business. Meeting those requirements lets the developer apply; Google still has to approve access. The rule governs the applicant’s eligibility, rather than imposing a fresh waiting period on every customer.

Getting approval would remove a delivery constraint. Evidence that someone wants the product has to come from somewhere else.

That distinction matters when a launch stalls. An empty billing dashboard tells you little about where people stopped. A relevant buyer might never have seen the offer, a willing buyer might have been unable to connect, or someone might have tried it and declined. Each gives you a different reason to open the editor, or leave it closed.

The compiler replies

An unanswered email can mean the offer missed, the recipient couldn’t buy, or the message was never read. You don’t get a stack trace. The compiler, for all its pedantry, replies every time.

Returning to code restores a feedback loop you know how to work. But if silence is the only evidence, choosing another feature also means choosing a cause before you’ve observed one. You could spend the next sprint improving an experience your intended buyer has never reached.

A blanket instruction to stop building makes the same mistake in reverse. If a buyer wants to proceed and your connection flow breaks, repairing it is useful work. You need to locate the interruption before deciding which skill to use.

Follow the person past the signup

For the review tool, developer approval is only part of the path. Google also requires the business owner’s explicit consent for an app to access and modify their location data. That creates a question an account-created event can’t answer: did you reach someone who can authorize the next step?

If the person doing the review work needs someone else to connect the business’s profile, the next useful conversation includes that person. A clearer invitation flow might help. So might selling to a different role. Watching the handoff tells you which possibility deserves a test; another dashboard widget tells you neither.

A failed authorization request and an owner declining access deserve different notes. If the owner refuses because they don’t want an app acting for the business, a retry button won’t settle that concern. Ask what they need to know before granting access. They may reasonably prefer to keep doing the task themselves.

Compare that with an authorized owner who connects successfully, handles a real review, then declines the paid plan. Access has been tested in that case. The remaining questions concern the value of the result and the terms of buying it. Even here, a refusal alone won’t tell you whether the price is wrong, the task is too infrequent, or the existing way of doing it is good enough.

Ask how they handled the last review without your app, and what completing it in yours changed. If the old way is good enough for them, that is a reason to question the offer itself. If they name a missing capability, ask to see the work it prevents them from finishing before turning it into a build plan.

For each prospect, keep the source of the introduction, their role, the last step they completed, and any reason they gave for stopping. Separate what you observed from what they said and what you suspect. Leave an unknown reason unknown.

An overall conversion rate hides these handoffs. For the same group of prospects, keep counts of who tried to connect, completed the review task, saw the price, and paid. Payment among people who reached the useful part of the product helps you examine the offer. Keep the contacted-to-paid result beside it; excluding blocked users from that total would hide a problem you still own.

This is where systems design helps with distribution. You can inspect the handoffs without pretending people behave like deterministic components. You can also distinguish a channel that brings interested people from one that brings people able to act.

What would the agency actually do?

An agency that manages business profiles might be a route to customers. But access to profiles, by itself, supplies no reason for the agency to introduce your product to its clients. It could already sell the work you’re proposing to automate.

A concrete proposal would specify what the agency gains and what it will do: introduce you to an owner, include the app in a service it sells, or buy it for its own staff. Those arrangements put different people in charge of using and paying for the product. Agreement to discuss a partnership leaves all of that open.

Brian Balfour’s 2017 essay on product-channel fit argues that products have to fit the rules of their acquisition channels. Applied here, that means a channel choice can give you legitimate product work. If an agency agrees to buy for its staff but needs a way to keep clients’ accounts separate, you have a specific design requirement to investigate. Building an agency dashboard before anyone accepts that arrangement merely adds another untested assumption.

Direct owner outreach remains a reasonable alternative when you can reach owners who have the need and authority themselves. The agency route earns consideration when it provides an introduction or purchasing relationship you can’t obtain as readily alone. Test the arrangement before planning around its client list. Follow an actual referral through consent, use, and a payment decision; if the agency is the buyer, follow its staff through the task and put the price in front of whoever controls that budget.

Get through the first handoff

In his July 2013 account of Stripe’s early acquisition, Paul Graham describes the Collison brothers recruiting other Y Combinator startups. Once someone agreed to try Stripe, the founders set them up on the spot instead of leaving them with a link to follow later.

The audience matters as much as the installation. YC gave Stripe access to a concentrated group of potential users. Copying the hands-on setup without a way to reach buyers copies only part of the method. The account shows how willing users got started; it doesn’t isolate that tactic’s contribution to Stripe’s later growth or prove it would pay for itself in another market.

For the review tool, you can test a similarly complete path without an automated acquisition system. Reach a business through the route you’re considering. Once the required access and consent are in place, help it complete the review task you intend to sell. Put the actual price in front of the person who can approve it.

If they pay while you do the work for them, record that too. You’ve tested a hands-on offer, with self-service demand still open.

Include your own labor and any agency share when deciding whether that offer is worth repeating. An initial setup can be a cost of acquiring a customer; handling every review for them becomes part of the service you’re selling. Automation might reduce that recurring work, but count the saving only after you’ve demonstrated it.

For the next business, let its owner complete the task and watch where they need help. If you’re selling a recurring plan, follow what happens when another review needs attention. The signup remains in your chart even if the owner goes back to doing the work elsewhere.