Engineering
Engineering

Hello World from Introzy Engineering

Zac Sheffer · 2026.8.3 · 7 min read

We build Introzy — a multi-tenant SaaS platform for referral revenue, partner pipelines, private marketplaces, and the operational plumbing that makes partnerships actually work. Until now, the interesting technical problems we solve have stayed inside our Slack channels and PR descriptions. That changes today.

Why an engineering blog

Introzy sits at a non-trivial intersection: multi-tenant data isolation, real-money financial workflows (commissions, invoices, ledger entries), CRM-grade contact management, AI pipelines, and a partner marketplace with both global and private instances. We've accumulated hard-won opinions on all of it. Writing them down forces us to think clearly, and sharing them lets the broader community kick the tires.

We also want to show — not just tell — that Introzy is a serious engineering organization. When a potential partner or technical evaluator lands on our site, we want them to see that the team behind the product thinks carefully about architecture, reliability, and craft.

What we'll write about

A few themes on our radar:

  • Multi-tenant architecture — how we scope data, enforce permissions across organizations and marketplaces, and avoid the isolation pitfalls that plague B2B SaaS
  • Financial accuracy — commissions, invoices, ledger entries, and why toFixed(2) is never the answer
  • AI in production — our Kai pipelines, prompt engineering patterns, email intake processing, and how we evaluate LLM output at scale with Braintrust
  • Developer tooling — monorepo structure, synthetic data generation, AI-assisted workflow commands, and keeping a large TypeScript codebase honest
  • Integration lessons — connecting with Stripe, HubSpot, Salesforce, Slack, Nylas, Algolia, and the real-world edge cases that docs don't mention

Posts will be practical. We'll show code when it helps, skip it when it doesn't, and always aim for the kind of post we'd want to read ourselves.

The stack

Boring, reliable technologies. That's the philosophy. Every choice we've made optimizes for being well-documented and AI-friendly — which means our codebase is easy for both humans and coding agents to navigate.

TypeScript strict mode everywhere. Bun as our package manager and test runner. PostgreSQL and Prisma for the database. React and Next.js 16 with App Router and server components for the frontend. Express for the shared API. BullMQ and Redis for background job processing. Zod for validation at every external boundary.

For AI, we use Anthropic's Claude models with Braintrust for observability and evaluation. Authentication is Clerk. Billing is Stripe. Email is a split between Loops for transactional sends and Postmark for inbound processing (Kai's email intake pipeline). Search is Algolia. Analytics flow through Segment as the data spine, with FullStory for session replay. Errors go to Sentry. Everything is hosted on Render.

The monorepo

Introzy is a Bun workspaces monorepo. Here's what's inside.

Applications

apps/
  web/          Next.js 16 — product UI and same-origin BFF
  api/          Express REST API — shared backend surfaces
  workers/      BullMQ job processors and schedulers
  admin/        Bull Board dashboard for job monitoring
  marketing/    Static marketing site (what you're reading now)
  e2e/          Stagehand + Playwright end-to-end tests
  mcp/          Introzy MCP server for AI tool integration

apps/web is the main product — the dashboard, CRM, marketplace UI, partner portal, commission tracking, reporting, and everything users interact with daily. It runs Next.js 16 with App Router, React Server Components, and a same-origin BFF layer under src/app/api for data fetching that stays close to the frontend.

apps/api is the Express REST API. When a surface needs to be shared across multiple clients or exposed publicly, it lives here instead of the BFF. API routes use Zod for request validation and Prisma for data access, with strict org-scoping on every query.

apps/workers handles everything that shouldn't block a request: AI enrichment of contact profiles, email intake processing, scheduled jobs, webhook fanout, and async data syncing. Jobs are defined as contracts in the queue package and processed here.

apps/admin is an authenticated Bull Board dashboard. It gives us real-time visibility into queue health — job counts, failure rates, retry status, and the ability to pause or replay jobs when something goes wrong.

apps/e2e runs end-to-end tests using Stagehand, which lets us write tests in plain English. act('click the Submit button') works even after a UI refactor, because the AI interprets the intent rather than relying on brittle selectors.

Packages

packages/
  database/  Prisma schema, migrations, client, domain helpers
  ai/        Kai pipelines, prompts, tools, and evaluation
  queue/     BullMQ job contracts and enqueue helpers
  logger/    @introzy/logger — structured logging

packages/database is the single source of truth for our data model. The Prisma schema defines every table, relation, and index. Migrations are generated here and applied across environments. Domain helpers — things like permission checks, org-scoped queries, and financial calculation utilities — live alongside the schema so they stay consistent with the model.

packages/ai contains everything related to Kai, our AI system. Pipelines for contact enrichment, partner-fit scoring, deal intelligence, and email parsing. Prompt templates. Tool definitions for agent workflows. Evaluation harnesses that run against Braintrust.

packages/queue defines the contract between producers and consumers. Every background job has a typed payload schema here, with enqueue helpers that any app can import. The actual processing happens in apps/workers, but the interface is shared.

packages/logger wraps structured logging. It's required everywhere on the server side — console.log and friends are banned via lint rules. Every log entry carries context (org ID, user ID, request ID) so we can trace issues across services.

How we work

Every PR starts with a Linear ticket. Engineers use AI-assisted workflow commands — we've built a set of Markdown playbooks that guide coding agents through our house rules: branching from the Linear-provided branch name, running a two-pass pre-PR check (typecheck, lint, test, build, then format and re-verify), creating the PR with the right metadata, and cleaning up after merge.

We never use real customer data in development. A synthetic data CLI generates realistic marketplaces, companies, contacts, connections, and events at configurable scale. New developers can go from git clone to a fully populated local environment in about five minutes.

Prettier and lint-staged own formatting. We don't argue about style in reviews. TypeScript strict mode catches the rest. Zod validates every external boundary — API requests, webhook payloads, job payloads, and pipeline handoffs.

How this blog works

This marketing site is a static Next.js export deployed to Render. The engineering blog you're reading lives at /blog/engineering/ with its own dark-themed layout — a scoped CSS variant that overrides the marketing site's warm-paper design tokens with dark surfaces, mono typography, and sharper edges.

Blog posts are JSON entries in a posts.json file, rendered through a minimal markdown parser that handles headings, paragraphs, lists, blockquotes, and fenced code blocks. No CMS, no database, no dependencies. Engineers write posts as pull requests. That's it.

What's next

We have a few posts already in progress. Expect something on our permissions model and how we enforce org-scoped data isolation, our approach to synthetic test data generation, and a deep-dive on how Kai's email intake pipeline processes inbound messages through a two-pass AI evaluation.

If you build things and this sounds interesting, we'd love to hear from you. And if you're curious about the product itself — it's free to start, no card required.

Let's build.

We ship in public. Come build with us.

Introzy is free to start. No card required.