How Weblym works

Components

• The dashboard: where the account, the stores and their settings are managed.
• The editor: the design environment for every page of the store.
• The server: the only component with access to the database. It verifies identity on every request and determines what information can be read and modified.
• The database: stores accounts, stores, pages and products, together with a dedicated repository for images.
• The email service: sends the account verification and password recovery codes.

The browser never talks to the database directly, because it has no credentials to do so: all traffic goes through the server.

Page model

Every Weblym page is a composition of sections. Each section belongs to a family —hero, products, testimonials, frequently asked questions…— and offers several layouts, designed in advance for desktop, tablet and mobile.

We do not store the code of each page, but its design decisions: which sections make it up, in what order, with which layout and with which texts, images and colours. The code is always generated by the platform. This model guarantees the integrity of the page: what changes are values, never the structure that makes it adapt to every screen.

Inheritance between formats

Changes made to the desktop version carry over to tablet and mobile; changes made on mobile apply only to that format. Each version can be fine-tuned without doing the work three times.

Persistence

There is no save button: every change is recorded automatically within moments. When you close the tab or switch apps on your phone, pending changes are sent before leaving.

Publishing

When you publish, Weblym generates a snapshot of the store and serves it at its address. Later changes will not be visible until you publish again.

Each published page includes its three versions —desktop, tablet and mobile— and the visitor’s browser shows the right one for their screen. Published stores can only run code authorised by the platform itself, never third-party code.

AI-generated custom components

In development. This capability is part of the Weblym roadmap and will be added after launch.

Weblym sections cover the usual needs of an online store. But every business is different, and there will always be something no catalog anticipates. For those cases, Weblym will let you describe any feature in natural language and have the artificial intelligence design, code, verify and integrate it into the store as just another fully functional component.

For example: “show how many people are viewing the store right now”. No section does that; Weblym will build it from scratch, connected to real data and updated in real time.

From request to component

1. Specification. The request is turned into a formal specification of the component: what data it needs, how it behaves, how it is presented and what it must show on desktop, tablet and mobile. If anything is ambiguous, the assistant asks before building.
2. Generation. The AI writes the component’s code —structure, styles and logic— on top of the platform’s foundations: it inherits the brand’s colours, typefaces and button style, and is born adapted to all three formats.
3. Automated verification. Before it reaches the store, the code goes through static analysis, runs in an isolated test environment and has its behaviour, performance and accessibility checked in every format. Anything that fails the checks goes back to the generation stage.
4. Review and refinement. The component appears in the editor like any other section: it can be previewed, placed, customised and refined further with new instructions, such as “update it every five seconds” or “show it only on the product page”.
5. Publishing. When you publish, the component joins the store snapshot with its version pinned, so what the visitor sees is exactly what was approved.

Isolated execution

A generated component never runs with the same privileges as the platform. Each one runs in its own isolated environment, with no access to the rest of the page, to customer sessions or to credentials of any kind.

Published stores already enforce a strict content security policy today: only scripts whose cryptographic hash (SHA-256) has been authorised by the platform are executed, and any other is blocked by the browser. Custom components will follow the same principle: only verified and approved code ever runs.

Permission-based data access

The component does not talk to the database. It accesses information through platform interfaces, and only the capabilities it declares —for example, the number of visitors online, the product catalog or cart events—, following the principle of least privilege. In the case of active visitors, the figure is an aggregated, anonymous count: no component can identify a person.

Versions and control

Every change to a component creates a new version. You can compare, undo or roll back to a previous version at any time, and remove the component from the store without affecting the rest of the page.

Technology

• Editor built with React and TypeScript.
• Server on Node.js with TypeScript, hosted on Render.
• PostgreSQL database, on Supabase.
• Email through Resend, and this site served through Cloudflare.

The protection measures of this architecture are described in Security and privacy.