Invitation only · closed beta
Ship the software and the paper trail somebody can sign.
Teqys turns a discovery conversation into a business requirements document, an architecture, a technical spec and a plan — then writes, tests and deploys the code against them. A named person approves at every gate that cannot be undone, and the whole chain is recorded as evidence.
Your GitHub, your branch protection, your model key. We take no margin on your compute.
The problem
Writing code got cheap. Agreeing on what to write did not.
Every number below is measured, and none of it is an argument against using AI to build software. It is an argument about where the expensive mistakes happen, and about who is watching when they do.
19% slower
In a controlled trial, experienced developers took longer to finish real tasks in codebases they knew well when they used AI — and came away believing they had been 20% faster. The cost of a wrong direction is invisible from the inside.
81% more duplication
Across hundreds of millions of real commits, duplicated code has risen sharply since 2022 while refactoring has fallen by roughly 70%. More code is being written and less of it is being reconciled with what already exists.
Production, unreviewed
Audits of applications assembled by prompt-to-app tools keep turning up critical vulnerabilities, leaked credentials and exposed personal data — live, and serving real users, because nothing in the path required anyone to look.
No way to say stop
An agent has already deleted a production database during an explicit freeze and then produced fabricated test results rather than report what it had done. The lesson is not that agents are bad. It is that permission cannot be advisory.
The cheapest place to catch a mistake is before the compute is spent — and the only way to catch it there is to make the person who owns the outcome agree to the scope first.
Where Teqys sits
Two mature categories. Neither one does the whole job.
Tools that write software
Coding agents and app builders have got very good at producing working code from a prompt. They are built for an engineer, they live in an editor or a terminal, and their unit of delivery is a pull request.
They cannot hand a client something to sign.
Tools that produce the record
Requirements and traceability platforms have produced approvable, auditable documents for decades. Regulated industries run on them, and they are very good at what they do.
They cannot write the software the record describes.
Teqys
One durable workflow that authors the business requirements from the conversation itself, carries them through architecture and plan into working code, and produces a signed record of who agreed to what along the way.
Both halves, or it is not delivery.
How it works
Documents first, then code — and gates in between.
Thirteen specialised agents run as two graphs inside a durable workflow. An approval genuinely suspends the run rather than prompting over a process that carries on regardless.
Agree
Meeting → BRD → architecture → TRD → plan
A discovery conversation becomes a business requirements document, an architecture, a technical spec and an implementation plan. Critics revise each draft before it reaches you.
Four approvals
Build
Data model → screens → backend → frontend → QA → security
Specialists write real files in a contained workspace and run real commands to check them. Failing tests and blocking security findings route the work back to coding rather than onward.
No gate — nothing here is irreversible
Ship
Pull request → merge → staging
Code lands in your GitHub organisation under your branch protection from the first commit. Opening a pull request is not permission to merge it.
Two approvals, plus five that can never be switched off
All seven stages, and what each of the thirteen agents does →
The Delivery Record
The chain is the product.
Anyone can hand you a document and anyone can hand you a repository. What neither category produces is the unbroken line between them — rendered as a traceability workbook with live formulas, and exportable the day someone asks.
- Business requirementwith an ID every later artifact cites
- Architecture decisionand the critique it survived
- Technical requirementtraced back to the business need
- Ticketin the approved implementation plan
- Change setthe actual files, in your repository
- Test resulta real exit code from a real run
- Security findingseverity, and whether it blocked
- Deployment stepwhat was promoted, and where
- Approvalwho said yes, to what, and when
Five approvals can never be switched off
Risk is classified in one policy rather than hardcoded per call site, so these stay mandatory on every plan and in every project.
- Production deploy
- Production schema change
- Secret access
- External communication
- Infrastructure deletion
Why the record can be trusted, and what stops it flattering itself →
The workroom
What you actually look at.
Screens from the product, with sample project data.
Overview
One surface for where the project actually is
Progress through the pipeline, what is waiting on a decision, and what the agents are doing right now — updating live rather than when someone remembers to write a status report.
- Stage-by-stage progress against the approved plan
- Pending approvals ranked by risk
- Live agent activity, streamed as it happens
Documents
Deliverables a client can open, edit and send back
Every artifact renders as a real Word, PDF or Excel file — cover page, table of contents, page numbers, live formulas. Edit the document by hand and the agents continue from your version, not theirs.
- BRD, architecture, TRD and plan, each behind its own gate
- Word round-trip: your edits are read back into the pipeline
- Traceability workbook with live formulas
Delivery
Real files, real exit codes, then a pull request
Coding agents work in a contained per-project workspace and run the verification commands themselves. What you review is the diff and the test output that produced it — with a running cost meter and a ceiling you set.
- Sandbox file tree and the commands that ran
- Test output with the exit code, not a summary of it
- Live spend against a limit you can move mid-run
Who it is for
Teams whose contracts are written in documents, not commits.
- Software agencies and delivery partners
You are paid against a scope somebody signed. The document that defines it is a commercial instrument, and rework you cannot attribute comes out of your margin.
- Delivery leads and PMOs
You have to say what state a project is in and who agreed to what, to people who will not read a repository. Today that means assembling it by hand after the fact.
- Internal teams under a compliance rule
Somebody will eventually ask who approved the change that reached production. An audit trail written afterwards is a reconstruction; this one is written as the work happens.
If your reviewers read pull requests and nobody ever asks you to produce a signed scope, you probably do not need this.
Pricing
Priced per team, and reviewers are free.
One subscription covers the workroom and everyone in it. Agent spend is metered separately against a ceiling you set, so a run cannot quietly become an invoice. The numbers are being settled with the first teams on the beta.
Start with one conversation.
Run a discovery meeting or paste a transcript, and you get a requirements document to argue with before a line of production code exists.
Teqys is invitation only while we are in beta and we set up each workroom by hand, so tell us what you are delivering and who has to approve it.
Still deciding? Read the questions we get asked.