How I Used Two AIs to Build an Astro Site Generator with Laravel

Several months ago, a solo therapist called about a website. I explained our starting cost of around $4,000, plus hosting, maintenance, and software licensing. I could hear the overwhelm in their voice.

For someone who just opened a practice or launched a solo service business, that number is often out of reach. They go to Wix or Squarespace instead. The SEO is thin, the service pages are shallow, and within a year, they’re calling back about a rebuild.

That gap stuck with me. Not the price — the fact that there wasn’t a middle option between “do it yourself and hope” and “pay an agency $4,000+.” I wanted to know if Claude Code could help me build one.

I don’t come from a software engineering background. I started in QA, moved into UX, and spent the last several years on the strategy and product side. I wanted to see how far a disciplined AI workflow could go if I treated it like any other complex project.

What I Was Trying to Solve

I asked Claude Code to generate about twelve different Astro starter templates. Different layouts, color palettes, and structural approaches. I wasn’t expecting finished sites. I wanted to see what it could do with design variability.

It could do a lot. And getting those templates to a shippable state taught me more about using Claude Code than anything I’d read.

Astro has a learning curve if you’re not already comfortable in VS Code or deployment tools. For our team to use these templates with clients, the process needed to be simpler. So the product I started building wraps that complexity. It collects client inputs, handles design selection, and generates a foundational site without anyone touching a terminal.

Twelve templates, a workflow system around them, and a process for using two AI tools to hold it together.

How I Used Two AIs With Different Jobs

I gave Perplexity and Claude Code different jobs. Keeping them separate is what made this work.

I’d been talking to Perplexity about this problem for months before I started building. Not just for research, but as a thinking partner. What does this product do? What does “done” look like for a single template?

Perplexity kept doing that job throughout the build. Before anything went to Claude Code, it helped me decide which template to work on, which problems to fix, what to test, and where to stop. It also acted as a brake. Every time I wanted to tell Claude Code to fix everything at once, Perplexity pushed me back to one small, well-defined task.

That constraint is where the quality came from.

When I told Claude Code to “fix the mobile nav,” it rebuilt the navigation component, changed the breakpoint logic, and added a hamburger animation I hadn’t asked for. The result worked on the surface, but it also changed styling I wanted to keep and introduced a bug where the menu wouldn’t close on resize.

When Perplexity shaped the task first, the output was consistently better. Fix this template. Test these viewport widths. Check keyboard-close and resize-close behavior. Update the log. Then stop.

I have a backlog with over a hundred items. That’s the workflow doing its job — breaking a big idea into small, structured pieces instead of letting Claude Code run at the whole thing and produce something that works on the surface but has problems underneath.

Why I Fixed One Template Fully Before Moving On

My instinct was to work through all twelve templates at once. Perplexity kept redirecting me. Pick one. Get it shippable. Then move on.

That pushback mattered more than I expected.

Every template shared the same structural problems. No mobile navigation — the links existed only in a desktop layout and were invisible on a phone. There were leftover CSS classes from an earlier color palette, a conditional color pattern that didn’t work reliably in our version of Tailwind, and style blocks causing build failures.

Once those issues were fixed on the first template, the second took about an hour. By templates seven and eight, applying the same fixes was close to routine. Every problem caught early made the next build faster and the system easier to hand off.

If I’d tried to fix all twelve at once, I’d have done shallow work across all of them and ended up with twelve different sets of lingering issues. Going slow was the point.

How My QA Background Shaped the Process

The QA instinct came from a specific place. I started at the American Academy of Family Physicians in 2001 on the internet support desk. Because we were closest to the user problems, we naturally became the QA layer. Over time that moved into software development, UX, analytics, and SEO.

One thing stood out from those years. The documentation that was supposed to exist rarely did.

As I worked through the templates, I noticed Claude Code had built a docs folder on its own. QA logs, deployment notes with real measurements, and a template readiness matrix.

There was also a folder called ADR. I didn’t know what that meant and had to look it up. Architecture Decision Records — written context for why a specific choice was made, so you know the reasoning six months later.

None of that appeared because I chased documentation for its own sake. It appeared because I kept asking Claude to QA each template thoroughly and explain what it found. That’s a QA move, not a coding trick.

The instincts from my first job made this build stable. Assume the docs are missing. Ask what could go wrong. Write down the reasoning.

If you’ve worked in QA, UX, tech support, or marketing ops, you’re closer to building something like this than you might think. The mindset is the asset, not the ability to hand-write every line of code.

What AI Got Wrong and Why That Matters

The image upload crash is the one that sticks with me. My partner was the first person besides me to use the system. They uploaded a photo, and the whole thing failed. An 8-megabyte image exceeded the default PHP upload limit. I’d been testing with smaller files and never hit the ceiling.

Claude Code introduced its own bugs, too — Tailwind classes that didn’t compile, an undefined variable, and placeholder syntax issues. I caught them testing by hand. The mobile nav problem lingered longer than it should have because I didn’t test on a phone early enough.

What kept the whole thing from turning into AI slop was simple.

Perplexity shaped the task before Claude Code touched it. Claude handled coding, testing, and documentation inside those constraints. I still ran through the site myself and caught what the tools missed.

That combination works. Take away any one piece and the results get worse.

How to Try This Workflow Yourself

You don’t need to be a software developer to work this way. You do need a clear picture of what “good” looks like and the discipline to work through one thing at a time.

This is especially useful if you work in that dev-adjacent space. QA, tech support, marketing ops, SEO. You can see the shape of a product, but you don’t think of yourself as an engineer. You don’t have to.

Before you touch Claude Code, spend time in Perplexity. Describe what you’re building, the constraints you’re working within, and what done should look like. Use it to pressure-test the idea, think through edge cases, and write a more specific prompt. Vague prompts lead to vague output.

Once you have a structured prompt, hand it to Claude Code. Ask it to explain what it’s doing and update a log or checklist as it goes. If the project has multiple pieces, that log matters more than you think.

Then use what you built. Open it in a browser. Try it on your phone. Hand it to someone else. Most gaps show up fast once a real person pushes on it.

Take what you found back to Perplexity, tighten the criteria, and run the next piece through Claude Code.

The temptation is to give Claude Code a vague idea and let it run. That’s how you get brittle, AI-looking output. The real advantage is running it inside a constrained system — tight prompts, small steps, real QA, and real users finding the edges.

The constraint is where the quality comes from.

The product isn’t finished yet, but the direction is clear. A solo therapist who can’t justify $4,000 could get a well-built site with real SEO, strong page structure, and a design that holds up — for a fraction of that cost. That’s the gap I’m trying to close.

If you’re building something with Claude Code or thinking about it, I’m happy to talk about what worked and what didn’t. Reach out here and let me know what you’re working on.