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.

What the three have in common is easier to see as a staffing question. A business on this platform is not hiring a marketing operator to send campaigns, an analyst to find out what is selling, a bookkeeper to keep the ledger, or a developer to make the tools talk to each other. Those are jobs the engine does. What is left is the part that was always the owner's: deciding what to sell, what to charge, who to reward and when to discount. Decisions stay with the person who owns the business; execution is the software's problem.

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.

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.

Yes — three ways, depending on what you are moving from. A spreadsheet import that maps your columns, previews the result and lets you resolve conflicts before anything commits. A scheduled feed from a URL, with a dry run showing exactly what would be created or updated before you confirm. Or a direct connection to a store platform you already run, which gives real-time two-way stock sync rather than a copy that is stale the next morning.

The detail people actually worry about: a column your spreadsheet has and we do not is not dropped. It becomes one of your own custom fields, private to your admin until you choose to publish it.

No, and this is settled field by field rather than all or nothing. Every scheduled import carries a field ownership setting: for each field you say whether the import keeps it current or whether your own edit stands.

The defaults match how people actually work. How a product reads — name, description, images, brand — and how it is organised belong to you. Price and stock belong to the import, because that is what moves in your supplier's system. Any field can be moved either way. It is the question an agency asks about any scheduled sync, and the honest answer is that your copy is not at the mercy of a feed.

Any currency, and it is on every plan rather than held back for a higher tier. You add from the full international currency list — not a short curated handful — and each one either follows live market rates or uses a rate you set by hand.

You then map currencies to areas, so a shopper sees the price in the currency that makes sense where they are, with one nominated as the catch-all for everywhere you have not mapped.

Yes, once automatic tax is connected. The rate for each order's destination is calculated at the moment of sale — on the in-person till and the online store alike — and applied before the customer pays, so nobody receives a corrected amount afterwards. The order carries the breakdown, and a refund reverses the tax that was filed for it.

A single rate you set yourself works too, and doubles as the safety net: if the automatic service is briefly unreachable the sale is calculated on your own rate and marked as such. A sale is never blocked on tax. Where you are obliged to collect at all is configured in your tax provider's own account — we do not guess it for you.

The same engine, which is the whole difference. A walk-in sale runs through the same money calculation, reduces the same stock and posts to the same books as an online order — written as one transaction that records the sale, moves the stock, posts the accounting entries and updates the customer together.

The browser never computes the money: discounts, tax, the total are all calculated on the server by the same engine your storefront uses. One thing to know before you plan around it — it needs a connection. There is no offline mode today, and we would rather say so than have you find out at a busy counter.

Yes, but the shape is worth understanding before you plan around it: a store is either retail or wholesale, not both at the same time. A retail store graduates to wholesale — you request it, it is reviewed, and it is switched on. That is a transition rather than an addition, and you say at that point which kind of business you are: manufacturer, distributor, wholesaler or supplier.

Once it is on, the admin reframes itself for trade: the retail-only surfaces step aside and customers become buyers. Each buyer can have their own price list with quantity breaks and minimum order quantities, their own credit limit — a buyer who would go past it is stopped at confirmation until they pay down — and their own payment terms. What a buyer may see is set separately from what they are charged, so you can show someone the whole range and price only part of it.

If you genuinely need to trade both ways, that is two stores on the same platform rather than one store wearing two hats. Worth a conversation about how to set it up — talk to us.

No, and this is the thing worth comparing. On most hosted platforms the plan price is the smallest number on the bill: reviews are an app, returns are an app, loyalty and reporting and a decent search are each a separate vendor with its own charge, login and support queue — and none of them knows what the others are doing, so you become the integration layer.

These are built into the engine instead. Every plan includes the commerce core, the in-store point of sale, selling in more than one currency, gift cards, promotions, campaigns, tax calculation, multi-carrier shipping with live rates and printed labels, and first-party storefront analytics. Higher plans add returns, expenses, collections, double-entry accounting, and search and recommendations. They are line items on a plan, not vendors — one bill, one login, and one set of books that all of it writes to. When the pricing engine and the promotion engine are the same system, they cannot sell something below cost without a person deciding to.

We are not going to tell you what that saves against a comparable stack, because we have not measured it and an invented number would be worth nothing to you. The structural claim is the honest one: one subscription rather than nine, and nothing between them for you to maintain. What is on each plan →

No platform anticipates every business, so the honest question is what happens at the edge of ours. There are nine named seams — payment, shipping, tax, email, marketing, SMS, sales channel, authentication and accounting. Describe what you need in plain language; the platform drafts it against the live contracts of its own interfaces and opens it in the browser for you to read, edit and test against a sample event before anything is switched on. No separate hosting account, no second deployment.

Three qualifications we would rather state than have you find. Simple automations are genuinely built in a guided form with no code; the deeper ones are real TypeScript, and you should read what you are running. The drafting is billed as credits rather than folded into the subscription. And payments is the one seam we treat as serious — it moves real money and it deserves a developer's eye.

Three things, and saying so is more useful than implying otherwise.

It does not design storefronts. There is no theme editor and there will not be one — that is Anvil, a separate product, priced separately. It does not let you swap out the engine: search, recommendations, analytics, reviews, gift cards, returns and messaging are deliberately not extension points, because they are what you are buying — the seams are at the edges, where businesses genuinely differ. And a marketplace or an enterprise rollout is not a plan you click; those are scoping conversations, because they are different systems with different questions. Start one →

No — and this is structural, not a policy we could change our minds about. A cart can span several sellers, the shopper pays once, and the payment processor splits the payment and settles each seller's share directly to them.

Neither the marketplace operator nor Tybrite ever takes custody of the customer's money. That is the property that keeps an operator outside money-transmitter regulation, which is a licensing problem you do not want to discover after launch. You set the commission rules — flat, tiered by volume, per category or per seller — and never touch the funds.

Then you plug in your own, which is unusual enough to be worth spelling out. The provider behind a capability can be swapped per store — payments, shipping rates, tax, email, text messaging, marketing sync, sales channels, even shopper sign-in. The built-in option stays the default until you switch.

You also choose where it runs: hosted by us, or on your own infrastructure, where we call a signed endpoint you run and your provider's credentials never leave your systems. Galactic Core stays the authority over money either way — a payment provider's claimed result and a shipping provider's returned rate are both re-checked server-side. That is normally a level of control you only get by hosting the entire platform yourself.

Galactic Core starts at $29 a month (Starter), with Growth at $79 and Premium at $199, and every plan starts with a free month. The full breakdown is on Galactic Core pricing. Agencies pay a published wholesale rate per client store — just over half of each plan stays with the agency — set out on the white-label page.

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.

Yes. Anvil white-labels on the same terms as the engine, and independently of it — so your clients can describe a store in your studio, under your brand, and have it come out wired to a commerce engine that also carries your name. That is the whole stack a small software business would otherwise spend years building, available as something you sell rather than something you write. Taking one layer does not commit you to the other; they are priced and adopted separately.

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.

No entry fee, no seat minimum, no annual commitment. You pay a wholesale rate for each client store that is live and trading — $13.84, $37.63 or $94.45 a month, against plans Galactic Core sells direct at $29, $79 and $199 — from your fifth store; the first four are at full retail. A client on a free trial costs you nothing until it converts. A marketplace across your clients is $1,000 a month including 100 of them, then $20 for each beyond. 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. See the economics →

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.

It acts — and the interesting part is where the line sits. It is drawn by consequence, not confidence.

Anything reversible it does directly: reorganising the catalogue, re-filing a mis-categorised product, activating a category, building a collection. If one is wrong, someone changes it back and no customer ever knew — and every action is written to an audit log regardless.

Anything that moves money is prepared as a draft you approve. A gift card creates a balance someone can spend and emails them the moment it exists; a promotion discounts every matching order, continuously, until a person stops it. Neither is undone by deleting a row, because the effect has already left the building. So they are proposed, and a person approves them.

On Suggestions, one page listing everything the assistant has prepared — waiting, approved and rejected — filterable by type, each showing what is being proposed, the reasoning in plain words, and when it expires. It appears in the sidebar only when something is waiting, with a count, so an empty rail means nothing needs you rather than that the page has gone. It is on every plan, because the assistant is.

Two choices in it are worth knowing. Rejecting keeps the record rather than deleting it — the assistant wrote these from your own numbers, and what was declined is worth as much as what was taken. And a suggestion nobody decides expires on its own, with the expired count shown on the page: expiring is not rejecting, and a rising number means they are arriving faster than anyone is deciding them.

Approving needs the same permission as doing the thing by hand, plus the separate right to approve suggestions — which an owner can give a teammate without changing anything else they can do. Checked on the server, so it cannot be bypassed from the browser.

No — nothing listed there is live. A suggestion is a pointer to a real draft row in the table it belongs to rather than a stored copy of one, so there is exactly one version of the truth and one place it can change.

What makes that safe nearly went wrong, and is worth stating. Gift cards and promotions already notified the customer the moment a row appeared, so writing a draft would have sent the email before the approval. Those notifications are now gated on the thing becoming active rather than on the row existing — a draft is inert in the strongest available sense, a real row the rest of the system declines to act on. Approving is the moment it becomes real: the gift card is issued and sent, the promotion starts discounting.

A margin guard, and the important thing about it is where it lives. It is described in the prompt, so the model usually does not try — and it is enforced on the server, so it does not matter when the model does. A prompt is guidance for a cooperative participant; there is no version of it that is access control.

It also declines on missing information rather than guessing. The assistant knows how much of the catalogue has usable cost data, and when that coverage is too thin it refuses margin-affecting actions instead of producing a confident number from thin data. Knowing the difference between a number it has and a number it can produce is most of what makes it trustworthy.

Who may approve a draft is likewise a permission checked against real membership on the server. The browser also hides the button, which is a courtesy — a permission enforced only in the interface is not enforced.

Yes, and the distinction matters more than it sounds. Ask for something ongoing — keep the featured collection showing what is actually selling, check for slow stock every week — and it becomes a standing rule that re-evaluates on a schedule.

Re-evaluates is the word doing the work. Each run re-reads the store's current figures and decides from those, so a rule written in March to surface best sellers surfaces different products in September without anyone editing it: the rule names a criterion rather than a list. An event-driven automation performs a defined action after a trigger — useful, predictable, and blind to whether the action is still right.

The same line holds as before. Reversible merchandising runs unattended, because a wrong decision costs an afternoon. Anything touching money still prepares a draft and waits.

Yes — opt-in per store. The assistant watches how the store is performing and keeps the rule set current on its own: setting up rules worth running, retuning ones whose thresholds have drifted from the business, retiring ones that have stopped producing anything.

It is worth being exact about what that changes. It changes who maintains the rules. It does not change what a rule may do — discounts, gift cards and price changes are still prepared as drafts and still wait for a person, on the same pages and under the same permission as before. What becomes automatic is the upkeep, not the spending.

Two constraints hold it in place, and neither is left to the assistant's judgement. A rule you paused stays paused — pausing is an instruction, not an untidy state to be tidied, and nothing restarts it. And nothing happens without a record: every adjustment is logged with the figures behind it, kept separate from the log of actions, so what changed in my shop and what changed about my rules stay two questions with two answers.

It keeps working after the build, and this is the part people miss. A storefront is generated against the store as it exists that day — but a store is not static. Reviews arrive. Promotions start running. Collections fill out. Capabilities that had no data behind them become real. A storefront built in March does not know about any of it.

Anvil watches for exactly that and proposes the matching storefront integration when a capability crosses into being worth showing — a reviews section once there are reviews, a popular-now shelf once there is enough behaviour to fill it. Shipping those on day one is noise; shipping them the week they light up is the point.

Same posture as the engine's assistant, for the same reason: it is opt-in, you preview before approving, and nothing goes live without a click. Anvil proposes; a person decides. Anvil →

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.

Yes — an official, fully typed TypeScript SDK on npm, covering the storefront surface: catalogue, cart, checkout, orders, payments, customers, search, recommendations, promotions, gift cards, reviews, returns, messaging and wholesale.

To be straight about it, TypeScript is the only first-party SDK today. The API underneath is plain HTTP, so any language works — you just write the calls yourself. Documentation →

Yes, and it is separated rather than flagged. Every store has a live and a test key pair; the test key selects an isolated sandbox. Sandbox orders never appear in your order list, never move your stock and never reach your reports or revenue — and a live key is refused outright on sandbox operations, so nobody reaches your real store by mistake.

The useful part is the tooling around it: reset to start clean, time travel to move the sandbox clock forward so an abandoned-cart window or a stock hold expires now rather than in three days, webhook replay to re-send an event your store already produced so you can fix a handler without recreating the order behind it, and seeding for the promotions and gift cards a test needs.

They retry, and then they stop rather than hammering you. Each delivery is signed, so you can verify it genuinely came from us. Failures retry on a back-off schedule, and an endpoint that keeps failing is disabled rather than hit forever — re-enabling clears that state.

You also get a full event log: every attempt with its status code, latency and response body, a manual retry, and a send-test that fires a real signed request so you can check a handler before you depend on it.

The server is the price authority, which is a stronger guarantee than signing alone. Checkout never trusts client-supplied money: the server recomputes every item price from the live catalogue and checks each discount against a real entitlement, so a signed but dishonest payload is still rejected.

Around that: two key types — a publishable key that is safe in a browser and a secret key that is server-side only — and the sensitive writes, creating orders and starting payments, additionally require a signature. Creates take an idempotency key, so a network retry cannot quietly become a second order.

Yes — there is a consent flow, so nobody is pasting a secret key into someone else's tool. A developer registers their app; once approved they ask a merchant to connect, and the merchant approves on a screen listing the specific permissions requested rather than all-or-nothing. The app gets its own scoped keys, including its own signing secret, so it never needs the merchant's. Disconnecting is one action from either side.

One thing worth stating plainly in both directions: apps are reviewed before they go live. That is reassuring if you are a merchant and it is friction if you are the developer.

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, and two details are what make it worth anything. It runs as a separate site, independent of the platform — a status page hosted on the thing it reports on goes down exactly when you need it. And it reports per service rather than as one green dot, checked every five minutes. You can subscribe rather than finding out yourself.

It is kept for 90 days and you can bring it back — restoring returns the record exactly as it was, with everything that belonged to it. There is no separate bin to hunt through: each list has an active and deleted filter, and you restore from the same place you deleted.

The more important half: deleting never unpicks your history. Past orders, invoices, returns and accounting entries that reference the record keep working and keep showing what they always showed.

Yes, whenever you want, and as a complete copy rather than a page-by-page download. The store owner asks for an export and gets an archive of spreadsheets — one file per data set, organised by area: catalogue, orders, customers, inventory, accounting, finance, marketing, content, messaging, wholesale, pricing and settings — with a manifest listing the row count of every file.

Credentials are always stripped, so the archive is safe to keep or hand to someone. Your own cost and margin figures are included, because they are your business data and an export that withheld them would not be a copy of your business.

Yes — 20,000 buyers arriving in the same second against limited stock is the shape this is built for, and the reason is structural rather than a matter of provisioning.

Stock is decided at the edge, in memory, rather than every buyer contending on the same database row. So a synchronised drop forms no queue behind row locks, and a sold out answer never reaches the database at all — which is what keeps the losers of a drop from being the thing that takes the shop down.

The property that actually matters under that load is exactness: zero overselling and zero double-granting. The units that exist are reserved, everyone else gets a clean sold-out. Nobody is sold something that is not there, and nobody's order is quietly dropped to make the numbers add up.

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.