From Prompt to URL: the Magic Behind Magic
By Diego Castaneda and Joshua Bochu
Earlier this year, something shifted at Wealthsimple. Across the company, we saw more and more people using AI to generate working code through conversations with LLMs. Not just engineers, but designers, marketers, operations, the people team and more. They were tackling real problems by building prototypes, dashboards and internal tools.
But it had nowhere to go.
A vibe-coded artifact lives and dies in the chat window. You can copy it into a file, but then what? You need hosting on a domain, and maybe authentication if it's internal. The gap between "I made a thing" and "my team can use this thing" was still full of the same infrastructure friction as always.
We were watching dozens of useful tools get built every week and then vanish into chat history. The problem wasn't building anymore. The problem was publishing.
So we built Magic, a publishing platform that creates the simplest path from generated code to a live URL.
How It Works: MCP as the Interface
Magic speaks MCP, the Model Context Protocol that LLMs use to interact with external tools. Any AI assistant that supports MCP can deploy to Magic natively, as part of the conversation.
You don't switch contexts. You don't copy files. You don't run deploy commands. The LLM builds your app and ships it in the same breath. The conversation is the development environment.
In practice it looks like this: you describe what you want and the LLM generates the code. It calls Magic's MCP tools to publish the files and you get a URL. The whole loop, from idea to live site, happens without leaving the chat.
MCP shows up on both sides of this. At build time, the LLM uses it to deploy files. At run time, the apps themselves can call tools through the same protocol, with the user's identity attached. So the same mechanism that ships the app also powers what the app can do.
The MCP surface is deliberately small, featuring five tools:
- Upload files
- List what's there
- Read a file
- Delete
- Manage storage
That's the entire API, and the LLM figures out the rest. A constrained tool surface turns out to be a feature, not a limitation, because models work better when there are fewer choices to make.
For those who prefer it, there's also a CLI where running magic init scaffolds a project. The magic server gives you local hot reload and then magic deploy pushes it live. For some people, they start in chat and graduate to the CLI when a project gets more complex, but both paths lead to the same place.
The Constraint That Enables
Magic is a static site platform. You give it files (HTML, CSS, JS) and it gives you a URL only Wealthsimple employees can reach, protected by a Content Security Policy. Since everyone is already authenticated, we didn't need to build access controls or approval workflows on top.
We already had a service that brokers identity across all our AI tooling. When the LLM calls a tool on your behalf, or your app calls a tool at runtime, the request carries your identity through the same gateway. We didn't build auth for Magic; it inherited it. That's why zero-config works without being reckless. Every action is attributable to a real person, through infrastructure that existed before Magic did.
What You Get
Magic gives every app a small, fixed set of capabilities without requiring any backend infrastructure:
- Storage — persist data scoped to the app and the user viewing it. Each visitor gets their own namespace automatically, so a tool can store preferences or state per person without any user management code
- AI — call language models and image generation directly from client-side code, no API keys needed
- Identity — know who's using your app instantly, because the platform already does
- Tools — access internal systems through the same authenticated context
When your site is served, Magic injects these APIs automatically. There's nothing to import, no packages to install and no configuration file. The platform makes them available to every app by default. Here’s what it looks like:

A handful of building blocks cover a surprising amount of what internal tools need. API keys live on the server and auth is handled by the platform. The Magic user doesn't need to think about any of it.
What It Unlocked
Recent advancements in AI have made it possible for people across every discipline to generate working applications from a prompt. Magic and MCP make that possible at Wealthsimple. Today, 25% of Wealthsimple employees have published a Magic site, and those sites have collectively seen more than 50,000 visits.
Some examples:
- A designer built an interactive prototype to pitch a new feature. Not a mockup, but a working app colleagues could click through and leave feedback on.
- The operations team built a dashboard pulling live data they'd previously waited weeks to get through an engineering request.
None of these required tickets, sprints, or infrastructure requests. With the friction gone, people just built things.
We built Magic because the hard part of shipping internal tools wasn’t building them, it was everything around building them. It turns out there’s a big opportunity in how we approach deployment. By optimizing the path to production and enforcing strong controls around data access, we can move quickly without compromising on security. The goal is to make building faster and easier while ensuring we’re always operating on a foundation of trust.
Interested in working at Wealthsimple? Check out the open roles on our team today.
.png)