We Started spec2web in December 2025.
Here’s the Exact Moment It Became Obvious.

The Client Call That Started Everything

In December 2025, a client showed me their new website.

They’d built it with AI. One prompt, maybe two. Under an hour from blank screen to something that looked genuinely professional — clean layout, real copy, working navigation. Not a prototype. A production site they were ready to put their business name on.

I was impressed. I’ve been building software for a decade. I know how long this used to take. What they showed me in that call would have been two to three weeks of work in 2019. They’d done it in an afternoon.

Then they asked: “How do I add a blog?”

We went back to the AI. Re-opened the session. Re-explained what the site was, what stack it was running on, what the folder structure looked like. Got the blog working — mostly. The styling was slightly off. We fixed that too.

Then: “Can we add WooCommerce for the three products we sell?”

Another session. More context-setting. The AI built out a product page. It worked, but it broke the navigation. We fixed the navigation. The product images didn’t load. We fixed that. Two hours later, we had WooCommerce running.

Then, a week later, an email: “Can you just change this one line of text on the homepage? The price changed.”

One line. One price. And the only path that existed was to go back to the AI, re-explain the entire context of the site, make the change, and hope nothing else broke in the process.

That’s when I understood what was missing.

Not missing from the AI. Not missing from the client. Missing from the entire ecosystem that had just democratised web building for millions of people worldwide.

There was no visual layer. No way for the person who owns the site to simply open it, find the element they want to change, edit it, and be done. No interface designed for the non-technical business owner who built their site in an afternoon and now just needs to run it.

The AI had solved the build — completely, genuinely, irreversibly. It had not solved the morning after.

That conversation in December 2025 is why spec2web exists.

Before We Go Further: Who We Are and Why That Matters

There are a lot of “AI-native” products being announced right now. Most of them were started by people who saw the wave in 2024 and paddled toward it. I don’t say that as a criticism — the timing is correct — but it matters for how you evaluate what anyone building in this space is telling you.

My co-founder Tiran and I have a different starting point.

We ran a software studio — Beta Launch — for nine years. Forty people. Clients in five countries. We shipped more than 120 products across industries: USAID contracts in the development space, a ride-hailing platform in Sri Lanka, fintech work in the Netherlands and Australia. Real software. Real delivery. Real consequences when things went wrong.

We were good at it. The business worked. And in 2022, we shut it down.

Not because it failed. Because we could see — clearly, three years before most agencies admitted it publicly — that the model was becoming the wrong model. AI was going to collapse the economics of custom software development faster than the industry expected. A two-person team with the right toolchain would outcompete a forty-person agency on the dimensions that mattered most to clients: cost, speed, and honesty about what was actually being built.

We didn’t want to be the agency that kept selling the old model until the clients stopped buying. So we stopped first.

That decision gave us two things: time to build specshop.dev as a lean, AI-native studio before the market caught up to what we already knew — and nine years of pattern recognition about what actually happens to software after it gets shipped.

Which brings us back to December 2025, and the gap that conversation exposed.

The Build Era Is Over. Most People Haven’t Noticed the Implications Yet.

The numbers are no longer ambiguous.

Platforms like these have done something genuinely remarkable: they turned web development from a specialist skill into something a non-technical founder can do in an afternoon. A restaurant owner can build a site that would have cost £3,000 from a web agency in 2020, and do it for nothing, in an hour, without touching a line of code.

That shift is permanent. The question is what it left behind.

Here is what the morning after looks like for most of them. The business owner wants to update an opening time. They go back to the AI. Re-open the session. The AI doesn’t remember the site — it has no persistent memory of what was built. They paste in the context. The AI makes the change. Redeploys. Hopefully nothing broke.

They want to add a product. Same process. More context. More re-explaining. They want to know why their site isn’t appearing in Google. They don’t know what Search Console is, much less how to connect it or read it. They want to connect their Stripe account. They open a browser tab, find a tutorial, get confused, and either abandon it or pay someone £150 for thirty minutes of work.

None of this is a build problem. It is an operations problem. And the tools that built the site were never designed to solve it.

The Vibe Coding Hangover: Why the Industry Knew This Was Coming

The critics of vibe coding — the term coined by Andrej Karpathy in early 2025 to describe building software entirely through natural language prompts — have been making a specific and valid point since the tools launched.

The concern isn’t that the build quality is poor. The concern is what comes after.

Fast Company named it the “vibe coding hangover” in September 2025: the moment when the prototype works, the founder is excited, and then the realities of production, maintenance, and iteration arrive. Senior engineers cited “development hell” when trying to work with AI-generated codebases that nobody fully understood.

More pointedly: investors from Footwork VC made the same observation — that vibe coding startups “excel at developing prototypes but struggle to enable users to launch production-ready software.” This isn’t a fringe view. It’s being named in the mainstream tech press because it’s what’s happening, at scale, to real users every day.

And there’s a specific version of this problem that applies to non-technical users. A developer who used Lovable to build a prototype can, if needed, open the code in a proper editor, understand what was generated, and maintain it. A non-technical founder who built their site with Bolt or Claude does not. They can’t open the code. They can’t navigate a file tree. They don’t want to know what a diff is. They just want to change the price on the product page without breaking the navigation.

For that person, the gap isn’t about AI quality or developer tooling. It’s about having no visual interface for the website they own.

That’s who spec2web is primarily designed for.

What We Actually Built: spec2web, Explained Simply

spec2web is an open-source, locally-installed application that sits between any AI-built website and the people responsible for running it.

Here is what it does, in plain terms.

You install it once. It runs on your machine. Not a cloud platform. Not another SaaS subscription. A local application, like VS Code, that you open and run. Your files live on your computer, in your own Git repositories, connected to hosting providers you already use. Nothing is locked into a platform that can change its pricing or terms.

You open a project and see your site. A live preview loads alongside your file tree. You can see exactly what the site looks like — not a wireframe, not a component library, the actual site.

You click any element to find and edit it. Click a headline. spec2web highlights the corresponding HTML block. Edit it directly in the editor pane. The preview updates in real time. You see what you’re changing before you deploy it.

You review the diff and deploy in one step. spec2web commits the change to your GitHub repository with an auto-generated commit message, triggers a redeploy on Vercel, Netlify, or Cloudflare Pages, and it’s live. No terminal. No command line. No explaining anything to an AI.

Integrations are added in logical groups, each with its own setup wizard. Connect Google Search Console: see keyword impressions and indexing status alongside the editor — not in a separate dashboard, in context. Manage your robots.txt in plain language. Connect WooCommerce, Stripe, PayPal, or eBay — your commerce data in one place. Each integration deploys independently. A broken PayPal connection doesn’t affect your Stripe deploy.

The WordPress Parallel: This Has Happened Before

The most useful frame for understanding where spec2web sits in the ecosystem is WordPress.

Before WordPress, if you wanted to add a blog post to your website in 2003, you either edited HTML directly, paid a developer, or used a clunky proprietary CMS that cost thousands of dollars. The person who built the site and the person who ran the site were different people, separated by a wall of technical complexity.

WordPress tore down that wall. It gave non-technical owners a layer they could operate themselves — and gave developers a platform to build on top of. That combination created an ecosystem that still powers nearly half the internet, more than twenty years later.

The web has changed. AI tools have produced a new generation of websites — built faster, by more people, with more variety in stack and framework than WordPress ever had to accommodate. And the same gap has reopened: between the person who built the site and the person who runs it.

That gap is what spec2web is designed to fill. The same role WordPress played. Updated for 2026.

Why Open Source? Why Local-First? The Decisions We Made Deliberately.

These were not technical defaults. They were strategic choices, and they’re worth explaining.

Open source, MIT licence, no exceptions.

The people who would benefit most from spec2web have often been burned before. They’ve paid a developer who disappeared. They’ve built on a platform that changed its pricing. They’ve been locked into a tool they can’t leave because their data is inside it.

The only way to credibly say “we won’t do that to you” is to let anyone read the code. MIT licence means you can self-host it, fork it, build on top of it, and white-label it without asking us. There is no bait-and-switch coming. If Tiran and I get hit by buses tomorrow, the code is still there and the community can keep building.

Local-first, not cloud-first.

The instinct in 2026 is to build everything as a SaaS — monthly subscription, cloud-hosted, everything managed. We understand the appeal; it’s where the recurring revenue lives.

We built local-first because of who our users are. A non-technical business owner who manages their own website doesn’t want another cloud platform with another login, another monthly charge, and another set of terms that might change. They want their files on their computer, their repos under their control, their deployments going to providers they already pay.

Plugin architecture, not monolith.

We’ve seen what happens when a platform tries to be everything to everyone too early. The core does one thing well: edit, deploy, maintain. Everything else — SEO tooling, AI assistance, Project Memory, commerce connectors — is a plugin. The core is fast and unopinionated. The plugins create a layered commercial ecosystem on top. The marketplace, once open to third-party developers, creates a compounding effect: more plugins make spec2web more valuable, which attracts more users, which attracts more plugin developers. We’re building the platform, not the features.

Who This Is Actually For: Three Real Segments

Let’s be specific, because “anyone with a website” is not an ICP.

Developers and agencies building with AI tools. These are the earliest adopters and the people closest to the problem. The build side of their workflow is solved. But maintenance is destroying their margins. Every routine update from a client — change this text, update this price, fix this image — costs twenty to thirty minutes minimum. Re-open the project. Reload context. Make the change. Push. Redeploy. Across ten clients, once a week each, that is three to five hours of low-value work every week.

spec2web gives them two things: a platform their clients can use for routine changes without involving them, and a managed retainer product (spec2web Care) they can white-label or refer clients to for a recurring fee. The developer builds the site, hands over the dashboard, and earns referral income for the lifetime of the client relationship.

Freelance designers. Designers are using AI tools to produce sites they couldn’t previously build technically. But designers have a specific vulnerability: they’re not developers. They can produce a beautiful site with Bolt or Framer. They cannot set up a GitHub CI/CD pipeline, connect Google Search Console programmatically, or build a client-facing CMS. spec2web fills exactly that gap — turning a one-off project into a recurring revenue relationship.

Non-technical founders, consultants, and business owners. This is the segment who built their own site with an AI tool — or had someone build it cheaply using AI — and now own something they can’t operate. They’re smart, capable people who simply don’t want to learn to code. They want their website to work. They want to update it. They want to know if it’s appearing in Google. spec2web gives this segment genuine self-service capability for the first time.

What Comes Next: The Roadmap We’re Honest About

We’re shipping early and learning from real use. Here is where things stand as of publish date, and where we’re headed.

What works today: The visual editor is functional — open a project, click any element, edit the HTML, see it update in real time, deploy in one step. Git integration with GitHub is stable. Deployment to Vercel, Netlify, and Cloudflare Pages works. Google Search Console integration is live — keyword data, impressions, indexing status, all surfaced in-context in the editor. The robots.txt manager works.

What’s in active development (Q2 2026): WooCommerce and PayPal integrations are functional but not yet out of beta. The SEO plugin v1 — on-page audit, title tag and meta description analysis, heading structure, image alt text, sitemap manager — is in build. The Plugin API is being documented and versioned for community developers.

What’s on the roadmap: Project Memory plugin — auto-generation of structured project context from the codebase. Watches for changes and updates the context file automatically. Exports as a standard markdown file. Useful for onboarding, handoffs, and as context-feeding for the AI when you do go back to it. AI Assistant plugin — Cursor-like capability on top of the HTML editor. Natural language input, HTML diff preview, approve or reject, deploy. When Project Memory is installed, the AI already has full context from the first prompt.

What we explicitly are not building (yet): Support for complex enterprise sites with custom backend logic, headless architectures serving multiple channels, or large SaaS products. Not because those markets aren’t interesting — because owning the simpler case completely is the right sequence. Build the platform for the AI-built SMB site first.

The Managed Service: For People Who Want a Human Behind It

spec2web as a platform is open source and free. Not everyone wants to run their own operations layer, even with the right toolset.

For them, there’s spec2web Care — a managed maintenance and operations service delivered by specshop.dev. Proactive monitoring. Content updates. SEO maintenance. Flat monthly pricing. No ticket queue. No surprise billing. No discovering on Monday that something broke on Friday.

Care is built on the spec2web platform. Our team — which uses the same toolchain we’re giving to the world — can maintain client sites with a fraction of the overhead a traditional agency carries. That’s the margin advantage that makes the pricing competitive and the service profitable at the same time.

The Care retainer is also how we’re building the training data for the automation layer. In Years 1–2, the service is human-delivered. By Year 3, the target is for 90% of standard maintenance requests to be fulfilled by proprietary AI automation, trained on the patterns from early human delivery. That’s the trajectory. We’re honest that we’re at the beginning of it.

And if none of those apply — if you just found this interesting — follow along. We’re publishing the build, the numbers, the mistakes, and the lessons. No polish, no PR, no “we’re excited to announce.” Just the real thing.

Questions About spec2web