W
WisyLink
ProductPricingAPIBlogContact

00 · Product

The engineering behind WisyLink

A plain, section-by-section reference for how the product is engineered, what it can and can't do, how it stays reliable, and how it's supported.

No vendor names. No invented metrics.

01 · Architecture

How it's actually built

Every site is a real, independent backend — not a shared template. Here's what that means underneath.

1.1

Its own compute, not a shared one

Every site you build runs on its own dedicated compute — never sharing a runtime with any other site's code. A problem in one site has no path into another's.

1.2

A real backend from the first build

Each site gets its own database and file storage, and — when it needs them — real accounts, payments, and live channels, wired in from day one instead of bolted on later.

1.3

A multi-agent build pipeline that runs with nothing to take

The build process is a coordinated pipeline of specialized agents and an orchestration layer above them — and none of it carries standing access to your account, your credentials, any other site's data, or the platform's own environment variables and internal configuration. Even a manipulated instruction can only affect the one site already being worked on.

1.4

Every request is checked before it runs

An unsigned or forged request never reaches your site's code — it's rejected at the front door, before any compute even starts.

1.5

Delivered from a global network, kept current automatically

Pages are served from a global network close to your visitors. A new build goes live in seconds; a data change reaches visitors in about a minute — with no manual step.

1.6

Deploys are all-or-nothing

A new version either fully replaces the last one, or it doesn't ship. There's no state where visitors land on a half-updated site.

02 · Scope

What it does — and what it doesn't

What gets produced is a real, production-grade product — built inside a fully isolated, secure, live environment, coordinated across multiple orchestration layers and specialized agents. Here's exactly what that includes, and where the intentional limits are.

What's included

2.1

✓ A real, hosted web app

Server-rendered pages on their own domain, with search-engine-visible content from the first byte — not a static mockup.

2.2

✓ A working backend, not just a front end

Data storage, file uploads, and — when the site needs them — accounts, payments, and live updates, already wired in.

2.3

✓ Your own address

A hosted subdomain by default, or your own custom domain connected or purchased through the platform.

2.4

✓ Keeps working while you keep changing it

Every change goes through the same isolated build process and either ships cleanly or leaves the previous version live.

The intentional limits

2.5

— It never spends on your behalf silently

Any action that consumes billable usage beyond your plan's included allowance runs only after you explicitly trigger it — never automatically, and never past what you've approved.

2.6

— It doesn't hold your third-party accounts

Payment processors, email, and any other service you connect are configured with your own credentials, encrypted at rest and read only by your own site's code.

2.7

— Usage has a ceiling, and it's enforced, not assumed

Storage, database, and bandwidth are measured continuously and capped per account — a limit is enforced the moment it's reached, never after the fact.

2.8

— It builds real web backends, not app-store binaries

What you build is a web application, reachable from any browser and any device — not a compiled app submitted to an app store.

03 · Reliability engineering

Built to stay up, not just to launch

No platform is immune to failure. What matters is how much of a failure it contains, and how quickly it recovers.

3.1

Contained failure

Because every site runs on its own compute, a fault or traffic spike on one site can't take another one down with it.

3.2

A failed build never reaches visitors

If a new version doesn't finish successfully, the site simply keeps running on the last one that did — reliability here means nothing ever ships half-done.

3.3

Abuse absorbed before it reaches you

Traffic passes through a protective global layer before it reaches any compute — high-volume abuse is stopped before it becomes your site's problem.

3.4

Race-free resource accounting

Usage limits are enforced as part of the same write that consumes them, at the data layer itself — not by a separate check that can lag or double-count.

3.5

No shared maintenance window

Every site is deployed and updated independently, so there's no platform-wide window that takes every site offline at once.

04 · Development history

How the architecture got here

The platform didn't arrive at this design by accident — it moved here in deliberate stages.

Foundation

One backend per site

The core decision: every site is its own real backend on its own compute, with its own database — not rows in someone else's app.

Hardening

Locking down the request path

Every request into a site's compute was moved behind cryptographic signing, so an unsigned or forged hit is rejected before it costs anything to process.

Sandboxing

Stripping the build agent's privileges

The AI build process itself was moved to run with no standing permissions at all — access to secrets and infrastructure was removed at the source, not filtered after the fact.

Today

Instant, event-driven delivery

Cache invalidation moved from waiting on a timer to firing the moment something actually changes — a new build or a data write reaches visitors almost immediately.

05 · Support

How support requests are handled

Send a question or a support request through the contact channel — here's what happens once it arrives.

5.1

Every report is picked up the moment it lands

A submitted issue enters the system immediately and is triaged without delay — nothing waits in an unattended queue.

5.2

Most technical issues are resolved autonomously

The system investigates the reported problem and, in most cases, resolves it on its own — and keeps watching afterward to confirm it stays resolved.

5.3

If it needs a person, you'll hear from us directly

When a report requires a response back to you, we reach out as soon as possible — not left in a ticket queue.

5.4

It starts with a message

Every step above begins the moment one arrives — send a question or a support request through the contact form and the process starts immediately.

See it for yourself

The fastest proof is a real one — describe what you want and watch it get built.

Let's build something together

“From a sentence to a live app.”

Documentation

  • Overview
  • API
  • CLI
  • GitHub
  • npm

Blog

  • Explore the blog

Legal

  • Privacy
  • Terms
  • Company

Product

  • Capabilities
  • Pricing
  • Contact
  • Engineering
WisyLink © 2026·
Built with ❤️ by our team