A restaurant client was about to launch a new physical menu and asked us to update the menu on their website to match.
Fair request, squarely inside their maintenance agreement, exactly the kind of thing we’re here for.
So I did it. They sent photos, I had Claude Code do the tedious part, and the site was live and correct the same day. Nobody should spend a human hour transcribing menu items when a machine does it faster and doesn’t get bored on item forty. Done. I moved on.
Then this landed in my inbox.
”We still have the old menu on the website”
That can’t be right, I thought, because I’d checked it myself, twice.
So I asked for a screenshot. What came back wasn’t the website at all. It was the menu on his Google Business Profile — which, I’ll be honest, I didn’t know restaurants could even put there. To him it’s all “the website.” To me it was a second menu living in a system I’d never touched, quietly serving the old prices to everyone who searched the restaurant by name.
Fine. New surface, same job. I’d update it, and while I was in there I’d automate it so it never had to be done by hand again.
That was the plan.
There is no easy button
A bit of research turned up exactly two official ways to bulk-update a restaurant menu on Google Business Profile. One is connecting an integrated point-of-sale system. The other is their API, which you apply for and wait to be approved for.
The POS route wasn’t happening on this timeline. And I’d promised the changes would be live today, which ruled out waiting on an approval queue.
What I had instead was a web form. One item at a time. Thirteen sections. One hundred and eight items.
I’ll do tedious work when there’s no other way. There is almost always another way.
Anything can be automated. It’s a budget question, not a possibility question.
I believe this genuinely, and it’s worth saying plainly:
The whole world could be automated. The reason it isn’t is that someone has to decide the automation is worth more than the hours and dollars it costs to build. That’s it. That’s the only real constraint. Most “we can’t automate that” is actually “we haven’t decided it’s worth automating yet.”
One hundred and eight items, thirteen sections, and a form designed by people who assumed you’d be adding one burger. That’s comfortably over the line. So I built it.
How it actually got done
I worked out how Google’s form and submission flow behaved, then wrote a Node script using Puppeteer to drive it — filling and submitting each item the way a person would, minus the typos and the growing resentment.
The interesting wrinkle was the anti-bot layer. Google doesn’t love being automated, which is fair of them. The way through was remote debugging, which let the script drive the real browser session instead of getting flagged at the door. A round of fine-tuning later it was working through the whole menu on its own, every section, every item.
The client’s menu was current everywhere it needed to be, same day, as promised.
Was it faster? Honestly, probably not. That’s not the point.
I’ll be straight with you: building the script took about as long as grinding through 108 items by hand would have.
So why do it?
Because the next time a client has 108 of anything sitting behind a form, I’m starting from a script instead of from zero. Because “I didn’t know that system existed” turned into “I know exactly how that system behaves, including the part where it gets suspicious of you.” And because the next version of this problem probably won’t be a one-off, and I’d rather meet it with something already built.
Also, writing automations is more fun than data entry. I’m not going to pretend that wasn’t part of it.
Got a tedious thing eating your week that everyone swears “just has to be done by hand”? It probably doesn’t. Book a blunt audit → and we’ll tell you straight whether it’s worth automating, or whether this is one of the times the by-hand way genuinely wins.
