The two-tool tax
Think about what a small business actually runs on. There’s the inside: the system where staff track customers, orders, inventory, bookings, applications — the thing with logins and permissions. And there’s the outside: the website where the public browses what you offer, submits an enquiry, or signs up.
Normally those are two separate products. You build the internal system in one tool (or a spreadsheet), and the website in another — a site builder, a CMS, whatever. Then the real cost shows up: the two don’t talk. A lead comes in through the website contact form and lands in an inbox, and someone re-types it into the system. Your product list lives in the database and in the website, and they drift apart the first time someone updates one and forgets the other. You’re paying a tax in copied data and manual re-entry, forever.
That gap — between the app your team uses and the website your customers see — is exactly what AppeneriX closes.
What AppeneriX actually generates
From a single description (or an uploaded spreadsheet), AppeneriX can produce both halves:
- The internal system. Real entities and relationships, forms and grids, dashboards, roles and permissions, workflow — the multi-user back-office app your team logs into. This is the part most people already associate with us.
- The public website. A public-facing site — landing pages, a marketing site, a catalog, public forms — that visitors reach without any login, published under its own address.
Internally these are just two kinds of page on one platform: the internal list and master–detail pages your staff use, and public pages the world sees. Same project, same data, two audiences.
The one sentence that matters: the form on your public website writes into the same table your internal app reads from. A booking request submitted on the site is a booking your staff see in the back office a second later — because it’s literally the same record, not a copy passed between two systems.
Why “same live data” is the whole point
Plenty of tools will generate a nice-looking website. What makes this different is that the website isn’t a static brochure sitting next to your data — it’s bound to it. Two directions matter:
- Public forms write in. A contact form, an application, a booking, a “request a quote” — when a visitor submits it, the record is created in your entity, with the same validation and rules your internal app enforces. It shows up in your grids and dashboards immediately. Nobody re-keys anything.
- Public sections read out. A catalog, a product grid, a listing page can be bound to an entity, so when your team updates a price or adds an item in the back office, the public site reflects it — because it’s reading the live record, not a snapshot someone pasted in.
That’s the difference between “a website and a database” and “a website on a database.” One backbone of truth, two faces on it.
How it works in practice
- Describe your business. Tell Ailock what you do — or upload the spreadsheet you already use. It builds the internal system: the entities, forms, grids, and permissions.
- Say yes to the site. Once the backend exists, Ailock offers to generate the matching public website, already aware of the entities it just created — so the catalog knows about your products and the enquiry form knows where to file a lead.
- Shape it like a website builder. The public side is a block-based builder: pick and reorder sections (hero, feature grid, gallery, pricing, contact form…), apply a theme, drop in AI-generated hero and section images, and edit copy inline. Ask Ailock to “add an About page” and you get a second linked page under the same site.
- Publish. The site goes live under its own address (its slug), on the same platform as your app. No separate hosting to wire up.
And because everything is described as metadata rather than throwaway code, you keep changing both halves later — add a field to the internal form, add a section to the public page — without a developer and without the two drifting apart.
What the public side supports today
- A block-based website builder — themed, reorderable sections with inline editing, closer to a modern site builder than a form generator.
- Multiple linked pages — a home page plus About, contact, catalog, or other secondary pages under one site.
- AI-generated imagery — hero and section visuals produced automatically as part of generation.
- Entity-bound forms — public forms that write into your real entities, with your rules applied.
- Entity-bound content — catalog and listing sections that read from your live data.
The honest boundaries
We’d rather you know the edges than find them later. Today the public side is at its best for marketing sites, catalogs, and lead capture — the “show what we do and let people get in touch or apply” shape. Two things are deliberately not there yet:
- Visitor logins are early. Accounts for the public visitors of your site (a member portal, a “my requests” area for customers) are in progress rather than fully shipped. Your staff logins for the internal app are mature; it’s consumer-facing accounts that are still landing.
- There’s no shopping cart or checkout yet. You can present a catalog and take enquiries, but taking payment for a basket of items on the public site is a planned capability, not a current one. If “sell products online with a cart” is your core requirement today, that specific piece isn’t ready.
Everything else above — the generated site, the block builder, multiple pages, AI images, and forms and content bound to your live data — you can use now.
Why this is the big win
The reason this matters more than it sounds: it collapses two projects and two bills into one, and it deletes the single most common source of bad data in a small business — the human re-typing things from the website into the system. When the front door and the back office are the same app on the same data, the enquiry is already a record, the catalog is already the database, and there’s nothing to keep in sync because there was only ever one copy.