At a certain point, your app stops being one thing.
Auth and identity sit in one place. Billing lives somewhere else. There's a customer-facing API, a reporting layer, and services that each grew up around a team that owned them. You separated them for good reasons—clear ownership, independent deployments, teams that can move without stepping on each other. That separation is healthy. It's how serious systems get built.
But it creates a question smaller apps never face: what happens when multiple workspaces need the same thing?
Picture a single Xano instance hosting four workspaces—core, payments, analytics, and a customer-facing app. The three domain workspaces each do one thing well; core holds the shared stuff. The moment you have a pricing rule, an auth policy, and a canonical customer record that all three depend on, you have to decide where that shared logic lives.
This article is about helping you make that decision. Read on, and check out the video below to watch Cameron Booth walk you through it!
You have exactly two choices
Option A: put it in core once, and have every workspace call in. One pricing rule, one place, and payments, analytics, and the customer app all pull from it when they need it.
Option B: copy it into each workspace, so every team owns its own version. Each domain carries its own copy of the auth logic and the pricing rules, embedded right where it runs.
Here's the part worth sitting with: both are valid. Plenty of production systems use both patterns for different pieces of the same architecture. The mistake is almost never picking the "wrong" one—it's letting the choice happen by accident, shipping the feature without ever stopping to ask the question. This post is about asking it on purpose.
The centralized pattern
The first pattern is what most mature Xano builds converge on for their genuinely shared concerns. Core sits in the middle, and the domain workspaces have arrows pointing into it. That direction is the whole point: domains call core and pull what they don't own; core doesn't call them back.
So what earns a place in core? Auth decisions—no workspace should decide on its own who's logged in. The canonical customer record, so payments and analytics read the same customer rather than two subtly different ones. Shared business rules like pricing tiers, plan limits, and feature flags. Shared third-party integrations you'd rather manage once than wire up in every workspace. Often a shared database layer too. It's the same idea behind pulling business logic out of application code and putting it behind governed APIs: one rule, one home, many consumers.
Why teams centralize
The headline benefit is simple enough to put on a slide: change it once, and every workspace gets it. Change a pricing rule in core, and payments, analytics, and the customer app all inherit the update. There are no four copies to sync, and no anxiety about which workspace is still running last quarter's version. When the rule has a single home, "which version is in production?" has a definite answer, because there is only one.
Governance and compliance follow directly. When your security logic, audit trails, and compliance rules live in one place, certifying them means looking in one place—not assembling evidence from four workspaces and hoping you found all of it. It's also the foundation that makes AI-generated code safe to adopt at speed: when the canonical rule lives behind a governed endpoint, an agent calls it instead of inventing a new interpretation wherever it happens to be working.
There's a quieter benefit too: ownership clarity. As teams grow, "where does auth live?" needs exactly one answer, and tribal knowledge in one engineer's head is a real maintenance cost. When the logic is visible in a single governed layer, the people who own a domain can read the rules that govern it instead of filing a ticket and waiting for a translation. And most practically: you build the customer lookup once and three workspaces use it, instead of building it four times and keeping four copies in sync indefinitely.
The distributed pattern
The second pattern has no center. Four workspaces, each holding its own copy of the shared logic, each able to move on its own.
The case for it is real. Sometimes teams are genuinely autonomous, with different release cadences, and a shared dependency only slows them down. Sometimes the logic only looks shared and actually differs per domain—what reads as "the same rule" is three rules wearing the same name. Sometimes a latency-sensitive hot path can't afford a cross-workspace hop. And sometimes you're early enough that you haven't found your shared boundaries yet, and committing to them prematurely is its own mistake.
The thing to respect about this pattern is drift. Four copies of a rule will, over time, stop being the same rule. This is what bites teams twelve to eighteen months in: the auth logic in payments gets patched for a bug, analytics doesn't pick up the patch for two sprints, and the customer app runs a slightly different version a contractor wrote. Now you have three diverging implementations of something that was supposed to be one thing—and nothing that tells you they've diverged.
Distributing is a perfectly good choice when you make it deliberately. It only becomes a problem when it's the default nobody actually decided on.
Don't forget the data layer
Logic isn't the only thing worth centralizing—your data pipeline deserves the same treatment. A common shape puts Snowflake on one side as the source of record for historical and analytical data, and the Xano database on the other as the fast application layer your API reads hit. A function stack in core connects them: Xano's Snowflake connector lets you query the warehouse directly, reshape the data, and write it into the Xano database. You build that pipeline once, in core, instead of standing up a separate copy inside every workspace that happens to need warehouse data. Snowflake stays the source of truth; the Xano database stays fast; and core owns the path between them.
Put it all together and the full picture is core at the top—auth, shared rules, Snowflake, the Xano database, governance—with three domain workspaces below it, each making API calls up into core for the things they don't own. This is where a serious multi-workspace Xano build tends to end up. You don't architect it on day one; you grow into it.
How to actually decide
Xano's recommendation is short enough to remember: centralize for consistency, distribute for speed.
Centralize the things where inconsistency is expensive or dangerous—identity and auth, the canonical customer record, pricing and plan rules, compliance and audit logic, external integrations. Get one of these wrong, and it's wrong everywhere at once. That's exactly when you want a single source of truth rather than four chances to diverge.
Distribute the things that change per sprint, differ by domain, or need tuning for one team's read pattern—domain-specific APIs, fast-moving features, UX-specific transforms, domain caches. These are the places where a shared dependency costs more than it protects.
The rule that resolves the hard cases: optimize for the cost of change, not the cost of building. Things that must stay consistent are expensive to change when distributed across four copies; things that move fast are expensive to change when locked behind a shared dependency. So don't reason from your current state—reason from your rate of change.
Try the exercise
You can run this on your current build, or your next one, in about fifteen minutes. First, list every workspace and what it actually owns—not just its name, but what it genuinely does. If you can't name what a workspace owns in a sentence, define it before going further. Naming is design. Second, list the shared concerns: auth, the customer record, pricing, integrations—anything more than one workspace needs. Third, next to each, write one word: centralize or distribute, using the cost-of-change framing to decide.
And if you're on a single workspace today, run the same exercise inward: dissect what it does, and figure out which concerns would eventually want their own workspace and which belong in core.
That single page is the architecture most teams never write down, and it's the difference between a system you designed and one that just happened to you. If you want to see what a governed, centralized logic layer looks like in practice, request a demo to walk through how it fits your architecture—or try Xano for free and centralize your first shared concern today.
