Back to all posts
Technical StrategyAI Automation

Your Next Customer Won't Look at Your Homepage

ChatGPT's browser can now call a website's own tools directly, which means the highest-leverage AI work for a small team is making your product callable, not chatty

Three founders have asked me the same question this year, in almost the same words: what AI feature should we build?

Every one of them was already halfway to the same answer. A chatbot. In the corner of the product. Trained on their docs. Something that would demo well and get a slide in the next board deck.

I think that's the wrong spend, and this week gave me a cleaner way to explain why.

The news, briefly

OpenAI's desktop ChatGPT browser now supports WebMCP. The short version for a non-technical reader: instead of an AI agent squinting at your website and guessing which button to click, your site can publish a list of the actions it performs, and the agent calls those actions directly. Book the appointment. Run the search. Submit the claim. No pixel-hunting.

I haven't shipped against it. It landed a few days ago. But I've watched the underlying pattern play out for most of a decade, and the pattern is what matters here.

Two things change the moment a real consumer agent can call your tools. Your visitor might not be a person. And the visitor that is a person might be sitting next to an agent doing half the work for them.

The distribution question wearing an engineering costume

Here's the reframe I'd want a founder to walk away with.

A chatbot inside your product is a retention feature. It helps the people who already found you, already signed up, already logged in. It is the last mile of a journey they completed on their own.

Making your product callable by somebody else's agent is a distribution feature. It puts you inside a surface where your customer already spends their day and already pays a subscription. That's not a UI decision. That's the same category of decision as deciding to be on the App Store in 2010 or to have a Shopify app in 2018.

Small teams should almost always buy distribution before they buy polish. I learned that the expensive way.

What actually drove 10M MAU

At Lucky Day I spent six-plus years going from pre-revenue to 10 million monthly active users, with a team that grew from 4 engineers to 31. If you asked me in year two what would move the number, I'd have said the product. Better screens, faster flows, cleaner onboarding.

The honest answer was integration surface. Ad networks, attribution partners, payment rails, platform hooks. Every clean interface we exposed to somebody else's system pulled in users we did not have to go find. Every quarter we spent perfecting internal screens moved a metric we could feel but not point to.

That's not an argument against good product. It's an argument about sequence when you have four engineers and eighteen months of runway. Interfaces compound. Polish doesn't, not at that stage.

An agent-callable version of your product is exactly that kind of interface. The difference is that in 2018 you had to negotiate the partnership. Now the distribution channel is a spec you can publish unilaterally.

What this actually costs

This is the part founders get wrong in both directions.

The chatbot quote you're about to accept is real money, and it buys you a feature your competitors will have by Christmas. Meanwhile the work I'm describing is genuinely small. One competent engineer, days not months, if and only if somebody has already answered the hard question.

The hard question is not technical. It's: what are the three things your product actually does?

Not thirty. Three. The three verbs that, if an agent could invoke them on behalf of a user, would complete a real job. For a scheduling product it might be search availability, hold a slot, confirm. For a compliance tool it might be submit a document, check status, export the result.

I ship a lot of three-week MVPs, at a fixed $14,500, and the entire job in week one is deciding what we don't build. Founders arrive with a list of forty features and leave with four. That muscle, deciding what the product is by refusing to build most of what it could be, is precisely the muscle you need here. When I built FlipSmrt solo, I had no choice but to use it. One person can only expose a handful of surfaces well.

So the work is: pick three actions. Describe them so a machine can call them. Handle auth. Test what an agent does when it gets something wrong.

That last item is the one people skip.

The part that isn't days of work

If an agent can call your product, an agent can call your product badly. It can call it in a loop. It can call it with garbage arguments. It can call it a thousand times while a user watches a spinner.

You need rate limits per identity, not per IP. You need every callable action to be idempotent, meaning calling it twice does the same thing as calling it once, because agents retry. You need destructive actions gated behind something an agent cannot do alone. And you need to know who is on the other end, because "a human customer" and "a customer's agent acting on their behalf" have different failure modes and should have different permissions.

That's the real scope. It's still not a hire. It's a decision about which actions are safe to hand out, and that decision belongs to you, not to whoever writes the code.

I've written before about who's allowed to say no when agents can ship. Same principle, pointed outward. Exposing capability without exposing a stop button is how a small team ends up with an incident it can't explain to a customer.

What I'd do this quarter

If you're pre-product-market-fit with a small team, I'd put the chatbot back on the shelf and spend one week on this instead. Write down the three actions. Have someone expose them properly. Watch what an agent does with them.

You will learn something uncomfortable and useful: whether your product actually performs a job, or whether it's a collection of screens that requires a human to assemble the job themselves. Products in the second category cannot be called by an agent, and they were always going to be hard to sell.

The homepage isn't dead. It's just no longer the only door, and it may not be the door your next customer uses.

If you want to spend a sprint figuring out which three actions yours should be, that's exactly the kind of scoping I do. Otherwise, the assignment is free: open a doc, write three verbs, and see how hard it is.

Written by Hootan Nikbakht

Building something?

Get a second opinionbefore it costs you a quarter

I build MVPs for non-technical founders and step in as interim CTO when there's a leadership gap. If this one hit close to home, bring me the repo.

Or email hootan@nikfam.ai.