Skip to content
← Blueprints

The Blueprint holds the business half, never the stack half.

Two kinds of decision usually get written down together and then rot together. One is business: what a customer is, when an invoice may be voided, which role approves a refund, which events other products listen for. The other is implementation: frontend and backend framework, database, API style, cloud, deployment. Business truth should survive technology changes. A Blueprint holds the first kind and leaves the second to the generators and target adapters that read it.

Migrations stop rewriting the product

Moving from one database to another changes the adapter that reads the Blueprint, not the definition of Invoice. The rules reach the new target word for word, because they were never phrased in terms of the old one.

One definition, more than one target

The same Blueprint can be generated against different stacks, since the choice of language and framework sits with the generator. Two products built on shared capabilities stay consistent in meaning even when their runtimes differ.

Review reads like a business document

A finance lead can read what an invoice is and when it may be voided without opening a schema file. The person who owns a rule is the one who checks it, before generation turns that rule into behaviour.

In this capability

  • Business concepts only
  • No framework choices
  • Generator-owned implementation
  • Portable across targets

Stop managing prompts. Start managing software strategy.

Connect your repositories. Let Foundariq understand what you have already built. Then tell it what your portfolio should build next.

Read-only to start · Your code stays in your GitHub · [email protected]