| tc

tc is a graph-based, executable architecture description language and framework for cloud-native systems, with entity abstraction, composition and infrastructure generation capabilities. tc (topology composer) provides a higher-level abstraction for serverless development, focusing on the logical relationships between abstract entities (functions, events, routes, queues, channels, mutations and pages) rather than the underlying infrastructure details.

Unique Value Proposition

What makes tc genuinely different is the graph-first, reletionship-first approach. Every other tool still makes you think of infrastructure primitives (even if abstracted). tc says “describe how things connect, we’ll figure out the infrastructure.”

The fractal composition and namespace versioning are also unique - tc lets you zoom into a sub-topology, create a sandbox, test it, then zoom back out to the full system while maintaining graph integrity.

tc is unmatched when you have 30+ interconnected components. You can see and understand the entire system topology at a glance becase relationships are explicit first-class citizens, not scattered implementation details.

Aha! Moment

tc is unique because it asks a different question:

Terraform: “What resources do you need?”
Serverless: “What functions do you have?”
SST: “What constructs compose your app?”
tc: “What’s the graph of your system?”

tc is the only infrastructure tool that thinks in graphs first. Everything else is resource-first, function-first, or construct-first, then tries to add relationships. tc inverts this - relationships are primary, implementation is derived.

The closest analogy: tc is to infrastructure what React was to UI - a fundamentally different mental model that elevates certain concerns (component relationships) above traditional concerns (DOM manipulation/infrastructure management)

Who is it for?

tc is for engineers building cloud-native systems who value architecture clarity and team velocity over fine-grained infrastructure control.

It’s targeting teams where managing the complexity of component relationships has become more painful than managing infrastructure itself.