Claude Generated 50 Websites Overnight. Prisma Compute Helped Ship Them.

Ali Fatemi gave Claude the Prisma docs and CLI, then used Prisma Compute to turn generated websites into working URLs.

Ali Fatemi left an AI outreach system running overnight.

By morning, Claude had generated roughly 50 websites for spas in Vancouver.

Each site was part of a larger workflow: find businesses in a target market, check whether their website exists or needs work, research the business, generate a custom site, ask Ali for approval, deploy it, and prepare an outreach email with the live URL.

The interesting part is not just that AI can generate the sites. It is that the agent can move from generated code to a working URL without Ali turning deployment into a separate project.

Prisma Compute gave Ali's agent a deployment path it could actually operate: docs, CLI commands, terminal output, and a working URL.

That is the story: AI can make software feel cheap to create, but generated code only becomes useful when it can run somewhere. For this workflow, Ali said getting to a working URL felt easier than Railway.

What Ali is building

Ali runs a boutique software agency and has been experimenting with AI agents as a new way to build and sell software. His current project is an outreach system for agencies and service businesses.

Instead of sending a generic cold email, the system creates something useful first.

The flow looks like this:

• find businesses in a specific segment and location
• evaluate which ones have no website or an outdated one
• research the business and generate a relevant angle
• create a website tailored to that business
• ask for approval or changes
• deploy the site
• write the outreach email with the live URL

Ali described the message as something closer to: "I noticed your business does not have a great website. I created this free version for you. Check it out."

The product is still early, but the workflow already changes the economics of outreach. If AI can create a useful asset before the first email, the outreach can start with proof instead of a promise.

The deployment loop

For this workflow to be useful, generated websites have to become shareable quickly. A static mockup is not enough. Ali needs a real URL that a business owner can open, review, and reply to.

That is where Prisma Compute became part of the loop.

Ali gave Claude the Prisma docs, asked it to install the Prisma CLI, and let it create the deployment script. The generated websites were deployed to Prisma Compute, with many generated pages living inside one Prisma app.

For Ali, the important part was not a dashboard tour. It was that the agent could use the CLI, deploy the app, and get a working URL.

This is one reason Prisma Compute matters for AI-built software. Agents are already comfortable reading docs, installing CLIs, running commands, and iterating on output. The hosting layer should meet them there.

Why Prisma Compute fit the workflow

Ali's strongest comparison was not a benchmark. It was the lack of ceremony. He described the setup as simple enough that Claude could almost one-shot it. (He also said getting a working URL felt easier than Railway.)

The biggest difference was getting from account creation to deployment.

That matters because the bottleneck in Ali's product is not whether an AI agent can produce another version of a website. It is whether the whole system can keep moving:

• generate the site
• deploy it
• review the live result
• improve the prompts
• run the next batch

Prisma Compute gives that loop a default path. The app can be deployed with the CLI, the deployment gets a URL, and the database can live close to the app when the workflow needs state.

As Ali put it, having the database and deployments close to each other is helpful. The outreach system is generating websites today, but the next step is deploying the generator app itself so it can run without his laptop staying open.

Why this matters for agents

AI coding agents made it easier to create software. But every generated app still has to survive the same handoff:

• where does it run?
• where does state live?
• how does the agent deploy changes?
• how does it inspect failure output?
• how does it get back to a shareable URL?

If those steps require jumping across vendors and dashboards, the agent loses context and the human has to stitch the workflow back together.

Prisma Compute reduces that stitching. It gives builders and their agents a place to deploy TypeScript apps, connect them to Prisma Postgres when needed, and keep the work inside a toolchain agents can operate.

That is especially important for products like Ali's. The product is not one website. It is a system that can create many versions, test many prompts, and ship many small deployments.

From generated software to useful software

Ali's strongest reaction was not about a single feature. It was about the end-to-end workflow becoming real.

That is the shift Prisma Compute is built for. Builders can ask an agent to create software, then give that agent a practical path to deploy it.

For Ali, that means moving faster on the product itself: better prompts, better generated sites, better approval flows, and eventually a version that other agencies can use.

For Prisma, it is a concrete example of where app hosting is going. AI agents need infrastructure they can operate. Builders need infrastructure that does not slow the idea down.

Prisma Compute sits in that handoff: from generated code to a working URL. And it does not sit there alone. The same project gives an agent Prisma ORM to model the data, Prisma Postgres to store it next to the app, and one CLI to operate all of it. When Ali's outreach system needs to remember which businesses it has contacted and what it deployed for them, that state has a place to live in the same loop.

If you're building with agents, start with Prisma Compute from the quickstart, give your agent the Compute docs and the CLI, and let it ship.