Webeloper

The Premise

Most people who can sell a website cannot build one.

Most people who can build one cannot easily handle the entire process of finding prospects, understanding their needs, designing a solution, developing it and delivering it.

Webeloper explores whether an agentic system can close that gap.

The experiment was simple: could someone with no web-development skills run the complete sales and delivery cycle of a website business?

The human would choose the market and make the sale.

The system would handle everything in between.

The Hypothesis

Webeloper started from a broader hypothesis:

AI agents should take responsibility for the mechanical parts of a workflow while humans remain responsible for the decisions where context, judgment and agency matter most.

For a website business, that meant separating the workflow into three specialized roles:

Rather than building a single general-purpose agent, each agent receives a specific responsibility and a structured contract describing what the next stage needs to accomplish.

The System

The workflow begins with a human choosing a niche.

The Seller Agent researches potential customers, analyzes their online presence and prioritizes prospects. For each opportunity, it creates a Project Contract describing the prospect, the opportunity and the characteristics the website should address.

The Designer Agent consumes that contract and translates it into a Design Contract: a structured description of what needs to be designed and how the website should respond to the prospect's needs.

The Developer Agent then turns that contract into a functional website.

The resulting workflow is:

The human remains in the loop where the system benefits from human judgment, while the agents handle the execution between those decisions.

Why Contracts Matter

One of the central architectural decisions in Webeloper is the use of contracts as interfaces between agents.

The agents don't simply pass conversational context from one stage to another.

Instead, each stage produces a structured artifact that explicitly defines what the next agent needs to do.

This serves several purposes.

Contracts give each agent clear and specific instructions, reduce ambiguity between stages and provide a mechanism for constraining the agent's behavior.

They also reduce the amount of orchestration the human needs to perform. Instead of manually explaining to each agent what happened previously and what should happen next, the workflow itself defines those responsibilities.

For Webeloper, this became an important lesson:

Agentic systems need interfaces, not just conversations.

Keeping the Human in the Right Place

The initial version of Webeloper tried to automate more of the workflow.

That included letting the Seller Agent generate the final cold-outreach message.

In practice, this created a problem.

The generated messages were often generic, sometimes overly aggressive, and did not adequately account for considerations such as terms that could increase the likelihood of being interpreted as spam.

The solution wasn't simply to improve the prompt.

Instead, the responsibility was redesigned.

The Seller no longer makes the final decision about the outreach message. It proposes a message skeleton, while the human decides whether and how to use it.

This reflects a broader principle emerging from the experiment:

Autonomy should be assigned according to the cost of being wrong, not simply according to whether a task can technically be automated.

The same principle is being applied to the design stage. Future versions will allow the human to define selected aspects of the website's design system while leaving the agent responsible for implementation.

Where the System Breaks

Webeloper also exposed several failure modes.

Defining "good"

Webeloper deliberately uses a relatively strict definition of a successful website.

A site isn't considered successful simply because an agent generated code that renders in a browser.

It needs to:

• satisfy the requirements established by the contract;
• be fully functional;
• work responsively;
• implement the requested interactions correctly;
• avoid functional errors.

This distinction matters because Webeloper isn't testing whether an LLM can generate a website.

It is testing whether a system can reliably deliver a usable artifact as part of a larger workflow.

A Real-World Test

The experiment eventually moved beyond the controlled development environment.

A person who discovered Webeloper through LinkedIn decided to try the system because they needed to generate income.

They selected four different niches.

For each niche, Webeloper identified three prospects. The human handled the actual sales conversations while the system generated the demo websites and, according to the user's report, the final websites after sales.

Within three weeks, the user reported having sold four websites.

The user has not authorized NDZ Labs to disclose their name, LinkedIn profile or employer, so the result is presented anonymously.

This is not treated as statistical validation of the system. It is an early real-world signal that the workflow can support someone without web-development expertise through an actual commercial process.

What Webeloper can — and cannot — do

The current system is designed around relatively straightforward websites.

It has not been sufficiently tested with complex products such as e-commerce platforms or CMS-driven applications, so those capabilities are not claimed.

This limitation is part of the experiment rather than something to hide.

The next iteration focuses on expanding the Developer's capabilities through specialized skills, including the ability to work with technologies such as PHP and React while remaining conscious of token consumption and implementation efficiency.

The objective isn't simply to give the agent more capabilities.

It is to make those capabilities available when they are actually necessary.

What We Learned

Webeloper started as an experiment in automating website development.

It became an experiment in how autonomy should be designed.

The most important lessons so far have been:

1. 1. Agents need explicit boundaries. Giving an agent a task doesn't mean it should own every decision related to that task.
2. 2. Contracts can act as coordination infrastructure. Structured handoffs reduce ambiguity and minimize the need for humans to orchestrate every step.
3. 3. Automation changes the location of the bottleneck. When execution becomes cheap, verification, quality control and judgment become more important.
4. 4. More autonomy isn't necessarily better. The Seller generating outreach messages was technically possible. Giving it the final decision wasn't necessarily the right system design.
5. 5. Output quality requires explicit evaluation criteria. A website can satisfy a prompt and still be poor. Functional correctness, responsiveness and adherence to the contract need to be treated as requirements of the system.
6. 6. Skills provide a mechanism for evolving the system. Instead of continuously increasing the complexity of the core orchestration, new behaviors can be introduced as specialized skills that modify how individual agents operate.

What's Next

Webeloper is still an experiment.

The next iterations focus on improving verification during prospect discovery, preventing repetitive implementation patterns, reducing AI-generated design conventions and expanding the Developer's ability to handle more complex web applications.

But the larger question remains unchanged:

How much of a workflow can an agentic system own before autonomy stops helping the human and starts getting in their way?

Webeloper is one attempt to find that boundary.