Websites as a Subscription: Building xqx.pl into an Automated Studio with a Human in the Loop

Context

xqx.pl is my own studio. It sells one thing: a business website on a monthly subscription. You pick a package, you see the price and the delivery date on screen, you pay, and a few days later the site is live — with hosting, SSL, a CMS, backups, technical care, and a monthly results report included in the same recurring fee.

That is the product today. This post is about how it is built, why the subscription model changes the engineering decisions, and where it is going: a heavily automated production pipeline that keeps a human in the loop at every point where judgement matters, plugged into an auto-promotion engine that keeps marketing a client's website long after launch.

I have been building websites professionally since 2010 and running my own business since 2014 — 160+ projects, clients in 10+ countries, from one-page brochure sites to SaaS platforms with millions of users. xqx.pl is what happens when you take fifteen years of that and ask a different question: not "how do I deliver this project?" but "how do I deliver this category of project a hundred times without the quality falling apart?"

The Gap in the Market

A small business owner in Poland who wants a website has two realistic options, and both are bad.

Option one: the 300 zł template. A marketplace theme, installed and lightly recoloured. It looks like a marketplace theme. It ships with fourteen plugins the owner will never update, a page speed score in the forties, and no one on the hook when it breaks. Twelve months later it is a security liability with a contact form that silently stopped sending email.

Option two: the agency. A discovery call, a proposal in five business days, twelve thousand złoty, and three months of calendar time for what is, structurally, a brochure site with six subpages. The work is often good. The price and the timeline are calibrated for a client who has a marketing department, and a hairdresser, a physiotherapist, or a restaurant owner does not.

The middle was empty. Nobody was selling a genuinely custom, fast, well-optimised small business website with a price you could read off a screen and a delivery date measured in days.

There is also a second, quieter problem: nobody answers the question "how much does a website cost?" Every agency site in this market says "contact us for a quote." That is not a pricing strategy, it is a filter — and it filters out exactly the customer who is ready to buy but not ready to negotiate. The most common reason a small business does not have a website is not that they decided against it. It is that they asked three companies, got two non-answers and one number with no explanation, and quietly gave up.

Websites as a Subscription

xqx.pl answers the question on the homepage, in the form of four packages. These are the real numbers, net of VAT, per month:

The commercial shape matters as much as the numbers:

• 0 zł to start. No setup fee, no activation charge, no "design deposit."
• 12-month minimum term, monthly or annual billing. Annual prepay is ‑17% — effectively two months free — and includes a free .pl domain.
• The domain is registered in the client's name and stays theirs if they leave. This is non-negotiable for me. A subscription that holds the client's domain hostage is not a subscription, it is a hostage situation.

This is the websites-as-a-service (WaaS) model, and it is a genuinely different business from project work. In project work you are paid once and every subsequent hour is a loss. In a subscription you are paid every month, which means the incentive flips: it is now cheaper for me if the site does not break, if hosting is fast, if the client can edit their own content without calling me. The subscription aligns my margin with the client's outcome. That alignment is the whole argument.

What "included" has to mean

A monthly price only works if the boundary of what it buys is explicit. Every xqx.pl package includes:

• A custom design, made for the client's industry — not a marketplace theme with new colours.
• Managed hosting, SSL, and automated backups. No separate hosting invoice, no expiring certificate at 2am.
• Technical care and security updates for the full subscription term.
• Unlimited content edits through the CMS. Text, photos, prices — the client changes them themselves, as often as they want.
• A monthly results report: traffic, sources, visitor behaviour, in plain language.

And the boundary that makes the fixed price survivable:

Fixes are unlimited and free. Design rounds are not.

Anything that is a defect — a broken responsive layout, weak SEO, a form that fails, a typo we introduced — is our problem and we fix it without limit and without an invoice. A design change — a new layout, a different look, a structural rewrite — gets one free round in every package. Further rounds are priced one-off: 150 / 250 / 350 / 400 zł depending on the package.

Every productised service dies the same death: unbounded scope against a fixed price. Writing the boundary down, publicly, in the customer's own language, is what keeps the model alive. It also removes the single most uncomfortable conversation in this business — the one where you have to explain, after the fact, why this particular request costs extra.

Pricing as a Product Surface

The calculator on the homepage is not a marketing widget. It is the sales process.

The client picks a package, toggles monthly versus annual, adds extras, and the price and the publication date recalculate live. Not "we'll get back to you." Not a quote request form. A number and a date, on screen, in about sixty seconds — followed by a checkout that takes payment through Tpay.

Two things follow from that, and both are engineering constraints rather than copywriting choices:

1. The estimate has to be honest, because it is binding. If the calculator says three business days, the pipeline behind it has to deliver in three business days. A pricing surface that overpromises is worse than no pricing surface at all. This is the single hardest constraint in the product, and it is the reason the rest of this post exists — an honest instant quote is only possible on top of a genuinely repeatable production process.
2. The price has to hold across a hundred clients. Which means the cost of producing site number 100 has to look like the cost of producing site number 3. That is a manufacturing problem, not a design problem.

Removing the quote wait is the entire conversion argument. Every day between "I want a website" and "here is what it costs" is a day the buyer talks themselves out of it. Instant pricing does not just convert better — it converts a different customer, the one who would never have sent the enquiry email at all.

The Delivery Pipeline Today

Four steps, and the client never has to write an email.

1. Choose a package and start the subscription — online, in the calculator, 0 zł upfront.
2. Upload materials — text, photos, logo go into the client panel.
3. Connect the domain — bring your own in a minute, or we register one inside the package price.
4. Approve and it's live — one round of design changes is included before publication.

The panel is where intake happens, and it is deliberately the least friction-y thing in the product: passwordless login. The client types the email they ordered with and gets a magic link. No password to forget, no account to create, no reset flow to support. For a customer segment that regularly locks itself out of its own Google account, this removes an entire class of support ticket.

The stack, and why it is one stack

Every client site is built on the same foundation: Next.js + TypeScript, deployed on Vercel, with a CMS layer for content. That uniformity is the product's most important technical decision.

• One stack means one upgrade path. A framework security release is one rollout procedure applied N times, not N archaeology projects.
• One stack means shared components. A booking widget built for one restaurant is available to the next one, hardened by the first client's real usage.
• One stack means predictable performance. Server rendering, static generation where it fits, and image optimisation are defaults rather than per-project heroics. Good Core Web Vitals and clean Lighthouse scores come from the platform, not from a rescue mission before launch. I wrote up what that looks like when pushed to the limit in the Qlease 100/100/100 case study.
• One stack means the technical SEO baseline ships by default: semantic HTML, clean URLs, sitemap, robots.txt, Open Graph, and JSON-LD structured data — LocalBusiness, Organization, Service, FAQPage, Menu for restaurants — generated from the same content the client typed into the CMS, not hand-written per project.

That last point is worth dwelling on. A small business website's SEO value is mostly structural: correct markup, correct entities, fast pages, real content. Those are exactly the things a templated pipeline can guarantee and a bespoke project routinely forgets.

Same stack, same standards, whether it is a one-page site for a vocal coach or a platform with millions of users. And because the whole thing is built mobile-first, the small-screen experience is not an afterthought — for most of these businesses it is the only experience their customers will ever have.

Where It's Going: Automation with a Human in the Loop

Everything above exists today. What follows is the roadmap — the system I am building toward.

The goal is not "AI builds websites." That framing produces demos, not businesses. The goal is narrower and much more useful: compress the mechanical 80% of production to near-zero marginal cost, and spend the freed time on the 20% that is actually judgement.

Here is the honest split.

Genuinely automatable:

• Intake normalisation. The client uploads a logo, twelve photos of varying quality, and a Word document. Extracting structure from that — services, opening hours, address, NAP data, tone — is a well-defined transformation.
• Copy drafting. First-draft headlines, service descriptions, meta titles and descriptions, alt text, FAQ entries. Drafts, not final copy.
• Image processing. Cropping, format conversion, responsive variants, compression — this is already fully mechanical.
• Layout assembly from a design system: choosing and configuring section blocks against the content that actually exists, rather than against a wireframe of content that might.
• Structured data generation. JSON-LD is a deterministic function of the business facts. There is no reason a human should ever hand-write it.
• Quality gates. Lighthouse budgets, accessibility checks, broken-link scans, schema validation, a visual diff against the previous deploy. These run on every build and block on failure.
• Deployment. Preview URL, domain wiring, DNS verification, SSL, go-live.

Not automatable, and I am not going to pretend otherwise:

• Brand judgement. Whether a design feels right for a psychotherapist's practice versus a stretch-film manufacturer is not a scoring function.
• The client conversation. Understanding that what the client asked for is not what they need is the actual skill in this job.
• The go/no-go before publication. Somebody with a name and a reputation approves what goes live.

The rule is one sentence: the machine proposes, a person disposes. Every client-visible artefact — a page, a paragraph, a published post, an outbound update — passes exactly one human approval gate before it reaches the world. This is the same architecture I use for Nico, the AI assistant inside Learnico: the model never performs a consequential write directly; it produces a structured proposal, and a human confirms it.

                     ┌──────────────────────────────┐
  client materials → │  INTAKE                      │
  (panel upload)     │  normalise · extract facts   │
                     └──────────────┬───────────────┘
                                    │
                     ┌──────────────▼───────────────┐
                     │  GENERATE                    │
                     │  copy drafts · layout from   │
                     │  design system · JSON-LD ·   │
                     │  image variants              │
                     └──────────────┬───────────────┘
                                    │
                     ┌──────────────▼───────────────┐
                     │  AUTOMATED GATES             │
                     │  Lighthouse budget · a11y ·  │
                     │  schema validation · links   │
                     └──────────────┬───────────────┘
                                    │  fail → back to GENERATE
                                    │
                     ┌──────────────▼───────────────┐
                     │  ★ HUMAN REVIEW              │  ← the gate that never gets removed
                     │  brand · tone · go / no-go   │
                     └──────────────┬───────────────┘
                                    │
                     ┌──────────────▼───────────────┐
                     │  PUBLISH                     │
                     │  deploy · domain · SSL       │
                     └──────────────────────────────┘

Concretely, every unit of work in the pipeline is a job with an explicit approval state. Nothing reaches a client's domain without passing through approved:

type ArtifactKind =
  | 'page'
  | 'copy_block'
  | 'blog_post'
  | 'schema'
  | 'image_set'
  | 'promo_update';
 
type ReviewState =
  | 'draft'        // queued, nothing generated yet
  | 'generated'    // machine output exists
  | 'gated'        // automated checks passed (Lighthouse, a11y, schema)
  | 'needs_review' // waiting on a human — the only path forward
  | 'approved'     // a named person signed off
  | 'published'
  | 'rejected';    // feedback recorded, fed back into generation
 
interface PipelineJob {
  id: string;
  siteId: string;
  kind: ArtifactKind;
  state: ReviewState;
  generatedBy: 'human' | `model:${string}`;
  approvedBy: string | null;   // never null in state 'published'
  checks: { lighthouse: number; a11y: boolean; schemaValid: boolean };
  rejectionNotes?: string;     // training signal for the next run
}

Two design details carry most of the weight:

approvedBy is never null for anything published. It is a database invariant, not a policy document. If a machine can quietly publish, then sooner or later it will publish something embarrassing on a real business's homepage, and the client will be the one who finds it.

Rejections are recorded, not just acted on. Every "no, not like that" is a labelled example. The system that gets better is the one where the human's correction is captured as data rather than absorbed as a fixed edit.

The economics of this are simple. If generation is cheap and review is the bottleneck, then the design question becomes: how do I make review fast? Side-by-side diffs, quality gates that have already eliminated the obvious problems, and batching similar decisions together. A review that takes four minutes instead of forty is what turns a studio into a system.

The Auto-Promotion Engine

This is the part I am most interested in, and the part that is furthest out. Consider it a design, not a shipped feature.

A website that goes live and then sits still is a dead asset. This is the actual failure mode of the small business web. The site launches, everyone is happy, and then nothing is ever added to it again. Eighteen months later it ranks for nothing, it says the opening hours from before the renovation, and the owner concludes that "websites don't work."

A subscription is the right commercial shape to fix this, because the relationship does not end at launch — the client is paying every month, so the site should be doing something every month. The auto-promotion engine is the system that makes that true: an always-on marketing loop attached to every client site, running inside the subscription.

flowchart TD
    A[Business profile: industry, services, location, NAP] --> B[Content calendar<br/>industry templates + seasonality]
    B --> C[Generation queue]
    C --> D1[Blog post drafts<br/>local + service intent]
    C --> D2[On-page SEO<br/>internal links, meta, entities]
    C --> D3[GEO layer<br/>JSON-LD, citable passages, llms.txt]
    C --> D4[Google Business Profile<br/>posts, photos, review prompts]
    C --> D5[Directory + NAP consistency]
    C --> D6[Social syndication]
    D1 --> E{★ Human approval gate}
    D2 --> E
    D3 --> E
    D4 --> E
    D5 --> E
    D6 --> E
    E -->|approved| F[Publish / distribute]
    E -->|rejected| C
    F --> G[Monthly results report<br/>traffic, queries, AI citations, conversions]
    G --> B

The components, in the order they matter for a local business:

1. A content calendar per industry. A physiotherapist, a restaurant, and a stretch-film manufacturer do not need the same twelve posts. Industry templates encode what the recurring topics and seasonal moments actually are — and the client's own facts fill them in. Generic content ranks for nothing; the specificity has to come from the business.

2. Blog posts, generated and human-approved. Drafted against local and service intent ("physiotherapy for runners in Kraków", not "the importance of physiotherapy"), then reviewed. This is where the approval gate earns its keep: publishing unreviewed generated text under a real business's name is a reputational risk transferred from me to my client, which is exactly the wrong direction.

3. On-page and technical SEO, continuously. Internal linking as the site grows, meta refreshed when services change, entity consistency across pages, sitemap freshness. Not a one-time launch checklist — a recurring pass.

4. A GEO layer. Generative Engine Optimization is the part most studios are not thinking about yet, and for a local business it may end up mattering more than classical rankings. When somebody asks ChatGPT, Perplexity, Gemini, or Google's AI Overviews "who does X in my city," the answer is assembled from sources the model can parse and trust. Optimising for that means: structured data that states the business's facts unambiguously; short, self-contained, quotable passages that answer a real question in one paragraph; consistent entity information everywhere the business appears; an llms.txt describing the site for machine readers; and crawler access that does not accidentally block the AI crawlers. Classical SEO gets you into the index. GEO gets you into the answer.

5. Google Business Profile automation. For a local business this is often worth more than the website itself: scheduled posts, fresh photos, opening-hours accuracy, and — carefully — review prompts. Automating the mechanics here is high leverage precisely because it is the thing owners never get around to.

6. NAP consistency across directories. Name, address, phone, identical everywhere. Boring, unglamorous, and a real local ranking factor. Perfect work for a machine, and terrible work for a human.

7. Social syndication. The post that went on the site becomes the post that goes on Facebook and Instagram, reformatted appropriately, still behind the same approval gate.

8. The monthly report closes the loop. The report the client already receives becomes the input to next month's calendar: which queries produced traffic, which pages converted, where the business is being cited by AI assistants. Results feed planning. Without that edge, the whole thing is just scheduled content production with extra steps.

Everything in that diagram converges on one node: ★ Human approval gate. Same gate as the build pipeline, same invariant, same reason. An auto-promotion system that publishes autonomously to a real company's Google profile is not a feature, it is a liability with a cron schedule.

Why Subscription Economics Make This Possible

There is a reason a traditional project-based agency cannot build this, and it is not talent.

In project work, revenue is lumpy and tied to delivery. Any month spent building internal automation is a month of lost billable capacity, with the payoff arriving somewhere in a future you cannot forecast. The rational move is always to take the next project. So the tooling never gets built, and the twentieth site costs roughly what the first one did.

Recurring revenue changes the arithmetic:

recurring revenue
      → funds engineering time on the pipeline
      → lowers marginal cost per site
      → makes a lower price point profitable
      → widens the addressable market (the 300 zł-template customer)
      → more subscribers
      → more recurring revenue

The interesting consequence is at the bottom of the market. At a 12k project price, a large part of the population of Polish small businesses is simply not a customer — not because they do not want a website, but because the number is not survivable for them. Every złoty removed from the marginal cost of production moves the floor down and pulls a new band of businesses into the market. That is the actual point of automating this. Not margin. Reach.

The metrics that matter in this model are not project metrics. They are MRR, churn, cost of production per site, and — the one nobody tracks early enough — support minutes per client per month. A subscriber who needs forty minutes of my attention every month at 99 zł is not a customer, they are a slow-motion loss. That single number drives more product decisions than any other: passwordless login exists because of it, unlimited CMS editing exists because of it, the explicit fixes-versus-design-rounds boundary exists because of it.

What I'd Tell Someone Productising a Service

Five things, learned expensively.

Constrain before you automate. You cannot automate a process you have not first made boring. Four packages, one stack, one deployment path. Every axis of variation you allow multiplies the automation surface. The packages are not a marketing simplification — they are the precondition for everything downstream.

Put the boundary in writing, in the customer's language. "Fixes free, design rounds priced" is a public sentence on the website, not a clause the client discovers in month four. Unbounded scope against a fixed price is how productised services die.

Automate the mechanical 80%, keep the judgement. Not because AI is untrustworthy in principle, but because the 20% is where the client's actual value is, and where your reputation lives. Make the approval gate an architectural invariant — a NOT NULL constraint, not a promise.

Instrument margin per client from day one. In project work you find out you underpriced when the project ends. In a subscription you find out twenty-four months in, after the loss has compounded across every month. Support minutes per client is the leading indicator.

Give the client the exit. The domain in their name, their content exportable, no hostage-taking. Counterintuitively this sells better than a lock-in, because the reason small businesses distrust subscriptions is precisely the fear of being trapped. Removing the trap removes the objection.

Conclusion

xqx.pl today is a productised website subscription: four packages, live pricing, delivery in 3 to 12 business days, custom design, CMS, managed hosting, SSL, technical care, and a monthly report — from 99 zł net per month, with the domain in the client's name.

Where it is going is a production system where the mechanical work of building and promoting a small business website runs continuously and automatically, and a human being reviews and approves everything a client's customers will ever see. Not AI that builds websites. An automated studio with a person at the gate.

The subscription is what makes it possible: it funds the engineering, it aligns the incentives, and it turns a website from a thing you buy once into a thing that keeps working every month you pay for it.

If you want to see the pricing side of it, the calculator is on xqx.pl — price and delivery date, in about sixty seconds, without sending anyone an email.