AI Builder Test

I gave an AI website builder my portfolio brief and a hard stop on patience. It got me 80% of the way in minutes—until closed codebases, paywalls, and deployment handoffs broke down. Here’s why I scrapped it, rebuilt from scratch, and what actually shipped.

Every few months a new AI website builder promises the same thing: describe what you want, get a finished site, skip the build entirely. I wanted to know if that promise holds up for something real, not a demo, so I used one to build my own portfolio site, martingeorgiev.xyz.
I wasn’t trying to prove AI builders wrong. I was trying to save time. What follows is what actually happened – the parts that worked, the two places it broke, and the decision that got the site live anyway.

The Build

I started in Hostinger’s AI website builder with a simple brief: a one-page personal site, fast, clean, functioning as a digital business card rather than a full web app. No blog, no forms, no store – just enough to say who I am and point people at my work.
To its credit, the first pass was fast and it looked good. Within minutes I had a structured one-pager – hero, a short bio, a work section, a footer – that didn’t need a redesign to be presentable. If your ambition stops there, the tool does its job.
Mine didn’t stop there. I ran out of credits partway through refining it, which is the point most people either pay up or accept what they have. I did neither. I decided to take over by hand.
Document outline Folded corner flap Centered “X” mark

The First Wall

I connected Claude to keep editing the site directly, on my own knowledge of how a build like this should work. The first one or two changes went fine. Then I needed something the builder’s own environment wouldn’t allow: a new file.
The AI builder’s output wasn’t a normal, editable codebase – it was a closed structure that assumed I’d only ever come back to its editor, not mine. Claude could see the site. It could edit what existed. It could not extend it. That’s not a Claude limitation, it’s a builder limitation: the moment you leave its walled garden, you’re not editing a website anymore, you’re negotiating with one.
An AI website builder isn’t a shortcut to a codebase. It’s a replacement for one – and it only works as long as you never need to leave it.

Starting Over

Patching around a wall like that is how projects quietly die – another hour here, a workaround there, until you’ve spent more time fighting the tool than you would have spent building without it. So I didn’t patch it. I rebuilt the entire site from scratch, deleted the AI-builder version from Hostinger and uploaded the new one myself.
That’s the least interesting-sounding decision in this whole story and the most important one. Nobody hands out credit for “I started over,” but it’s usually faster than it sounds, and it’s always faster than the alternative of a project that never quite gets unstuck.
SEE IT FOR YOURSELF
The live result
Built the second time, the way I actually wanted it – martingeorgiev.xyz.

The Second Wall – Deployment

Rebuilding the site was the easy half. Getting it live was the second wall. I connected Claude to Hostinger through their MCP integration to handle deployment automatically – push the build, let the automation put it live, no manual steps.
It broke on the destination step. The automated deploy couldn’t resolve properly where the files were supposed to land, and no amount of retrying fixed it cleanly. Automation is only as strong as its weakest handoff, and this was it.
So I did what the automation couldn’t: uploaded the files by hand, redeployed manually, checked it, redeployed again. Not elegant. Live.
The lesson wasn’t “don’t automate deployment.” It was: know your manual fallback before you need it, because automation fails exactly when you’re least prepared to fix it by hand.

The Logo Call

With the site live, I wanted a logo mark instead of just a text wordmark. I had an idea, found a font that matched it well, and used it as-is. I didn’t spend an afternoon in Illustrator refining it into something more custom, because that afternoon wasn’t worth more to me than a site that was already done.
It’s a small decision, but it’s the same one running through this whole project: ship the version that’s good enough to represent you honestly, and treat “perfect” as a later problem, not a blocker. I may revisit the logo down the line. I won’t pretend I haven’t shipped it as-is in the meantime.

What Actually Ships

The finished site is deliberately small. One page, almost no functionality, built to work like a digital business card: say who I am, show the one project worth showing, get out of the way. It doesn’t need a blog or a contact form to do its job, so it doesn’t have one.
KEY TAKEAWAYS
AI builders are genuinely fast for the first 80 percent of a simple site – if your ambition stays inside what they’re built for, that’s a real advantage, not a gimmick.
The moment you need something the builder’s own editor doesn’t support, you’re not extending a codebase, you’re negotiating with a closed one. Know that going in.
Automated deployment needs a manual fallback you’ve actually thought through, not one you improvise while the site is down.
A fast, honest, finished result beats a perfect one that’s still stuck in the editor.
Have you hit the edge of what your website builder can actually do?

And if your deployment automation broke right now, would you know how to finish the job by hand?

Want a second pair of eyes on your own build?

AI-assisted or not, that’s literally what I do for a living.

Expert insights, delivered!

Stay informed with the latest updates and exclusive resources for high-growth teams. Reinforces professional authority and the "Trusted by teams" badge.