Skip to content
Syntrigen

Your business is not generic.Your software should not be.

Syntrigen is an AI-native SaaS product company. We build vertical SaaS — products shaped to one kind of business, with the AI inside the workflow rather than bolted to the side. Two are live in production. We build them for other businesses too.

Start a project
See what we run
ONE SYSTEMAI INSIDE THE WORK, NOT BESIDE IT

Trusted partners

  • Dnyantra
  • Essex
  • Safarnamha
  • Deepgram
  • AWS
  • Google Cloud
  • Microsoft Azure

Product 01 · built and operated by Syntrigen

Zeno CRM is deployed and running today.

It holds the customer record, the pipeline and the activity history for teams that outgrew a spreadsheet and do not want a six-month configuration project. We run it in production, which means we carry its migrations, its uptime and its support load. The interesting engineering is in what the eight applications share — which is also what makes it the starting point for a product built for somebody else.

Zeno CRM — seeded demo data

All views: seeded demo data

Zeno CRM leads table
Leadszenohq.io
Zeno CRM pipeline dashboard
Pipelinezenohq.io
Zeno CRM reports
Reportszenohq.io
Zeno CRM customers view
Customerszenohq.io

01

Multi-tenant data model with row-level access, so a permissions mistake surfaces as a query error rather than a leak.

02

Activity history is append-only, which makes the audit trail a property of the schema instead of application discipline.

03

One permission model across eight applications, so moving between them does not mean relearning who can see what.

Go to ZenoRead the engineering story

Product 02 · also in production

Mavio

AI meeting notetaker · standalone product

The hard part was never the transcription. It was system audio capture on two operating systems, speaker attribution over a noisy channel, and deciding what in an hour of conversation is worth writing down. It runs on infrastructure we built for it, including our own speech-to-text service that costs nothing while nobody is talking.

Go to MavioRead the engineering story
Mavio live meeting view: transcript on the left, extracted action items on the right
Mavio — live meeting, transcript and action items

What is behind it

One application deployed, seven at varying stages.

Zeno is built as eight applications on a single spine. Naming them is more useful than promising a roadmap: this is the order the platform is being finished in, and the shared half is already done.

  • Zeno CRMLive
  • Zeno WorkIn build
  • Zeno DeskIn build
  • Zeno DocsIn build
  • Zeno HRIn build
  • Zeno CampaignsIn build
  • Zeno POSIn build
  • Zeno DevIn build

The position

Generic SaaS has to sell to everyone, so it fits nobody exactly. That is why a business ends up with a dozen subscriptions, a spreadsheet holding the middle together, and people doing by hand the part no vendor covers. AI changes what the alternative costs: software shaped to a single business is now affordable to build and to run. Building that software — for ourselves first, then for other people — is the whole company.

01

We run what we sell

Two products in production, on our own infrastructure and our own pager. Every argument on this site is one we have already had to live with.

02

AI-native, not AI-added

The model is designed into the workflow rather than parked behind a chat box on top of a form. If removing the AI leaves the product intact, it was decoration.

03

Evaluated, then deployed

The evaluation suite is written on day one. A change that makes the system worse fails before it ships, not after a customer finds it.

04

One team, end to end

The engineer who scopes your product builds it. Nothing is handed to a delivery layer after the pitch.

Why this exists

Software bought for a market, used by one business.

None of this is a failure of the products involved. They are built to sell to a thousand companies, which is exactly why they stop at the edge of yours.

  1. 01

    evaluatedboughtconfiguredstill not how you work

    It covers the eighty percent that every business in your sector has in common. The remaining twenty percent is the part that is actually your business, and it is now done in exports, email and a settings page that does not go far enough.

  2. 02

    ten toolsnine integrationsa spreadsheet in the middle

    Each product owns a piece of the process and none of them owns the process. Something has to join them, so a person does, every day. It looks like a working system right up until that person leaves.

  3. 03

    AI addeddemoednever reached the work

    A chat box fixed to the side of software designed before the models existed. It answers questions about the work rather than doing any of it, because the workflow underneath it was never built to hand anything over.

Build yours

The same thing, shaped to your business

Most of this work is the first line with some of the others attached. Each ends with something running in your infrastructure, not a document about something running.

How a build works
01Vertical SaaS buildsTypically 8 to 16 weeksThe software your industry runs on was written for a market, not for your work. You have configured it as far as it goes, and the gap between it and the job is now held together by exports, a spreadsheet, and someone's memory.What you getA multi-tenant application in your cloud, with authentication, billing, an admin surface, the evaluation suite, and the deployment pipeline that ships it.
02AI in productionTypically 4 to 10 weeksAn agent works in a notebook and fails in the world. No retry path, no permissions model, no record of what it did, and no way to tell whether last week's prompt change broke it.What you getA deployed agent with tool permissions, retry and escalation behaviour, per-run traces, and an eval suite wired into your CI.
03Platform and cloudTypically 3 to 8 weeksDeploys are a person, not a pipeline. Nobody is sure what is running in production, and the one who set it up left.What you getReproducible environments, a deployment pipeline with rollback, dashboards and alerts that map to real failures, and the runbook to go with them.
04Data and integrationTypically 2 to 6 weeksThe model is not the hard part. Getting clean, current, permissioned data out of the systems of record is the hard part, and it is where most projects quietly stop.What you getConnectors to your systems of record, the schema and access work that makes them queryable, and tests that catch it when an upstream field changes.

What you start from

A fitted product does not start at zero.

A vertical product is only worth building if it does not start from an empty repository. Ours does not, and neither does yours.

These are the parts of a SaaS product that are the same everywhere and take months anyway. We wrote them for Zeno and Mavio, we run them in production, and a build for you begins on top of them. It is also worth saying plainly: this is not a product. You cannot license it, and we do not sell it. It is how we build.

The application spine
Multi-tenancy, roles and row-level access, billing, audit trail, admin surface. The half of a SaaS product that is identical everywhere and takes months anyway. Zeno's eight applications already share one.
Agent scaffolding
Tool calling, permission scoping, retry and escalation, structured output validation. Written once and hardened across every product that has shipped on it.
Evaluation harnesses
The suite that decides whether a change made the system better or worse. Every build gets one on day one, not after the first regression reaches a customer.
Integration connectors
The ERP, CRM, warehouse and document-store adapters we have already written, with the sync and access behaviour worked out.
AI infrastructure
Streaming speech-to-text that scales to zero, tracing per run, cost ceilings. Built for Mavio because we needed it, and reusable because it was built properly.
infrastructurealready builtyour problem

starting from zero

the whole build

starting from AI Studio

ends here

Relative scale, not measured weeks. The problem-specific segment is identical in both bars — that is the point. Your problem takes what it takes; the work around it is what we stopped rebuilding.

How a build runs

Four stages, in this order

The order carries the information. The risky work happens second, not last, so a bad answer arrives while it is still cheap.

  1. 01ShapeWe sit with the people who do the work and watch the process run. What comes out of this is the product's shape: what it must cover to replace what you use now, what it deliberately will not, and which part of it the AI is actually for.You end up withA written scope: what we would build, what we would not, and what could stop it.
  2. 02PrototypeWe build the risky part first — the extraction, the tool call, the integration everything else depends on — and run it against your real data. If it does not work, you find out here, while it is still cheap.You end up withA working prototype on your data, and an honest read on feasibility.
  3. 03ProductionWe build the product around the prototype: error handling, permissions, tracing, evaluations, billing, deployment. This is the part most projects skip, and it is the reason they stay pilots.You end up withThe product running in your infrastructure, with its evaluation suite and monitoring.
  4. 04Operate or hand overEither we keep running it, or your team takes it with documentation and a walkthrough. Both are fine. We will tell you which one we think fits your team.You end up withAn agreed monthly scope, or documentation and access.

Engineering stories

How the products above were actually built

Written for a technical reader. The engineering detail is the point.

See all work

Our own product · Platform and cloud

A GPU transcription service that costs nothing when nobody is talking, and rejects unauthorised requests before a container starts

We built our own streaming and batch speech-to-text service to sit alongside a managed provider — partly for cost at volume, partly for the workloads that cannot leave our infrastructure. The design problem was idle GPU cost, and the answer was to have no idle GPUs.

Python · WhisperLiveKit · WhisperX · Modal · RunPod · Docker · NVIDIA T4

Our own product · AI in production

Live transcription with speaker attribution, running on our own infrastructure and our own pager

Mavio transcribes meetings in real time across desktop, mobile and a browser extension. The hard parts were never the model — they were system audio capture on two operating systems, speaker attribution over a noisy channel, and retention rules that differ per artefact.

TypeScript · Python / FastAPI · Electron · Expo · Supabase Postgres · Deepgram Nova-2 · AWS ECS Fargate · Terraform

Fit

Who this works for, and who it does not

We turn work down, including when the honest answer is that you should buy something off the shelf. It is cheaper for both of us to find out here.

A good fit

  • Your work has a shape the software you buy does not have, and the difference is costing real hours.
  • You want to own the product at the end of it, not rent a seat in someone else's.
  • Someone technical on your side can make decisions without a committee.
  • You would rather hear that a step is not feasible in week two than in month five.

Not a fit

  • You want a proof of concept whose purpose is to exist rather than to run.
  • What you actually need is an off-the-shelf tool, configured well. We will tell you when that is the answer.
  • You want a strategy deck with no build attached.
  • You need a fixed scope signed before anyone has looked at your data.

How we work together

Three shapes, and how each one is priced

We price by phase against a written scope, not by the hour. Nobody is billed for a body on a bench, and a phase that finishes early ends early. If we do not think a phase is worth doing, we say so before it is quoted.

01ShapingFixed scope, fixed priceBefore anyone commits to building a product. We read the systems, watch the process run, and write down what the product would be and what could stop it.
  • A written product scope with the risks named
  • An honest read on feasibility
  • No obligation to continue with us
02BuildFixed scope per phaseThe engagement most work becomes. Priced per phase against a written scope rather than by the hour, so the incentive is to finish rather than to bill.
  • One team from first sketch to release
  • Starts from the spine and scaffolding we already run
  • Deployed into your infrastructure, not ours
03OperateMonthly, cancel with noticeWe keep running what we built: on-call, monitoring, upgrades, and the model and dependency changes nobody plans for.
  • An agreed monthly scope
  • The pager, genuinely
  • Handover to your team whenever you want it

Start smaller

Two weeks · fixed scope

Production Readiness Review

You already have an AI system that works. You do not know what will happen to it in production.

Two weeks, fixed scope. We take an agent or pipeline you have already built and put it through the eleven questions that separate a system from a demo — retries, idempotency, escalation, tracing, evaluation, cost ceilings, rate limits, data handling, rollback, ownership, and drift.

What you get

  • A written assessment against all eleven, with evidence from your code
  • The failure modes we found, ranked by what they would cost you
  • A remediation plan your own team could execute without us
  • A walkthrough with whoever will own it

It ends with a document and a conversation. If the answer is that you do not need us, that is a fine outcome and we will say so in writing.

Ask about a Production Readiness Review

Start here

Tell us what your business does that the software you bought cannot.

That is the whole first conversation. If the answer is that an off-the-shelf tool would cover it, we will say so and tell you which one.

Start a project