https://speakerdeck.com/player/1b428230180d4ee58304f9008824058c
Ray has published the full deck on Speaker Deck. Slide references below follow it.
TL;DR
- Agentic engineering removes SEO’s oldest bottleneck. For decades, SEO work waited on product and engineering teams. Migrations, analytics at terabyte scale, and large-scale content planning that took years can now take months.
- Vibe coding and AI-driven engineering are different things. Vibe coding is for prototypes and early user feedback. AI-driven engineering is for products, and what separates the two is deployment and ongoing operations.
- Get “hello world” live before building features. Ray’s Milestone 0 is the simplest possible version running in production, because a product succeeds on how fast it can iterate through automated deployments.
- Tests are the most important thing you build. Every bug found should become a regression test, so it never happens again.
- Don’t become “The One.” The people with the vision end up building everything themselves. Spread the knowledge so more than one person can build.
About the Speaker
Ray Grieselhuber is the founder and CEO of DemandSphere, an SEO and AI search data platform. He comes from an engineering, data science, and machine learning background, with more than 18 years in enterprise and technical search marketing. Before DemandSphere, he built an early enterprise SEO platform at Covario, and in 2015 he co-founded Functionize, an AI-powered test automation platform.
A year earlier, on the same San Diego stage, he had predicted that 2026 would be the year of agents, and he admitted that even he was surprised by how wild things have turned out.
He gave a brief tour of what DemandSphere runs on, which was also the working example behind the rest of the talk: a workflow automation builder, enterprise rank tracking across 200+ markets, brand visibility tracking across AI Mode, AI Overviews, ChatGPT, Perplexity, Gemini and Copilot, real-time log file analysis with AI crawler tracking, a search data warehouse queryable with SQL, and APIs over all of it.
How He Framed the Talk
He set expectations early: today we’re building a map, don’t worry too much about knowing it all. He said he would move fast, start high level and finish technical, and that nobody should expect to follow every detail.
The goal he stated was not to sell anything: promote more fluency in building repeatable systems with AI, and help decision makers understand what it takes to support AI-engineered products. Most of what his team does, he said, is collaborate with other people building in similar ways, and none of them have it fully figured out. The point is to share information and get better.
His deck also makes a point the talk moved past quickly: many of the same engineering principles apply in both product and data engineering. That is the bridge between the title and the content.
The practical reason for it: client teams and decision makers keep asking whether they should build tools internally on top of their data, and in his experience few have the right heuristics to answer that question.
The stated takeaway: a framework to help you build more reliable products.
Ray’s Talks Over the Years
Ray is a brightonSEO regular, and his talks trace how the industry’s questions have changed.
- 2023 to 2024: measuring the SERP. “Measure the whole SERP at any scale” (San Diego 2023) and “Going beyond ‘what happened?’ in SERP analytics” (Brighton and San Diego 2024) were, as the titles suggest, about tracking the full search results page at scale and getting past simply reporting what changed.
- April 2025, Brighton: how AI answers are built. “Exploring relationships between AI answer engines and organic SERPs” explained retrieval-augmented generation (RAG), where AI tools search an index before answering. His data showed about 80% of AI responses relied on Google and Bing indexes, with Perplexity drawing about 55% from Google.
- September 2025, San Diego (repeated in Brighton that October): it’s all AI search. “It’s ALL AI search now: building a unified view for growth” argued that “traditional versus AI search” is a false dichotomy, since Google pioneered much of what we now call AI search. He showed AI tools running 8 to 12 background searches per prompt, and made the case for combining search data into one view.
- September 2026, San Diego: building with agents. This talk moved from understanding and measuring search to building tools and products on top of that data.
The Problem: Product Was Always the Bottleneck
Ray opened with why a talk about building software belongs at an SEO conference. In his view, this year has been exceptional for the industry, because agentic engineering lets teams solve problems that have held SEO back for decades.
His examples:
- Site migrations, including moving to new infrastructure without changing the architecture
- Platform moves, from one CMS or ecommerce platform to another
- Analytics at scale, working with terabytes of data
- Content planning for large ecommerce sites
The common thread is that SEO teams almost always depended on product and engineering, and product was the bottleneck. Not intentionally, but because of how organizations prioritize and how product teams are motivated. That is starting to change.
Ray’s broader framing: good search marketing is good product management, and vice versa. He described search performance as a leading indicator of how well a company is run, from the executive level down.
Context: Service as Software
Ray spent part of the talk on a business idea that explains why this shift matters beyond SEO.
When he co-founded Functionize, the test automation market looked like a tooling business. But the tool companies topped out at modest revenue, which he put at around $20 to $30 million for some and $80 million for others, while a services company in the same space was doing billions in QA engineering and managed QA. Companies weren’t buying tools; they were buying the job getting done.
His conclusion is that SaaS increasingly needs to be thought of as “service as software”: delivering the completed outcome in a programmatic, parameterized way that feels turnkey without being custom-built each time. Processes that used to be human-driven are becoming agent-driven, and that is what makes this model viable.
He also named what he called the dirty little secret in SaaS. VCs dislike consulting revenue, so software companies disguise or outsource it. Salesforce, he pointed out, relies on a huge partner network for delivery. The services were always there.
And a side note that got a laugh: whenever you hear “X is dead,” whether SEO or SaaS, remember that founders are coached to use that phrase in fundraising to convince investors the old thing is over and they are the new thing. You don’t have to adopt the language.
The Solution: Know When to Vibe Code and When to Engineer
Ray was clear that vibe coding shouldn’t be looked down on. It has a specific purpose.
- Vibe coding is for building prototypes and getting user feedback as early as possible. That feedback is the most important thing you can get.
- AI-driven engineering is for building products. A product is something you have to commit resources to, both people and money, to maintain and operate.
The dividing line is deployment and operations. When a team tells decision makers “I can build this,” the right answer is to let them, but also to evaluate honestly what ongoing support and operations will require.
He described the current moment as a Cambrian explosion of new tools and ideas. What survives will be what connects to business goals, and he repeated the point for emphasis: it has to be connected to revenue. The good news is that experimentation, and the cost of getting user feedback, is now far cheaper.
The Workflow: From Prototype to Product
Ray walked through the process his team uses, step by step.
Step 0: Build Your Brand Skills
Before anything else, spend time building your skills for brand, colors and assets, and decide whether the product is public or internal. That decision drives everything downstream.
He recommended a skill called Impeccable, not to use its output directly, but because, as his slide puts it, it shows you what should be stripped to avoid “Claude-isms”, the tell-tale default styling that makes AI-built interfaces look alike.
The Vanilla Prototype
Ask an AI tool for a prototype and it will often build something heavy with a complex React setup that is hard to work with. Ray’s advice is to ask for a lightweight, close-to-static version first, then build on top of it. His slide is specific about what that means: HTML, CSS and vanilla JavaScript.
Pick Your Runtime and Get Feedback
Next, build a simple version in the environment you’ll actually run in. DemandSphere is a Rails shop; Next.js is another common choice. The framework matters less than picking one. Then put it in front of users, even if that’s only you and a few others, before spending real time building.
Get the Spec Written While You’re Still in the Browser
Once you have a working version the stakeholders like, have the same web agent write a full product spec with context before you move anywhere. That spec is what the coding agent works from later.
Move It Local and Plan
Put all of those files into a project folder on your development machine, then:
git init- Create the repository on GitHub
- Connect the remote repository
- Run
claude initorcodex initto generate the context files
Then switch to planning mode and plan the roadmap. Don’t let agents start building without making sure they’re on the right track.
On repository organisation, his slide is explicit: product spec and other docs in /docs, prototype files in /prototype, with rules in your context files ensuring neither ever reaches public view.
Milestone 0: Hello World in Production
Ray’s Milestone 0 is literally a “hello world” page, live in production. The goal isn’t features; it’s getting deployment working first, because the success of the product will depend on how quickly you can iterate through repeatable, automated deployments.
His recommendation for continuous integration and deployment is blunt: just use GitHub Actions to build these. Then three environments:
- Development, where you build
- Staging, which should match production
- Production, deployed automatically once tests pass on staging
Enforce the Testing Policy
This was the point Ray said he hammers home most. He spends a lot of time at the start of every project making sure the agents understand that tests are the most important part of what they’re building.
He distinguished two kinds of testing that are often confused:
- Exploratory testing means trying to break the product. It’s usually done by humans, although agents are getting better at it. This is where problems are found.
- Regression testing means turning every problem you find into an automated test, so it’s fixed and never happens again.
His test suites form a funnel. On a mature project, he described roughly 5,000 to 10,000 unit tests, around 1,000 integration tests, and about 150 to 200 browser tests.
The reason for all of this is speed. The more iterations you can get through, the faster and more reliably you respond to feedback. In a heavy sprint, his team deploys five to ten times a day.
What He Didn’t Have Time For
Worth knowing before you start, because each of these is a decision the framework assumes you have made. His slide listed them as out of scope:
- Database selection
- Host selection
- Cloud versus bare metal
- Object storage
- Logging
- Security and audits
- Team collaboration
- Context file management
- APIs, MCPs, and the security around them
The New Bottleneck: “The One”
Ray’s closing warning was about people, framed with a nod to Neo in The Matrix. Product used to be the bottleneck. Now, the people with the vision for what to build end up building all of it themselves. He said he couldn’t count how many people have told him they were up until 3 a.m. building something new, and admitted he’s done it too, because they can finally build things they’ve wanted to for years.
The risk is that one person becomes “The One,” and the new bottleneck. A company should have more than one, which means spreading this knowledge and training more people to build.
His closing slides gave two instructions rather than a prediction: make the investment to own your own compute capabilities, and learn how to work with open weight models. DemandSphere runs a free tracker for frontier models, with particular attention to the open-weight ones, and he flagged where those models come from as an important topic to watch.
He closed by inviting anyone interested in Japan to FOUND Conf, DemandSphere’s own search and AI conference.
FOUND Conf Tokyo runs 18 to 19 February 2027, in the Tokyo Station area, covering search, AI and digital marketing. The announced speakers so far are Aleyda Solis, Amanda King, Christine Ullmann, Jes Scholz, John Shehata, JP Zhang, Krishna Madhavan, Marco Giordano, Rand Fishkin, Sam Torres and Zach Chahalis, with more to be announced.
The Blueprint
This is his own workflow slide, in his order, with the detail he gave around it:
- Start in Claude.ai, ChatGPT or similar. Build your brand skills first: colors, assets, look and feel, and whether this is internal or public.
- Create the repo.
- Build the vanilla prototype. HTML, CSS and vanilla JavaScript, then a simple working version in your target framework. Show it to users before going further.
- Have the web agent build your md context files, including a full product spec, once stakeholders like what they see.
- Move to the local filesystem and init.
git init, create and connect the GitHub repo, runclaude initorcodex init. Docs in/docs, prototype in/prototype, with rules keeping both private. - Enforce the testing policy. Do this before features, and make sure the agents understand tests are the most important part of what they build.
- Configure the deployment environment. Dev, staging, production, with staging matching production.
- Automate deployments. GitHub Actions is enough.
- Deploy regularly. Milestone 0 is “hello world” live in production. Everything after that is iteration speed.
And alongside it: train other people, so you don’t become the bottleneck.
What Not to Do
- Don’t dismiss vibe coding. It’s the right tool for prototypes and early feedback.
- Don’t mistake a prototype for a product. Without deployment and operations, it isn’t one.
- Don’t start with the big SaaS idea. Start with something simple.
- Don’t accept a heavy default prototype. Ask for a lightweight version.
- Don’t build features before deployment works.
- Don’t let agents build without a plan.
- Don’t fix a bug without adding a test for it.
- Don’t build anything that isn’t connected to revenue.
- Don’t become the only person who can build.
- Don’t adopt “X is dead” language just because it’s everywhere.
Next Steps
- List three SEO problems that have been stuck waiting on your product or engineering team.
- Pick the smallest one and build a vanilla prototype.
- Show it to two or three users before going further.
- If it earns a next step, set up a GitHub repository, a staging environment, and automated deployment before adding features.
- Write a testing rule into your agent’s context files and create a regression test for every bug from day one.
Personal Takeaways
This was the most engineering-heavy talk of my day, and the one I found most directly useful for my own work.
What I’m taking away:
- The vibe coding versus engineering distinction is the right one. I vibe code a lot myself, and it is the fastest way I know to test an idea. What Ray put into words is the point where that stops being enough: once something has real users, deployment, tests and operations are what turn it into a product.
- “Every bug becomes a regression test” is the rule I most want to adopt. We run our own booking platform on Next.js, and most of the bugs we’ve fixed would have been worth locking in with a test so they can’t come back.
- The staging environment matters more with agents, not less. When changes come faster, a place to check them before they go live becomes more important.
- Service as software is a useful lens for consultancies. Ray’s argument that customers buy outcomes rather than tools applies directly to agencies and consultancies that are packaging repeatable work with AI.
- FOUND Conf Tokyo now has dates: 18 to 19 February 2027, near Tokyo Station. A search and AI conference of that size in Japan is worth keeping an eye on, and more speakers are still to be announced.
- “The One” problem is real for small teams. For founder-led businesses, it’s the default. Writing down processes and context files is part of spreading the knowledge, not just a technical step.
- Ray’s talks show where the industry is heading. Over the past few years he has moved from measuring the SERP, to explaining AI answers, to unifying search data, and now to building. The talk was titled “Data strategy & engineering for agentic workflows,” but most of it was about engineering practice, which says a lot on its own. He’s giving the same talk at brightonSEO Brighton in October 2026.
Related Resources
- Talk: Data strategy & engineering for agentic workflows
- Speaker: Ray Grieselhuber
- The full slide deck on Speaker Deck
- Ray’s site, where he links the slides
- My report on Ray’s September 2025 San Diego talk: It’s ALL AI search now
- FOUND Conf Tokyo, 18 to 19 February 2027
- DemandSphere events, including FOUND
Written by Ayaka Uchida
CEO, A-Digital Works
This report covers Ray Grieselhuber’s session “Data strategy & engineering for agentic workflows” at brightonSEO San Diego (16 September 2026).
