Kiina (kiina.redbroomsoftware.com)

The productive-output dashboard for architecture practices — la casa del tiempo. Each construction project with its progress, its budget and its deviation in one view, plus shareable views towards the client. Kiina reads productive output from Colectiva through a versioned contract; it never implements payments.

URL: https://kiina.redbroomsoftware.comStatus: LIVE Tier: T2 (vertical SaaS primitive)

T1 apps are indispensable horizontal primitives. T2 apps are vertical SaaS or single-domain primitives — primitive-like in their domain but not universal dependencies.

Read this first: Kiina is a consumer, not a producer

Most pages in this section document an API you can call. Kiina does not expose one. It has no /api/* surface, and its sends / receives in the app registry are deliberately empty.

That is not an omission waiting to be filled — it is the design. Kiina is a reading surface over work that is recorded elsewhere:

• the money and the project ledger live in Colectiva (obras and their expenses);
• identity and access live in the ecosystem OAuth issuer plus Kiina's own read_grants;
• the commercial offer lives in the SDK (OFFERINGS.kiina_saas).

If you are integrating with the construction vertical, you almost certainly want Colectiva, not this page. What follows is here so you know where the boundary is and why calling Kiina is not a thing you can do.

What it consumes

One endpoint, one direction:

GET  {colectiva}/api/ecosystem/outputs/obra/{workspaceId}/{obraId}
     X-API-Key: <ecosystem key scoped to the workspace>

It answers with a ProductiveOutputView — an aggregate-only projection ({ totalCents } and progress figures). Line-level expense data never crosses the boundary. The contract is validated with a strict schema on Kiina's side, so a producer that adds a field does not silently change what a consumer renders, and a producer that removes one fails loudly instead of rendering a blank number.

The tier of the caller is stamped by the server (ecosystem-client), not asserted by the client.

What it does with it

• Project view — progress, budget consumed, and the gap between physical and financial advance. A project can be 40% built and 70% spent; putting both figures side by side is the product.
• Vision module — a photo of a space plus a style returns a restyle proposal with an approximate quote. Runs on Colectiva's AI proxy; metered.
• Shared views (read_grants) — a practice grants its client sight of one project. The grantee sees only what was granted; there is no "share everything" switch.

Access model

There is no public sign-up API. A visitor lands on the public pages (/, /precios, /prueba), leaves a request, and access is opened by hand. Sessions come from the ecosystem OAuth issuer; authorisation over a specific project comes from read_grants, re-read per request rather than carried in the token.

Pricing

Two self-serve levels live in the SDK as OFFERINGS.kiina_saas (Solo and Despacho, MXN/month before VAT). They are registered with status: 'proposed', not authorized — which means the Patadas checkout refuses to close on them by design. Read the amounts from the SDK, never from a copy: that is the whole reason the offerings registry exists.

A construction company that needs several projects plus accounting and payroll is a different offer (obra_observabilidad, consultative, with implementation) — not this one.

Related

• Colectiva (Payments) — where the project ledger and the money actually live
• Camino (Identity + CRM) — where a Kiina access request lands as a lead