Two thousand partners in a room, and the most useful forty minutes of the day came from a developer explaining metaobject schemas.
That is not a criticism of the keynote. Tobi's opening was the most confident I have seen him, and the Vercel fireside had genuine range. But the gap between the two halves of Day 2 is the story.
The keynote sold a world where building anything is cheap. The practitioner sessions explained, in detail, why most teams will still spend the money badly.
Both are true. The reconciliation is where the commercial value sits.
Tobi's real argument was about cost curves, not agents
The framing that stuck was deliberately unglamorous.
Previously impossible becomes merely hard. Previously hard becomes easy. Previously expensive becomes cheap.
Read that as a procurement statement rather than a technology statement and it changes what you do on Monday. If a capability shifts from expensive to cheap, every vendor charging you for that capability is repricing whether they admit it or not. Your renewal conversations in the next twelve months are going to look very different from your renewal conversations in the last twelve.
The anecdotes were fun and slightly absurd. He gave Claude access to his UniFi network and it diagnosed and fixed a fault on its own. He pulled his heart rate data against his calendar in DuckDB to work out which meetings were actually costing him something.
Silly on the surface. The underlying point is that the cost of asking a question of your own data has collapsed, and most organisations are still budgeting as though it has not.
The line worth stealing was about systems. You rise to your ambition, but you fall to your systems. Anyone who has run a peak trading period knows exactly what that means, and knows that AI does not change it.
Shopify Catalog is a distribution play dressed as a search engine
The Catalog announcement deserves more scrutiny than it got in the room.
Shopify built a product search engine from scratch in C++ rather than adapting web search infrastructure. The stated reason is that products are not information. Product relevance is contextual: who is asking, where they are, when they are asking, what they bought last. Those attributes are now legible to models in a way they were not two years ago.
The part that matters commercially is where they put the API key. It sits in the Shopify dashboard, surfaced to partners directly. That is not a technical decision, it is a distribution decision.
Shopify is positioning itself as the product data layer that agents query, and it is recruiting the partner ecosystem to make that real before anyone else establishes the standard.
If you sell merchandising, search, or product discovery software into Shopify merchants, your differentiation window on generic relevance just narrowed. Worth pressure-testing your roadmap against that before your next board meeting rather than after it.
River, the internal AI operating system, was the other tell. Seven thousand weekly users, roughly six and a half thousand daily, from a standing start of months. Tobi expects every major lab to ship an equivalent within six months. He is probably right, which means the moat is not the tool. It is the operational habit of using it.
Guillermo's agent-first company is a provocation worth taking seriously
The Vercel conversation opened on audience size. The original Next.js addressable market was ten to fifteen million JavaScript developers. Agentic coding pushes that towards hundreds of millions of people who can now specify software without writing it.
Guillermo said he has not felt this bullish about the web since Next.js launched, and the argument for it is structural rather than sentimental.
The return to fundamentals is the interesting bit. File systems, terminals, open standards. Agents operate happily on the file system, which has quietly rewarded boring infrastructure choices over clever abstractions.
Then the provocation. Future companies will start with the agent that runs the business before they build the website. They pointed at geek.dev as an early expression of it.
Worth noting for anyone scoping this: the vision they described, an agent that notices checkout conversion dropping, runs permutations, recommends a fix and ships it, is not primarily a model problem. It is a permissions problem. They said as much.
Token flow control, access control lists, sandboxed execution, firewall layers. All non-negotiable, all unglamorous, all a line item somebody has to own.
The composability point is the one I would take into a build-versus-buy conversation. Agents can write any software, which does not mean they should write all of it. Reinventing every component is an infinite waste of time even when the marginal cost of code approaches zero. High-quality building blocks still have to earn their right to exist.
That is a healthier standard for vendors than the one the market has been applying.
Shero on migration: discovery is the cheapest insurance you will ever refuse to buy
Beth Shero's session was the counterweight to the whole day, and Shero Commerce's position in the market is worth understanding.
Deep Magento heritage combined with a search-first Shopify practice is an unusual pairing, and it shapes how they read a migration brief in a way most partners cannot replicate.
Her core argument: lift-and-shift manufactures friction. Replicating legacy architecture on a new platform is a square peg in a round hole, because every platform carries opinions about how sites should be built and Shopify's are strong. Start from business process and user journey, then design for the platform you are actually on.
Data migration is where she was most direct, and rightly so. Poor data quality is close to unrecoverable post-launch, and it becomes more expensive as AI systems start consuming that data downstream. Bad product data used to be an SEO and merchandising problem. It is now a model input problem.
Discovery is the same argument in a different form. Skipping it is the most expensive way to save money on a replatform, because the operational processes you missed do not surface in UAT. They surface on day one, in front of the customer, owned by nobody.
Legacy Magento estates in particular are full of unused scripts, mystery tags and features nobody in the current team can explain.
The stakeholder section is the one most scoping documents get wrong. Internal IT usually selected the incumbent platform. A replatform can read as a verdict on that decision, and handled without care you alienate the exact group that has to support the new environment for the next five years.
Shero's approach is to bring them in early, hand them ownership post-launch and train them properly on Shopify admin. Do that and they advocate. Skip it and you have a permanent internal opponent with technical credibility.
The same logic applies to merchant team training. Untrained teams on go-live day produce pushback that gets recorded as a platform failure rather than a scoping failure.
Integrations are the operational floor. ERP and WMS failures do not degrade the experience, they stop the business trading.
The upside is that many legacy estates are still moving data by manual CSV, which makes the automation case easy to put in front of a finance stakeholder with a headcount number attached.
PIM earns its place when a brand runs multiple sites, multiple teams and genuinely disparate systems. Below that threshold the overhead rarely pays back inside a reasonable horizon.
Michal's decision framework is the most immediately useful thing from Day 2
Michal from CommerceUI made the case for native-first Shopify builds, and he made it with schemas rather than slides.
The frustrations he named are ones every ecommerce director recognises. App subscription costs that compound quietly, the performance tax of third-party scripts, and a roadmap held hostage to somebody else's release cycle.
His principle: keep data and logic inside Shopify, because going outside to an external database, middleware or an app always carries a cost.
The configurator case study was the proof. A B2B brand with 35 years of trading, highly configurable products, bundle pricing and tiered customer group logic. Rather than build an app, he modelled the whole thing as a data structure in metaobjects.
A configurator object referencing the product, a preset product handling the split between preset and custom paths, and options referencing variants with metadata for required, optional and active states. Clean server-side rendering, no performance penalty, and it works across B2B, markets and channels.
He also merged multiple configurable line items into a single cart entry, which is the kind of detail that only comes from watching real customers get confused.
The jewellery brand used the same approach for a necklace configurator with live preview, modelled as a relational table and rendered programmatically rather than pre-generating permutations. Then a custom drag-and-drop layer on top so non-technical merchandisers can run it without a developer.
That last part is the commercial unlock. Configurator projects usually fail on maintenance cost, not build cost.
The onboarding example showed where the line sits. Fifteen customer groups, form-based verification, scheduled re-verification via Functions with Slack reminders and checkout blocking until complete. Too complex for Flow alone, so a lightweight API layer for validation and handoff. Not an app. A thin edge.
His framework is three questions, in order.
- Can you solve it as a data problem? Use a metaobject.
- Can you solve it with logic? Use Functions or a metaobject as a config layer.
- Only build a custom app when neither applies.
Go headless mainly when the merchant already has a customer portal or systems requiring genuine integration.
Run your current app stack through that sequence and price the difference. For most mid-market merchants the recurring subscription line is larger than the one-off cost of building the equivalent natively, and it does not stop.
The takeaway
The keynote said building is getting cheap. The practitioners said the expensive parts were never the building.
Discovery, data quality, internal politics, integration, and the maintenance burden of everything you bolt on. None of those got cheaper this year.
What changed is that the cost of the code around them fell far enough that the discipline of deciding what to build now matters more than the ability to build it.
Cheap construction raises the cost of a bad decision, because you will make more of them faster.