Claude Built My Wix Website in 3 Hours -Is SaaS Dead?

Ran Isenberg
2 minutes ago
7 min read

“SaaSmagedon is coming,” they say.

And the stock market agrees.

Every new agentic model ships with better outputs, and fewer hallucinations. With modern tooling like skills, MCP servers, and plugins, AI agents can now generate production-grade code tailored to your preferences and best practices. If you believe the headlines, the biggest barrier to building software is rapidly disappearing.

So instead of debating theory, I decided to test the claim myself.

For the past four years, I’ve maintained my website on Wix. I’m a backend engineer and architect, the kind who avoids writing frontend code unless necessary. My website is nowhere near as complex as something like Monday.com, but that wasn’t the point.

The goal was to test the buy-versus-build customized argument on a smaller, more realistic scale.

Could AI build my website and give me a better experience than Wix?

In this post, I’ll share what I built, what I learned from the process, and why SaaS is definitely not dead — even if the rules are being rewritten.

SaaS is Powerful but Customization is Limited

Many SaaS products are very good, but companies build them for the needs of the many, not the individual. Sometimes a customer only needs a small subset of features, yet still pays for a full platform with capabilities they never use. That is my situation with Wix. It is an excellent product, and overall, I have been a happy customer, but it comes bundled with far more than I actually need. It provides features beyond website hosting, including visual editing, mobile and desktop domain management, CMS, e-commerce, views, event management, user management, and much more. The platform solves many problems well, but I personally use only a fraction of what I pay for. And some features that I actually want, as basic as dark mode, don't exist.

Four years ago, the tradeoff made perfect sense. I preferred spending time creating content rather than building infrastructure or learning frontend development. I am a backend engineer and architect, the kind who avoids writing frontend code unless his life depends on it.

At the same time, the industry narrative has become impossible to ignore. Some claim the barrier to building software has effectively disappeared. Amitay Gilboa, CEO of Spring, recently said they built Monday in 4 hours using their system and argued that, in this new world, vision and creativity matter more than technological knowledge because development resources are no longer the constraint. That is a bold claim, and I was quite skeptical.

Can customers really build customized versions of SaaS products in hours or days and stop paying SaaS providers altogether? Is SaaS actually in trouble?

As someone working at a large SaaS company, CyberArk, now part of Palo Alto Networks, I wanted to test this claim for myself. Instead of debating theory, I tried to replace my Wix website with Claude while having the same or better experience, with one simple rule: I would not write a single line of code. I even named the GitHub repository "wix-wannabe" because I expected the experiment to fail.

It didn’t.

But before the pitchforks come out, let me be clear. SaaS is not dead.

But more on that later. I want to show you how I built my Wix-like experience.

How it Started

Disclaimer: My use case is simple; it does not involve multiple integrations or backend APIs. It's mostly a static website with dynamic content and a Calendly integration. Take my experience with a grain of salt.

I started a new GitHub repository - a greenfield project called "wix-wannabe".

I used the AI-SDLC approach (taken from AWS open source, thanks!) which applies traditional software development discipline with AI: structured prompting, validation, iteration, review, and refinement. The idea is simple: you guide the AI like a junior engineer instead of blindly trusting output.

Don't know what AI-SDLC is? Check out my "AI-Driven SDLC: How to Build Secure, Governed, and Scalable Software with AI" article.

I prompted Claude:

My current website ranthebuilder.cloud is hosted on Wix. Build a modern version hosted on ranthebuilder.io. Scan the site, extract structure and resources, migrate content, use a similar theme, choose the framework, focus on security and performance, and host on AWS using CDK Python with CloudFront and S3. Support mobile resolutions and localhost view of the website. Hosting will be phase two.

And off it went doing its spec coding flow using the AI-SDLC skill.

Now it wanted clarifications to the requirements:

and it kept a local .md file as a state (memory) of all user stories and tasks.

One Hour Later

We went back and forth refining user stories, validating requirements, and clarifying details. I didn’t write a single line of code, I simply put on my product hat.

Within one hour I had:

A working website running locally with mobile resolutions view
Content scraped from Wix
Images and metadata migrated
A modern design
Dark mode working out of the box
Suggested features I never asked for

There were no tests, no deployment pipeline, no security hardening. But it worked.

I stopped and stared at it.

I felt conflicted. It was impressive, but nowhere near production grade. Still, the speed was shocking.

So I continued.

We iterated on design, added security controls, implemented infrastructure as code, and improved SEO. We added tests, refined the UI and improved accessibility.

Three hours later, the system was mostly complete.

The site was faster than my current one and honestly looked better.

The Aftermath

It’s addictive. You imagine something, and it becomes a reality.

The project generated more than 600 files. Reviewing everything would be impossible.

I reviewed the critical parts: CDK, infrastructure, Python logic, but I largely trusted the frontend code; I could do nothing but hope it was fine anyways.

In a regulated environment, handling customer data or financial transactions, this would be unacceptable. But for a personal site where the critical path relies on external integrations (Calendly and PayPal), the risk profile is minimal.

The next day, I pushed further. I added author sections, Playwright tests, SEO optimizations (Thanks, Boaz, for your SEO agent skills), and a GitHub Actions pipeline that lints, builds, deploys, and builds release notes for me.

Every idea I had became a feature almost instantly.

It’s addictive. You imagine something, and it becomes a reality.

Want to add an author sections or guest writers section? Just ask, and the agent complies - you will not understand the code, but it will work.

Within roughly six hours total, I had what I consider a production-ready website.

AWS handles the critical hosting and serving layer, and I kept Calendly and PayPal — because replacing them at their price and reliability makes no sense.

Want to see the current result? Look at https://ranthebuilder.io/ until it becomes my main .cloud site.

What Didn't Go Well

The experience wasn’t perfect.

First, the generated code often required cleanup. I frequently had to ask the agent to refactor or remove redundant Makefile commands and unnecessary code. While the system produces working code quickly, the structure is not always optimal, and keeping the codebase clean still requires human judgment.

Security was another concern. Some issues were obvious to me, others were not. That uncertainty alone is a risk. While the agent can implement security practices, trusting generated code without deep review is not something I would be comfortable doing in a production or highly regulated environment. This approach works well for prototypes, proof of concepts, or less critical systems, but the risk profile changes significantly when real customer data or financial impact is involved.

SEO is another open question. I used dedicated skills to configure SEO and analytics, but how good are those skills really? Are they applying best practices or just approximating them? Without domain expertise, it is difficult to fully trust the outcome.

Maintenance in my case is simple, which is why this approach makes sense. The site is mostly static and low risk. In more complex systems, long term maintainability could quickly become a challenge.

Interestingly, even simple UI changes require a mindset shift. Instead of editing JavaScript or CSS directly, I ask the agent to make the change. It is often faster, but it feels very different from traditional programming. You wait, review, and click continue. This is more about directing a system. But It's also easy to fall into a "just click OK to continue" and cause havoc to your systems.

The development experience itself can also be frustrating. The constant cycle of prompting, waiting, and approving changes is not always smooth. It no longer feels like programming.

Finally, human experience still matters (hurray!). For example, CloudFront traffic can easily generate significant costs if misconfigured. Fortunately, AWS recently introduced flat rate pricing tiers that help protect against unexpected traffic spikes and even DDoS related cost explosions. The agent initially claimed such an option did not exist. This highlights an important point: AI can generate solutions, but it does not always stay current with operational realities or cost implications. Human experience and context remain essential.

Is SaaS Dead?

I did not build Wix in 3 hours. I built my own customized Wix-like experience with a very limited set of capabilities, which is enough for me.

SaaS is NOT dead, repeat after me - not dead.

But the relationship between users and SaaS is changing dramatically.

The barrier to building software has indeed collapsed. Building solutions is easier than ever. Maintaining, operating, and supporting it over time is the real challenge. When someone claims they built Monday in four hours, it's not correct. They built a variation of the features that matter to them and, in doing so, also inherited responsibility for maintenance, operations, and long-term support.

Anton Aleksandrov, a top AWS serverless super-architect and a good friend, smartly said:

Within a year, every company will have 50 AI-generated systems, each delivering about two-thirds of what's expected while introducing years of technical debt. - Anton Aleksandrov,

The other barrier is guiding systems, designing products, understanding users, and ensuring production-grade security, observability, and reliability. AI can generate implementations, but it does not always reason about operational tradeoffs, pricing models, or long-term sustainability. Human experience and context still matter and not everybody can build these application with ease, at least for now.

What we are witnessing is not the end of SaaS but its evolution. Some companies will adapt and offer more customization options, some will shrink, and some may disappear if they fail to respond to this shift.

I'd like to see more SaaS products offer an experience where I can build ad hoc components into their system using their tailored/configured agents that play nicely with their APIs and SDKs, but I, as the customer, define the experience and result.

Will it happen? Who knows. Will developers still have jobs, probably, yes but a different one for sure.