How I Built SiteHorse.ai in 6 Weeks

The Idea

Early 2026. Every developer knows the feeling: you have an idea for a project that will not leave you alone. For me, it was the frustration with how laborious it still is to create a professional website. Yes, there is WordPress, Wix, Squarespace. But all of these tools require the user to make decisions they should not have to make: Which template? Which color scheme? Which font? How do I organize the navigation?

My idea was simple: What if you could just tell an AI who you are and what you do, and it builds the complete website? Not a template you customize, but a finished, individual website with real content, real design, live immediately.

That was the birth of SiteHorse.ai.

Market Analysis in One Week

Before I wrote a single line of code, I spent a week analyzing the market. Not with expensive tools or elaborate studies, but pragmatically: Who are the competitors? What does a website cost today? Who needs websites but has neither the time nor the budget for a designer?

The insight was clear: there is a massive market of small businesses, freelancers, and associations that need a professional web presence but do not want to spend a thousand euros on a designer and do not have the time to learn their way around a website builder.

At the same time, the existing “AI website builders” were disappointing. Most of them simply took a template and replaced the placeholder text with AI-generated text. The result was generic and uninspired. I knew I could do better.

Defining the MVP Scope

The hardest decision with any product is what NOT to include in the first version. I had a list of fifty features that SiteHorse should have. But I wanted to move fast — six weeks, one developer. So I cut ruthlessly.

The MVP had to do exactly three things: Ask a series of questions to understand the user’s business. Generate a complete website from the answers, including text, images, and design. Put the website live on a subdomain.

Everything else — custom domains, e-commerce integration, analytics, multi-language support, blog functionality — went on the “later” list. It was painful, but it was the right call.

The Foundation: IT-Trail SaaS Stack

Before I wrote the first line of SiteHorse code, there was an important decision to make: build everything from scratch, or invest in a reusable foundation first? I chose the latter — and built the IT-Trail SaaS Stack.

The SaaS Stack is an all-in-one foundation for SaaS applications: OAuth2-based single sign-on for all IT-Trail services, user registration, Google and Microsoft login, Stripe and Paddle integration for payments and subscriptions. All in TypeScript, all modular, all built so I can reuse it in every future SaaS project.

This investment paid off massively. When I started building SiteHorse, authentication, payments, and user management were already solved. I could focus entirely on what makes SiteHorse unique: the AI pipeline for website generation. Without the SaaS Stack, it would have taken weeks longer — or I would have had to compromise on quality.

The stack is currently still a private repository, but I plan to release it as open source in the future. Good infrastructure should not be a competitive advantage — it should be a foundation everyone can build on.

Technical Architecture

Backend: Node.js with TypeScript

The backend choice was made quickly: Node.js with TypeScript. Not because it was the objectively best choice, but because it is what I am fastest with. In a solo project, the developer’s speed is the most important factor, not the theoretical superiority of a technology.

The backend architecture builds on top of the IT-Trail SaaS Stack. No microservices, no Kubernetes, no over-engineering. A single Node.js service running on Hetzner Cloud in Germany, with clearly defined modules for website generation, template rendering, and asset management — while auth, payments, and user management come from the SaaS Stack. All data stays in Germany — that was important to me from the start.

The AI Pipeline

The heart of SiteHorse is the AI pipeline that generates a finished website from user inputs. This pipeline consists of several steps that run sequentially and partly in parallel.

In the first step, an LLM analyzes the user inputs and creates a structured profile: industry, target audience, tone of voice, key services or products. In the second step, another LLM call generates the content: text for each page, meta descriptions, CTAs. In the third step, a matching design is selected and configured: color scheme, typography, layout variant.

Each of these steps has its own challenges. The text generation needs to be consistent — the tone on the homepage must match the tone on the “About Us” page. The design needs to fit the content, not the other way around. And the whole process needs to complete in under thirty seconds, because no user wants to wait longer than that.

Prompt Engineering: The Unexpected Challenge

I underestimated how much work would go into the prompts. My first attempts were naive single prompts: “Create a website for a hairdresser in Vienna.” The result was — well — usable, but generic.

The solution was a multi-stage prompt system with specialized prompts for each step. One prompt for analysis, another for text creation, a third for design decisions. Each prompt with specific instructions, examples, and constraints.

I went through over three hundred prompt iterations until the results were consistently good. Three hundred. That is more than the number of commits in the entire backend code.

The biggest challenge: consistency. A single good output is relatively easy to achieve. A thousand consistently good outputs — for different industries, languages, target audiences — is an entirely different task.

Template System

I deliberately decided against a completely free-form design. Instead, I built a template system consisting of roughly twenty design building blocks: hero sections, feature grids, testimonial slides, contact forms, footer variants. The AI selects the appropriate building blocks and configures them with the generated content.

This has two advantages: the results are always visually appealing (because the building blocks are professionally designed), and the generation is fast and reliable (because the AI does not have to invent a complete design from scratch every time).

Challenges and Mistakes

Edge Cases

The first big shock after launch: the diversity of inputs. I had tested with hairdressers, restaurants, and lawyers. But then users came along with businesses I had never imagined. An alpaca breeder. An underwater wedding photographer. A historical martial arts association.

The AI handled most of these well, but there were enough outliers to keep me busy with edge-case handling for weeks. The lesson: no matter how much you test, real users will do things you did not expect.

Pricing

My first pricing model was wrong. I started too cheaply because I was afraid nobody would pay. The result: lots of sign-ups, but hardly any revenue. And even worse: the users who come for very little money often have the highest expectations and the highest support overhead.

After one month, I tripled the prices. The number of sign-ups dropped, but revenue increased, and the quality of customers improved significantly. Pricing is an art, and I am still learning.

Performance

The first version of the generation took two minutes. Two minutes during which the user stared at a loading bar. The conversion rate was predictably poor. I spent weeks optimizing — parallel API calls, caching, pre-rendering — and I am now at under thirty seconds. Still not perfect, but acceptable.

Lessons Learned

Six weeks from idea to closed beta. What did I learn from it?

First: the MVP is never as minimal as you think. Even after cutting ruthlessly, the scope was ambitious for one person in six weeks. I put in over a hundred hours of overtime. That is not sustainable and I would not recommend it.

Second: prompt engineering is software engineering. It needs structure, tests, versioning, and systematic debugging. Anyone who treats prompts like free-form text will fail.

Third: ship fast, but not broken. I launched too early and drove away the first users with bugs. A few more days of stabilization would have saved me weeks of firefighting.

Fourth: solo development has limits. I am proud of what I built on my own. But a product needs more than code: marketing, support, design, content. As a solo founder, you have to cover all of that, and in the long run, that is not feasible.

SiteHorse is currently in closed beta. Selected users are testing the product and providing valuable feedback that flows directly into development. The public launch is in preparation.

SiteHorse is my proof that a single developer with the right tools and enough caffeine can take a SaaS product from idea to beta. But it is also my proof that you need a team after that.