Personalize Connect: Building a No-Code Sitecore Personalize + SitecoreAI Bridge in 24 Hours

Personalize Connect: Building a No-Code Sitecore Personalize + SitecoreAI Bridge in 24 Hours

45 min read
Article

AI-Assisted Proofreading

All articles on this site are written by me. I use AI tools solely for proofreading and editing assistance to ensure clarity and accuracy.

Hello friends, and welcome back to my blog, today I’ll share the journey of my 2026 Sitecore Hackathon, what I built, the journey I had with it, and why I built it. At the end I’ll share a little more about where I hope to take this tool. Now I have to admit, with the announcements from this past years Sitecore Symposium, doesn’t sound like having a standalone version of Personalize will always be a thing, so that’s one reason why I’m planning to not take this core concept any further with Sitecore AI, but I wanted to share what and the why behind my runner up entry at the 2026 Sitecore Hackathon. So with that being said lets jump in and start covering this topic.

The Problem I had been Living With

This whole Sitecore Hackathon submission came about because I wanted to solve a real challenge I and I know others had experienced with the existing landscape (before Sitecore AI existed) with Sitecore Personalize and Sitecore XM Cloud. These two platforms just didn't work well together. Sure, with a Sitecore XM Cloud environment you had the ability to do Page Level personalization, but there were limits with that approach, especially once you had a license for Sitecore Personalize in the mix and you wanted to achieve 1:1 personalization instead of broad audience level personalization. What was encouraged by Sitecore was really two approaches.

Sitecore Personalize Specific Approach

This was probably the more common approach, where you would just use the Web Experience approach in Sitecore Personalize but it had major drawbacks as in what if you wanted to use your content from XM Cloud, in that case you probably would end up with duplicated content or some sort of advanced decision model to query XM Cloud for the content you needed, and then what happens when you are dealing with a new piece of content or that item had different language versions or other complexities, it wasn't a good low or no code approach for marketers. It also wasn't seamless with XM Cloud and you would deal with complexities where maybe you have page level personalization on the page and then this overlay of client-side personalization (after initial paint of the page) showing a different variation of personalization. You could create custom conditions and then use the same page level personalization but there were issues even with that, as there are limitations on the number of conditions or audiences you can use with page level personalization, and any external connection to a third-party system would be impossible. So it worked but wasn't a seamless approach either way.

Pure Custom Wiring Approach

The other approach was to use a Full Stack interactive experience, which is where you can an API to make a decision, and return a result, but this required custom logic per component. This is actually closer to the direction I took with what I built, however I wanted more of a wrapper that handled the complexities for me or for the marketer and didn't require a custom personalization component.

So I kind of knew if the opportunity arose that allowed me to build a solution I would take it. And luckily that was one of the topics for Hackathon. Which I'll share this journey, hour by hour on the build.

In addition I did have a phase two to this approach, which was also handling custom events that a marketer could just attribution to what a component already was, and that unfortunately I never got to for the Hackathon. To tease a project I've been working on recently, and will be sharing more on over the coming months, I've applied that technique. A marketer should be able to do many actions without code, and this is just one example of a gap that existed, well at the time two gaps that existed. Now since the Hackathon, the roadmap to Sitecore AI has shifted this, and with the new personalization capabilities in SitecoreAI alot of what I built is no longer relevant, but the techniques that were used could be useful for future enhancements.

Going Solo — On Purpose

This was my first year competing solo. After 7-8 years of hackathons on teams, I made a deliberate choice to go alone. Not because I don't value teammates, but rather I wanted to see how I could stack up as a solo team member, paired with my knowledge of using AI, so really it was a two man/AI team where AI did a ton of the heavy lifting on this submission. Also I've had some super solid teams in the past, but I've also had not so great pairings also in the past. One of the big negatives with a team is collaboration and communication and trying to consciously put the best developer on the right tasks, could lead to issues. Whereas a solo team, you know exactly what you are capable of, and you also know your own limitations and don't need to worry about wasting time with communication/coordination.

There are however negatives with a solo team, and the biggest is just the drain. Everything is on you to produce. If you hate documentation, then you probably want to find a developer that enjoys the documentation or atleast knows enough with AI to have AI write the bulk of the documentation. It's also quite easy to feel burned out, being that your the only way your going to deliver the result.

But at the end of it all, would I do it again, absolutely, it's greatest seeing what your skills can produce. But does that mean I wouldn't pair up with a team again, absolutely not, I would enjoy working on a Hackathon again.

What I Built: Personalization Studio

Personalization Studio (submitted as "Personalize Connect" during the hackathon) is a Sitecore Marketplace app built with TypeScript and Next.js that provides a no-code interface for configuring Sitecore Personalize advanced decisioning within SitecoreAI (well more so with Sitecore XM Cloud).

The core idea is straightforward: content authors and marketers should be able to set up personalization decisioning directly from the SitecoreAI Page Builder, without writing a single line of code. The app runs as a Marketplace extension, communicating with Sitecore through the Marketplace SDK's postMessage-based query/mutation API.

The Technical Stack

  • Framework: Next.js (App Router) with TypeScript
  • SDK: @sitecore-marketplace-sdk/client for iframe communication with SitecoreAI
  • Extension Points: SitecoreAI Page Builder context panel
  • Integration: Sitecore Personalize decisioning APIs
  • Hosting: Vercel

The Marketplace SDK handles all the iframe sandboxing and secure communication between the app and SitecoreAI. Your app talks to Sitecore through client.query() and client.mutate() — the SDK abstracts the postMessage layer so you're working with a clean API rather than raw cross-origin messaging.

The 24-Hour Build

The hackathon clock started at 8 PM EST on March 6th (actually we had our topics by 7 PM EST). Here's the reality of building a complex integration product as a single person in 24 hours.

Hours 0-4: Architecture and Scaffolding

As I mentioned above, I had strong opinions about what I planned to build and once I saw the topics, I wasted no time thinking about other possibilities and start immediately in hour 0 with Architecture chatting with Claude Desktop. I knew it was going to be a challenge to solve because well Sitecore would've solved it if it was easy. Nothing honestly is impossible, and sometimes if the topic is complex enough having a chat to discuss the architecture with Claude is the best way to refine the planned architecture. Honestly this is why I feel like AI has accelerated my ability to build practically anything, because I can just sit down and work on refining the original specifications and the parts needed to build that architecture. Once I had a general idea of how I was going to build it, then I had Claude Desktop craft the initial prompt to Cursor. I like to use the premier frontier models for brainstorming and then use cheaper models, like Cursors own Composer 2.x to scaffold out that initial design. This is a pattern I use all the time, it also spreads the costs across services. I know some folks go into Claude Code and do everything with a premium frontier model and burn their usage allowance in a few hours, that is not a sustainable model long term.

Hours 5-16: Core Decisioning Integration

This was the hard part — and the part that no amount of AI scaffolding can solve without deep domain knowledge. Wiring up Sitecore Personalize's decisioning APIs, handling authentication flows, building the no-code configuration UI, and making it all work within the constraints of the Marketplace SDK's iframe sandbox.

AI was my pair programmer here. I'd describe what I needed — "build a component that fetches available decision models from the Personalize API and displays them in a selectable list" — and iterate on the output. The speed advantage is real. What would have taken me 2-3 hours to write from scratch, I could direct AI to produce in 20-30 minutes, then refine.

Hours 17-20: Deep Dive into the Page Builder

Getting the Marketplace app to properly communicate with the Page Builder modules was the most technically challenging part. The Page Builder uses a nested iframe architecture, and understanding exactly how the SDK routes messages between your app's iframe and Sitecore's rendering context required reading SDK source code and experimenting with different query/mutation combinations.

Hours 21-24: Documentation, Video, and Polish

This is where going solo hurts. On a team, one person polishes code while another writes the README and a third records the video. Solo, you're context-switching between all three roles. I spent more time on documentation than I probably should have — but clean docs are a non-negotiable deliverable. If judges can't get your project running, it doesn't matter how good the code is.

I submitted with about 10 minutes to spare. The core decisioning integration was working. The app communicated with the Page Builder. The README had screenshots and setup instructions. The video walked through the purpose, setup, and usage.

The Future

Obviously I didn't get a chance to fully build my vision in 24 hours — no one does. The hackathon forced the MVP: a working decisioning integration that proves the concept. But the concept is bigger than what shipped on March 7th.

Given that Sitecore is in the process of phasing out Sitecore Personalize and CDP, I think it’s pretty clear to embrace the new capabilities in Sitecore AI. Which means honestly, I can probably throw away a good chunk of what I built. I did have a stretch goal to build a way to add event definitions to any component, by configuration i

The Competition Landscape

The 2026 hackathon saw 33 teams from 13+ countries. The biggest shift from previous years was the move to TypeScript and Marketplace apps — a direct reflection of Sitecore's platform evolution from monolithic C# modules to composable architecture.

The standout submission was from Sitecorepunk 2077 (Gabe Streza), who built a vibe coding platform for Marketplace apps. It's a tool that uses an LLM to generate Marketplace app code from natural language descriptions — and during his demo, he generated 5-10 test apps to prove it works. The meta angle is brilliant: he built the tool that builds the tools.

Cloud Surfers (Americaneagle.com's team, 2024 winners) built a publishing schedule tool — universally relatable, practical, polished.

My submission sits in a different category. It's not the flashiest demo and it's not the most universally applicable tool. But it solves a real integration gap that Sitecore hasn't closed yet, and it's the only submission that I plan to take to production.

Lessons from Going Solo with AI

What Worked

Zero coordination overhead. Every decision was instant. Architecture choices, naming conventions, file structure, commit strategy — no meetings, no debates, no waiting. When you're vibe coding with AI, the bottleneck is your ability to clearly describe what you want, not your ability to type it.

AI as a force multiplier for domain expertise. I didn't use AI to replace my Sitecore knowledge — I used it to amplify it. I know exactly how Personalize decisioning should integrate with the Page Builder. AI handled the boilerplate, the component scaffolding, and the repetitive patterns while I focused on the hard integration logic.

Tight scope discipline. Solo means you feel the time pressure viscerally. There's no illusion that "someone else is handling the docs" — it's all you. That forces ruthless prioritization. Ship the core integration. Nail the README. Record the video. Cut anything that threatens deliverables.

What I'd Do Differently

Less time on documentation during the build. I should have spent the last 2-3 hours exclusively on docs and video, not polishing docs throughout. The code was done earlier than it needed to be — I could have used that buffer to push further into the feature set.

Find the right partner for next year. Not a three-person team. Two people. Both fast with AI. Complementary domain knowledge. That team ships a complete product with time to spare.

Beyond the Hackathon

Win or lose, I'm walking away from this hackathon with something more valuable than a trophy. Personalization Studio is the foundation of a real product — one that addresses a gap I've experienced on every Sitecore Personalize implementation I've been on.

The hackathon forced the MVP. Now I iterate on my own timeline — stabilizing what's built, expanding the capabilities, and getting it in front of real customers. And when Sitecore eventually ships their native version of this integration (they teased it at Symposium, after all), I'll have deep expertise and customer deployments that make me the go-to resource for migration and optimization.

Stay tuned. There's a lot more coming for Personalization Studio.

That's worth more than a $150 Amazon gift card.