Tybrite Labs is a commerce infrastructure company. We build the systems modern commerce runs on — the engine behind a business rather than the shopfront in front of it. In practice that is three things: Galactic Core runs the operation, Anvil generates the storefronts, and TLDP carries the deliveries.

GalacticOS is the commerce operating system — the three layers as one system, with one set of records underneath them: Galactic Core as the flagship commerce backend, Anvil as the creative layer, TLDP as the delivery network. You run your commerce operations on it. What you don't do is buy it as a separate line item: you adopt it a layer at a time, which is why there is no GalacticOS account or subdomain to sign up for. Take one layer and you are already running it. GalacticOS →

Three groups, and they arrive by different doors. Merchants run their business on Galactic Core and Anvil. Agencies run their own branded commerce platform on top of ours — see white-label. Developers build against the API directly, whether or not they ever touch our interfaces.

Running. Galactic Core and Anvil are in production, serving real businesses today. TLDP is in public research preview and gradual rollout — deployed, with a live versioned API and a verified Galactic Core integration, while courier coverage keeps expanding. We say which is which on every page rather than flattening the difference.

We are a small, early team, and it is a fair thing to ask about infrastructure you intend to depend on. The honest trade: you get direct access to the people who actually build the system, and things change quickly — instead of a large support organisation and a slow roadmap. What is not a trade is whether the systems are real; they are in production and carrying live commerce.

It is the flagship commerce backend — catalog, checkout, payments, customers, inventory, accounting and analytics, as one system rather than a stack you assemble. The same core runs a single store, a multi-merchant marketplace, or a wholesale supply operation; what changes is configuration, not the platform underneath. Galactic Core →

The creative layer. Describe the store you want in plain language and Anvil generates a production storefront already wired to Galactic Core — catalog, checkout and customers connected from the first line rather than integrated afterwards. That wiring is the point; a generated site that is not connected to an engine is a picture of a shop. Anvil →

No. Galactic Core alone runs the whole operation, and plenty of businesses use it behind a storefront they already have. Anvil is simply the fastest way to get that storefront, and TLDP is a complete logistics platform in its own right. The one real dependency is deliberate: Anvil needs the engine, because a storefront generated against nothing would be a picture of a shop. Everything else is a choice. How the three fit together →

The Tybrite Logistics Developer Platform — one integration over many couriers, covering rates, orders, fulfilment, tracking, proof of delivery and returns, so adding a courier is a configuration change rather than a project. It is two-sided by design: businesses get couriers competing for every parcel, couriers get demand the moment they switch on. In public research preview and gradual rollout. TLDP →

Yes — it is API-first, so the storefront is a choice, not a requirement. Keep the front end you have and run the commerce operation underneath it. The developer documentation is at docs.tybritelabs.com.

Plan pricing lives on the product surfaces — Galactic Core pricing — rather than here, so there is one authoritative copy instead of two that drift apart. Agency wholesale pricing is set per agreement; talk to us.

It is how an agency runs its own commerce platform on Galactic Core and Anvil — your brand, your domain, your plans and prices, your billing account, your clients. An Embedded SaaS platform for agencies, and a primary route to market for us rather than a badge on a partner page. White-label →

No — and the difference is the whole point. Think of it as a Turnkey SaaS Franchise Kit: six things arrive together — the product, the packaging, the pricing, the billing, the storefront and the upkeep. A rebranded app would still leave you to invent the tiers, wire the billing and maintain the thing. What you supply is the clients, the brand and the price. See what's in the kit →

You do more than that. You define your own plans — including what each one grants — composed up to a ceiling set by your wholesale agreement. That is the part people usually get wrong: you are not re-labelling our tiers at a markup, you are building your own product out of the capability you have bought.

No. Your merchants pay you, on your own processor. We invoice you at your wholesale rate and take no share of the spread between what you charge and what you pay — the margin you build is entirely yours. We never touch your clients or their money.

The surfaces they use are yours — your brand, your domain, your emails. The honest boundary, which we would rather state than have you discover: a handful of wire-level values stay ours, because they are protocol rather than branding. Renaming them would describe an API nobody serves.

Both — this is new. TLDP is white-labellable too, so the whole stack, commerce and logistics, can run under one brand: your merchants ship through your logistics layer, and each courier invoice covering their deliveries carries your brand. It also runs the other way round — TLDP is a complete platform on its own, so a logistics operator can take it without adopting Galactic Core at all. One difference is worth knowing before you price it: on logistics you set your own prices and names, but the shipping tiers themselves stay ours, so you are re-pricing a plan rather than composing a new one.

Yes, and this is the part that separates the programme from a rebranded interface. You get a branded API host the day you are approved, you can publish the specification as your own — your server URL, your title, your key prefix — and a typed client library is generated and published under your own package name, from your own infrastructure with your own credential. We generate; you publish. Nobody here holds a key that could publish to your customers.

The specification regenerates as the platform gains capability, and your pipeline reads it on your schedule from a URL that is always correct. Staying current is a pull rather than a push — a scheduled run does nothing at all until something actually changed, so there is no maintenance burden sitting on anyone's desk.

Wholesale pricing is agreed per agency rather than published, because what you are buying depends on the ceiling you want. On timing: the platform is provisioned when you are approved, so the schedule that governs your launch is your own go-to-market, not our setup. Talk to us →

No — different things. White-label is a distribution layer: you run your own platform. Partners covers technology, app and implementation partnerships, where you build alongside us rather than resell.

Commerce that an agent can genuinely operate — read the real state of a business, decide, and act — because every operation is available over a permissioned API rather than locked behind a screen someone has to click. Most platforms expose a read-only slice and call it integration. The difference shows up the moment an agent has to change something.

It can act, within the scope it has been granted. Catalog, pricing, inventory, orders and fulfilment are writable, not merely readable — the operations an agent actually needs are first-class, rather than a reporting slice bolted onto a system that still expects a human to click the important parts.

Three things, and the third is the one that matters. Scope limits what a credential can touch. Sensitive actions require approval. And an agent that lacks the data to act correctly refuses rather than guessing — if a clearance needs cost prices and most of the catalog has none, the correct output is a refusal and a list of what is missing, not a confident wrong answer. That refusal is the feature; you can watch one happen in the simulation on the home page.

You do — yours to export or delete, on every plan. Data portability is not a feature we sell back to you; a platform that holds your records hostage is a platform you cannot safely leave, and that is not a relationship worth building.

No. Each store is isolated from every other, and that isolation is enforced by the platform rather than left to application code to remember on every query — which is the design decision that determines whether it actually holds.

With your payment processor. We do not store card numbers, and payouts go directly from the processor to your bank rather than routing through us — so your money never sits in an account we control.

Authorisation denies by default — anything not explicitly permitted is unreachable, rather than allowed until someone remembers to block it. Roles are never self-assignable, so no account can promote itself. Every public write is validated on the server for shape and size. And the permission rules are version-controlled and reviewed like any other code, because rules edited live in a console are rules nobody can audit.

Yes: status.tybritelabs.com shows live platform status and any incidents as they happen.

If you are a merchant, start on the surface itself — Galactic Core or Anvil. If you are an agency, or the question is larger than a signup form, talk to us first.

docs.tybritelabs.com — the API, authentication, and how to integrate.

Yes — beyond the products, we take on platform and integration engineering. Solutions → describes the practice, and contact is the way in.

support@tybritelabs.com for help, partnership@tybritelabs.com for partnerships and the white-label programme, and info@tybritelabs.com for anything else. A real person replies.