Pure-Client Products

“Pure-client product” does not mean “no backend at all.” It means you stop rebuilding the AI backend for every product.

Downcity lets a new product start from the frontend, extension, or app and connect to an already deployed Federation. You can validate the product UX first, then decide how much product-specific backend you really need.

Good fits

• lightweight web tools
• Chrome extensions
• desktop shells
• mobile entries
• client demos
• internal tools

Recommended boundary

The client owns:

• UI and interaction
• calling User City
• using the product-configured bureau_id when login starts
• storing or refreshing user_token

The Federation owns:

• provider keys
• model directory
• user_token verification
• service routing
• usage records
• hooks and billing logic

The most common minimum shape

City frontend
  ↓
Your login / token-issuing endpoint
  ↓
Federation

That product backend can stay very thin at first:

• user login
• FederationAdmin.tokens.apply()
• returning user_token to the client

Normal service requests do not submit bureau_id again; Federation reads it from the verified user_token.

Why this fits early products better

• you stop copying provider integrations for every AI idea
• the frontend can ship much earlier
• multiple products share one AI calling, logging, and quota layer

If the product gets more complex later, then add more business backend. Do not duplicate the whole AI infrastructure on day one.