ReviewPing Is an Experiment in the Part of AI Startups Most Builders Still Ignore
I built a small SaaS to learn GTM strategy and agentic engineering in the same live loop.
Most people building with AI are still spending their courage in the safest place possible.
They are using AI to write code faster.
That is useful. I do it too. But it is also the easiest place to stay comfortable. The codebase is controlled. The feedback is local. The tests either pass or fail. You can feel productive without ever confronting the harder question: can you build a system that helps you find customers, reach them cleanly, and learn what actually converts?
That is the part I wanted to get better at.
So I built ReviewPing.
On the surface, it is a small SaaS. It creates claimable review pages for local businesses, gives them a clean link, and makes it easy for an owner to take over the page.
But the product is not really the point.
The point is that ReviewPing gives me a live environment for a real experiment: what happens when you treat GTM the way I have been treating engineering — as a system that can be operated, measured, and improved with agents?
This Is an Experiment, Not a Win Story
I want to be clear about the stage this is in.
I have set the system up. I have not really started the campaign yet.
That makes this more interesting to me, not less.
A lot of writing about AI systems happens after the author already knows the ending. They know what worked. They know what the graph means. They know what the takeaway is supposed to be. That is useful, but it also hides the uncertainty that actually defines the work.
ReviewPing is more honest as an experiment than as a case study.
I know the system design. I know the loop I want. I know what evidence I plan to trust. What I do not know yet is whether the loop will hold up under contact with the market.
If the site now looks like a field journal, this post is one entry in it: the setup before the result.
The Part Most AI Builders Still Avoid
I think a lot of AI-native builders are getting trapped in a shallow version of leverage.
They let AI write the app.
They let AI generate tests.
They let AI refactor the codebase.
They let AI plan the feature, open the PR, and maybe even write the docs.
But they still want to do GTM by hand.
Or worse, they quietly avoid GTM and pretend product velocity is a substitute for traction.
It is not.
Shipping faster without a better learning loop around distribution just means you can build the wrong thing more efficiently.
That is not progress. That is acceleration without steering.
The real question is not whether AI can help you code. Of course it can.
The harder question is whether AI can help you operate the outer loop around the product: targeting, asset creation, outreach, measurement, iteration, and pattern recognition.
That is what I built ReviewPing to test.
ReviewPing Is Really Three Systems
The architecture is intentionally simple.
There are only three layers that matter.
1. ReviewPing MCP
This is the action layer.
Claude can use it to:
- search Google listings
- create live claimable pages
- upload logos and cover photos
- update unclaimed pages
- regenerate claim links
- sync contacts
- send outreach
- fetch campaign metrics
This is where the work happens.
2. Resend
This is the delivery layer.
I do not want Claude rebuilding email infrastructure every session. ReviewPing wraps Resend so contacts, metadata, and campaign context are handled consistently. If delivery is messy, the learning loop gets poisoned fast.
3. PostHog
This is the learning layer.
This is where the system becomes more than outbound automation. PostHog tells me which verticals claim, which metros convert, which subject lines create movement, and which batches deserve another round.
Short version:
- MCP runs the campaign
- Resend delivers the message
- PostHog decides the next move
That is the actual product.
Not the page builder.
The loop.
claude mcp add --transport http reviewping-admin \
https://www.reviewping.app/api/mcp \
--header "Authorization: Bearer $REVIEWPING_MCP_API_KEY"
Most GTM Systems Rot Because They Worship the Wrong Metric
One thing I already believe strongly: most outbound systems get stupid because they optimize for the easiest number to move.
Open rate is the classic trap.
Click rate is slightly better, but still dangerous.
Those are weak signals. They measure curiosity, not proof of value.
For ReviewPing, the evidence hierarchy needs to stay brutally simple:
- Claims
- Review-page visits
- Google tap-throughs
- Email clicks
- Email opens
If a business owner claims the page, that matters.
If they use the page, that matters more.
If customers actually tap through to Google, now the product is doing real work.
Everything else is secondary.
create pages
send outreach
measure claims
keep the winners
kill the losers
That is one reason I like this experiment. It forces me to build around harder evidence. I cannot hide behind engagement. Either the page gets claimed or it does not. Either it gets used or it does not. Either the outreach pattern creates movement or it is just another tidy spreadsheet of activity.
The Boring Part Is the Strategy
A lot of the real leverage in this system comes from things that sound boring.
Every page should carry a vertical and a metro when known. Every send should carry a sequence_step. Every batch should stay narrow enough to compare. Every contact should be synced cleanly before broadcast.
That is not admin work. That is the strategy.
If the metadata gets sloppy, the conclusions get sloppy.
If the batches are too broad, the signals blur.
If the sequence context is inconsistent, follow-up performance becomes meaningless.
This is the kind of structure many builders skip because it feels tedious. But tedious structure is what turns random outbound into a real experiment.
ReviewPing only works if the system stays legible enough to answer simple questions later:
- Which vertical claimed best?
- Which metro claimed fastest?
- Which subject line produced claims, not just opens?
- Which follow-up step actually moved someone forward?
- Which pages were claimed but never really used?
If I cannot answer those questions, I do not have a GTM engine. I have a pile of actions.
The rule I care about most: if AI only improves implementation, the founder is still the bottleneck for distribution.
Why This Is Also an Agentic Engineering Project
The deeper reason I am interested in ReviewPing is that GTM is a much harsher test of agentic systems than software implementation.
In engineering, it is easy to lie to yourself. The code compiles. The tests pass. The feature ships. You can mistake internal coherence for external truth.
GTM is less polite.
The market does not care that the prompt was elegant.
It does not care that the MCP tools returned 200s.
It does not care that the automation graph looked impressive.
The batch either works or it does not.
That makes ReviewPing a clean environment for learning what agentic engineering actually requires.
It requires boundaries.
Claude can create and update unclaimed pages, but it should not impersonate an owner. It can regenerate a contaminated claim link, but it should not use that as an excuse to cover for weak targeting. It can improve copy, but it should not confuse opens with success. It can help me move faster, but only if the system remains trustworthy and measurable.
That is agentic engineering in the real world.
Not just giving the model more freedom, but giving it a real operating surface, defining the rules clearly, and wiring the system so outcomes can improve future behavior.
What I Want to Learn Before I Scale It
The nice thing about calling this an experiment is that it forces me to say what I am actually trying to learn.
Right now, I care about a few specific hypotheses:
- A prebuilt, claimable page plus a clear email will outperform a plain cold pitch.
- One vertical and one metro at a time will teach me faster than broad blasting.
- Claims will tell me more than opens within the first week.
- Follow-up sequences matter, but only after the page and the first message are trustworthy.
- If the agent makes the system noisier instead of clearer, I should tighten the loop before I scale the volume.
Those are not product features.
They are experimental bets.
What Good Looks Like
A good ReviewPing session is not one where a lot happened.
It is one where the right things happened.
- a clean batch of pages was created
- contacts were tagged correctly
- outreach went out with one obvious CTA
- the funnel became measurable
- one concrete learning survived into the next batch
That is the bar.
Not more dashboards.
Not more activity.
Not more automation for its own sake.
Just one more loop where the system got slightly better at finding what actually works.
That is why I built ReviewPing.
Yes, it is a SaaS.
But more importantly, it is an experiment. A way to get better at the part of AI startups that still resists clean abstraction. A way to practice GTM with the same seriousness I have been bringing to engineering. A way to test whether an agent can help operate not just the product, but the path from product to customer.
I have not proven the system yet.
That is fine.
This entry is not the result.
It is the setup.