Explore a Different Way to Build Your Website

A website built around the business—not added to it

With a conventional setup, a business might buy hosting, install a content management system, add a form plugin, connect an email provider, open a payment account, subscribe to a customer relationship system and add a separate membership platform. Each service has its own login, billing model, data structure and update cycle.

The platform uses a different architecture. The Business Account acts as the ownership and administration hub. From there, the owner deploys a customer-facing WebApp. Modules are then used to add the functions the business requires, while credits pay for infrastructure and metered services such as hosting, storage, email and AI usage.

This structure is important because the website, customer records, purchases and protected content are designed to work together. A customer does not have to be passed awkwardly between unrelated systems for every interaction.

Your public website is part of the WebApp

The platform includes a Pages Manager for creating public and protected pages. Public pages can be used for a homepage, landing pages, information pages, sales pages, policies and articles. Each page receives its own permalink, and public pages include controls for search titles, descriptions, indexation and Open Graph information for social sharing.

Content can be created with a rich text editor, including text, images, links and basic layouts. Pages can be saved as drafts, previewed, cloned and activated when ready. A custom domain can be connected for professional branding, custom sender email addresses and automatically provisioned SSL/TLS.

• Public website and landing pages
• Protected internal pages
• Custom page URLs
• SEO titles and descriptions
• Indexing controls
• Social sharing information
• Draft, preview and clone functions
• Custom domain and SSL/TLS

The key difference is that these pages do not sit in isolation. They can connect directly to products, customer access, contact records, email campaigns and checkouts within the same WebApp.

An isolated cloud environment for each WebApp

According to the platform’s current documentation, each deployed WebApp runs in an isolated environment with its own database, storage and compute resources. This differs from a typical shared software service in which many customers operate inside the same application and database structure.

For the business owner, the practical benefit is separation. Customer data belongs to the business environment, media is stored in its own storage area, and application resources are not simply a page inside somebody else’s shared account. The platform provider manages the underlying cloud deployment, while the owner manages the business through the Business Account and WebApp dashboards.

WebApps can initially be deployed to a subdomain provided by the platform and later connected to a custom domain. The platform uses edge infrastructure for global delivery, and changes to installed modules are applied through a controlled redeployment process while the application remains available.

One environment for the website and the tools behind it

The modular structure means that a business can begin with the functions it needs and add more as its requirements develop. Essential system modules are installed with the WebApp, while other modules may be free, credit-based or licence-based.

Sell products, services, subscriptions or access

The platform separates the product from the offer. The product defines what the customer receives, while the offer controls how it is sold. This makes it possible to create different prices, billing terms and campaign checkouts for the same underlying product.

Offers can use one-time or recurring payments. Subscription options can include billing periods, a defined number of cycles and optional trial periods. Products can represent software access, digital products, memberships, courses or other services, with variants used for different packages or access levels.

For card payments, a business can use the platform’s own payment service, where the platform operates as Merchant of Record, or connect Stripe Standard. The platform’s payment service is designed to simplify payment setup and handle areas such as payment processing, chargebacks and compliance. Stripe gives the seller a direct processor relationship and more responsibility. The best choice depends on geography, business structure, fees and the desired level of control.

Checkouts can support cards and, where available through the configured processor, Apple Pay and Google Pay. Purchases are recorded against the customer, invoices are generated, and access entitlements can be managed from the contact record.

A public website can grow into a customer or member portal

A business does not have to use every part of the platform from the beginning. It can start with public website pages and later introduce logins, protected information, paid content or recurring access.

Internal pages can be restricted according to product and module entitlements. That makes the portal relevant for courses, documentation, digital products, customer resources, membership content and other information that should only be available to selected users.

For an association or club, this architecture also creates a potential path beyond the public homepage. A solution may begin with news, activities, team information and sponsor pages, while later modules or custom development can support member access, paid subscriptions or more specialised workflows.

A usage-based model instead of a conventional software bundle

Many business platforms charge according to plans, user seats, feature tiers or the number of stored contacts. This platform instead uses credits as an internal payment mechanism for services such as hosting and compute resources, storage, bandwidth, email sending, AI usage and transaction processing.

This changes the cost structure. Storing contacts is not presented as the same kind of metered activity as sending messages to them. AI costs relate to actual model usage, while cloud activity is charged according to resource consumption. Credits can be added manually, transferred from a personal account or replenished automatically when the business balance falls below a chosen threshold.

The platform’s stated position is “no monthly fees” and “pay for what you use.” In practical terms, this should be understood as the absence of a compulsory conventional feature-tier subscription for the integrated platform. A running business still consumes paid resources, and some modules may require credits or a separate licence. Businesses should therefore assess expected usage rather than interpreting the platform as cost-free hosting.

Start with the standard modules—and extend when necessary

For non-technical owners, the standard modules provide an administrative interface for the most common business functions. For developers, the platform also provides a command-line workflow for pulling a WebApp project, creating custom modules and submitting modules for review and distribution.

This creates two possible paths:

1. Use the platform as provided. Configure pages, products, offers, contacts, email, portal access and AI support through the available modules.
2. Build on top of it. Use the developer tooling and module architecture when the business needs custom features or integrations beyond the standard interface.

The developer model is significant because the platform is not positioned only as a closed page builder. It is intended to provide the authentication, database, storage, payments, email and administration foundations on which additional applications can be built.

Ownership can also be managed at the business level. Team members receive role-based access, and the platform’s materials describe the ability to transfer the Business Account—including its WebApp and business data—if the business is sold.

An honest assessment of the new platform

This platform offers a compelling alternative to building a website from unrelated tools, but it is important to evaluate the current platform rather than only its long-term vision.

The current Pages Manager supports public and protected pages, rich text content, SEO settings and basic layouts. However, the documentation also states that more advanced Developer Mode and AI-assisted page customisation are still being developed. Organisations requiring a highly bespoke visual website should therefore examine the current editing experience before deciding.

Similarly, an AI coding assistant is described in the documentation as upcoming. The existing CLI and module workflow should not be confused with unreleased functionality.

Who may benefit from this approach?

This platform may be particularly relevant for businesses and organisations that want their website to become an operational platform rather than remain a digital brochure.

Potential use cases include:

• consultants and agencies selling services or access;
• course creators and businesses delivering protected content;
• digital product and subscription businesses;
• organisations that want CRM, email and payments in the same environment;
• developers who want a prebuilt business infrastructure rather than starting with authentication, databases and payment plumbing;
• associations that want to start with a public website and retain a route toward member access and payment functions.

Questions to ask before choosing

1. Can the current page tools reproduce the design and content structure we need?
2. Which required functions are standard modules, and which would need custom development?
3. How many credits will our expected hosting, email, AI and payment activity consume?
4. Should we use the platform’s own payment service or our own Stripe account for card processing?
5. Which data can we export, and how would we migrate if our needs change?
6. Who will be responsible for content, module updates, custom code and ongoing administration?

A different way to think about a website

The most interesting part of the platform is not simply that it can publish pages. Many systems can do that. The difference is the idea that the page, the customer record, the payment, the access right, the email and the support conversation should belong to the same business environment from the beginning.

For a simple information website, that may be more infrastructure than necessary. For an organisation that expects to sell, communicate, provide protected resources or develop custom digital services, it can remove a significant amount of integration work.

The right decision is not whether this model is universally better than PHP, a traditional CMS or another hosted platform. The question is whether an integrated WebApp gives your business a simpler, more maintainable path from the website you need today to the digital services you may need tomorrow.