An add-on to Foundry

A professionally designed full-stack foundation, built into your repo

Made for new products and replatforms. Architecture, design patterns, and a playbook agents follow, generated straight into your repo with rich workflows for the things almost every platform needs. It deploys on any cloud, with construction and deployment recipes for every stage of scale and budget.

Four years in production, running real platforms today.

Built from the same science as every run

Foundry decides the science once and keeps it the same everywhere. The Foundation is where that science becomes real: generated into a running full stack, so every service starts from the same ground instead of each team deciding it again.

  1. 1
    Start a new repo

    A greenfield product, or a replatform of one you have.

  2. 2
    Agents generate the platform

    A working, scalable full stack built from the Foundation, in your git repo.

  3. 3
    Your team builds the product

    The platform work is done. Sprint one is your features.

The science, carried in

Not a separate product with its own rules. The same decisions, applied.

ArchitectureDesign patternsCode structure and namingError handlingTelemetryRoles and permissionsAPIs and contractsData accessTestsSecurity checks

Every agent builds from the same documented playbook

Generating the Foundation isn't a prompt and a guess. It's a defined playbook with the same steps, in the same order, every time, so a service an agent builds today looks like one built six months ago by someone else.

  1. 1
    Plan from the architecture
  2. 2
    Generate each layer in order: contracts, core, data, then routes
  3. 3
    Wire it into the one module list
  4. 4
    Rerun the tests, types, lint, and security checks
  5. 5
    Record what changed in the Knowledge Center

Read the code

From an app we built on the Foundation. It's the code your team and your agents work in every day.

A real app built on the Foundation. Every service has the same four layers, and the whole platform lives in your git repo.

acme-platform/
acme-platform/
├─ microservices/
│  ├─ service-apps/
│  │  ├─ shared/          contracts, events, permissions
│  │  ├─ core/            business rules and the ports they need
│  │  ├─ data/            repositories and migrations
│  │  └─ rest/            typed, documented routes
│  └─ service-integrations/   same four layers
├─ frontend/              React console: sign-in, admin, your screens
├─ deploy/
│  ├─ src/modules.ts      every service, listed once
│  ├─ src/bindings.ts     which provider each environment uses
│  └─ runbook/            operator runbooks
├─ vertical/alloy/        the Knowledge Center for this app
└─ e11-scaffold.json      pinned Foundation versions

Every route is typed end to end, secured by default, and published to OpenAPI. The handler is one line. The rules live in the core.

microservices/service-apps/rest/src/router.ts
const accessRoute = securedRoute(verifier, { tags: ['Access requests'] })

app.openapi(
  accessRoute({
    method: 'post',
    path: '/apps/v1/apps/{appId}/access-requests',
    operationId: 'requestAccess',
    summary: 'Ask for access to an app; the owner (or IT, when group-managed) is notified',
    request: { params: AppParamsSchema, body: { content: json(AccessRequestInputSchema), required: false } },
    responses: { 201: { content: json(AccessRequestSchema), description: 'The pending request' } },
  }),
  async c => {
    const body = await c.req.json().catch(() => ({}))
    return c.json(await appsService.requestAccess(requirePrincipal(c), c.req.valid('param').appId, body), 201)
  },
)

Plain business rules, with typed errors your users can read. The request and its notification save together, and every action is audited.

microservices/service-apps/core/src/service.ts
async requestAccess(principal: ConsolePrincipal, appId: string, input: unknown): Promise<AccessRequestView> {
  assertConsole(principal)
  const app = await this.publishedApp(await this.apps.get(appId))
  const reason = validAccessReason(input)
  if (await this.holdsAppAccess(app, principal.id)) throw accessAlreadyHeld(app)

  const sentTo = await this.accessManager(app)
  const recipients = sentTo.kind === 'it' ? await this.installAdminIds() : [app.ownerUserId]
  const request: AccessRequestRecord = {
    requestId: crypto.randomUUID(), appId: app.appId, requesterUserId: principal.id,
    reason, status: 'pending', createdAt: new Date(),
  }
  try {
    // the request and its notification commit together
    await this.accessRequests.createPending(request, requestNotification(app, request, recipients))
  } catch (error) {
    if (!(error instanceof AccessRequestPendingError)) throw error
    throw new E11Error({
      type: 'apps/access-request-pending',
      title: `You already asked for access to ${app.name}. Your request is still pending.`,
      status: 409,
    })
  }
  await this.deps.audit.record({ actor: principal.id, action: 'app.access.requested', target: { type: 'app', id: app.appId } })
  return { requestId: request.requestId, status: 'pending', sentTo }
}

Providers sit behind ports. Changing email, storage, or cloud means changing one file, and a missing secret stops the app at startup instead of failing quietly.

deploy/src/bindings.ts
/**
 * What every deployed environment runs. rest.ts never knows whether it got this file
 * or bindings.local.ts. Swap this for whichever provider you run (SES, Mailgun, ...);
 * nothing outside it needs to change.
 */
import type { EmailSender } from '@engineering11/v2-notifications-core'
import { SendGridEmailSender } from '@engineering11/v2-notifications-sendgrid'

function required(name: string): string {
  const v = process.env[name]
  if (!v) throw new Error(`${name} is required to bind the email sender`)
  return v
}

export const emailSender: EmailSender = new SendGridEmailSender({
  apiKey: required('SENDGRID_API_KEY'),
  defaultFrom: process.env.NOTIFICATIONS_FROM_EMAIL,
})

The things almost every platform needs, done before sprint one

Every product needs the same handful of workflows before it needs its own features. The Foundation ships them already built, already tested, and already documented.

  • Authentication
  • Registration and invitations
  • Multi-tenancy
  • Roles and permissions (RBAC)
  • Payments and billing
  • Notifications (email, SMS, and push)
  • File storage and uploads
  • Reporting and analytics
  • Audit log

One stack, every discipline covered

Designed once

The decisions every service shares

  • Architecture and design patternsDecided once, enforced everywhere, and written down in the Knowledge Center. Not left to each team to reinvent.
  • Opinionated where it countsArchitecture, patterns, and conventions are decided and enforced. Unopinionated everywhere else, so your product decisions stay yours.
  • Ports and adaptersEvery external provider, from payments and email to storage and queues, sits behind a strong interface. Swap one adapter, not your business logic.
  • Agent playbookThe documented steps every agent follows to build a service, so the output is consistent no matter which agent or session built it.
  • Documented in the Knowledge CenterEvery pattern and decision is written down, and every agent reads it before it builds.

Built in

Working from the first service

  • Rich workflowsAuthentication, registration and invitations, multi-tenancy, roles and permissions (RBAC), payments and billing, notifications, file storage, reporting, and an audit log, done before sprint one.
  • TelemetryTraces, logs, and metrics wired in from the first service, not bolted on later.
  • LintingClean types and lint enforced on every change, not left to review.

Proven and kept current

Checked, tested, and running today

  • Security checkedSecret, dependency, and infrastructure scans on every change.
  • Tested before releaseEvery version passes the full test suite before it ships.
  • Distributed as packagesVersioned packages, kept current by us and upgraded by you on your own schedule. A version bump, not a rewrite.
  • Four years in productionNot a template. The same Foundation runs real platforms today.

Runs anywhere

Any cloud, any stage of growth

  • Deploys on any cloudAWS, GCP, Azure, or your own Kubernetes. Pick the recipe, not a vendor.
  • Recipes for every stage and budgetConstruction and deployment recipes from startup to enterprise, with serverless and minimal ops at one end and Kubernetes and dedicated infrastructure at the other.
  • Scaling, built inEach service scales on its own. Add workers, caching, or read replicas where the load actually is, not everywhere at once.

Startup to enterprise, on the same code

Construction and deployment recipes for each stage of growth and budget. Start lean and move up when you need to, on any cloud, without a rewrite.

AWSGCPAzureYour own Kubernetes

Startup

Serverless containers, a managed database, and minimal ops.

Growth

Background workers, caching, and separate environments.

Scale

Kubernetes, event streaming such as Kafka, and scaling per service.

Enterprise

Isolation, compliance controls, and dedicated infrastructure.

A professionally designed full stack, four years proven, generated into your repo

Opinionated where it counts. Unopinionated where it doesn't. Yours from the first commit.

Tell us what you're building, and we'll show you how the Foundation fits it.

← Back to Foundry

How do you want to start?

Thanks. We'll be in touch.