Start from evidence
A screen can be polished and still be wrong. Claims are tied to implemented code, recorded decisions or a named source.
About DCC
The builder behind Deck.
DCC designs, builds and operates Deck: a hosted platform for operational work, with Carbon as its first client tenant and reference implementation.
The position
One platform, written decisions, explicit boundaries.
Deck is not presented as a set of disconnected demos. Its product areas live in one repository, publish contracts at their boundaries and use a common design system across tenant-facing work.
The apex site stays separate from tenant workspaces. It can explain the product and start a conversation, but it does not receive or render a client's operational data.
Working rules
Three things the work has to keep
Keep the wall real
Tenant separation is enforced below the interface. Marketing language never substitutes for the database boundary.
Make mobile the baseline
Operational work happens away from a desk, so the smallest supported layout belongs in acceptance, not in cleanup.
The product
Built to outgrow the first client
Carbon is proof, not a fork
Carbon remains a client tenant on the same host-derived path every tenant uses. Client-specific records stay behind that tenant wall.
The codebase stays legible
Module contracts, independent route gates and a shared Forge system make the product reviewable as it expands.
See the product through its first tenant.
The Carbon case study shows the boundary and the implemented capability map without manufacturing a testimonial or a metric.