Board cards in.
Proven changes out.
Sinawy is an AI engineering engine. Specialised agents carry each card through planning, code, review, browser verification and a witnessed deploy. People decide what gets built and accept the result.
Beside this: one real card’s run, replayed from its stage receipts.
Contacts: filter by tag
+78 min
- 08:19TriageFeature, criteria complete
- 08:23SpecBehaviour written down
- 08:25PlanScope declared
- 08:32ImplementChange and tests, gates green
- 08:32ReviewCode review passed
- 08:38VerifyRejected in the browser
- 08:40PlanRe-planned from the rejection
- 08:45ImplementReworked, gates green
- 08:45ReviewCode review passed
- 08:51VerifyEvery criterion passed
- 08:52CloseoutRecord written
- 09:00DeliveryServed commit confirmed
- 09:00WritebackHanded to human QA
Delivered 09:00 UTC, 78 minutes after filing
The bottleneck moved
Coding assistants made writing code faster. Review, testing, verification and deployment stayed human work, so the bottleneck moved instead of going away.
Agent runs that report “done” in prose are hard to trust. We learned that on our own early loop: a change that sounds finished is not a change that is live and correct.
Across a portfolio of products it compounds: concurrent writers in one repository, inconsistent checks, and no record of what actually ran.
Sinawy is our answer: an engine where every step has to prove itself before the next one starts, and where people decide what matters.
How a card moves
Contacts: filter by tagFiled
- Lane
- Ready to Fix
- Criteria
- 3, written by a person
- Owner
- Sinawy
First it lands on the board.
Contacts: filter by tagPlanned
- Type
- Feature
- Spec
- Behaviour written down
- Scope
- Declared paths only
Then it gets a spec and a scope.
Contacts: filter by tagVerified
- Gates
- Lint, types, tests, build
- Review
- Passed
- Browser
- Rejected once, then passed
Then a stage that didn't write it proves it.
Contacts: filter by tagDelivered
- Deploy
- Served commit confirmed
- Health
- Answering
- Lane
- QA Validation
Then it ships, and a person accepts it.
What the engine guarantees
A stage that cannot return a valid, schema-checked result has not finished, whatever its prose says.
Acceptance criteria are walked in a real browser by an invocation that never wrote the code.
Agents cannot push. The controller ships once, then confirms the target serves that commit and answers its health check.
At most one writer per repository: scheduled cycles, delegated jobs and human sessions take the same lease.
A rejected fix goes back to a new plan with the rejection as its input, not to someone's inbox.
A card missing a product answer is parked with one question instead of being guessed at.
Stages are routed by role, and implementation normally runs on a different model family from planning and verification.
Every attempt leaves a receipt. A deferral is recorded as a deferral, a fault as a fault.
Where people stay in the loop
Sinawy splits the work by who should own it. People write the card and its acceptance criteria, answer product questions, and accept or reject the result once it is deployed. Everything between those points is engineering, and the engine decides it: the plan, the scope, the code, the tests, the review, the browser walk and the deploy. When a card is missing a product answer, the engine does not guess; it parks the card with one question and waits. When a verifier rejects a fix, the rejection goes into a new plan, not into someone’s inbox. A small team spends its time on what to build and on judging the outcome, while every step in between leaves a receipt it can audit. See the receipts for yourself.
What you write,
How the engine reads it (conceptual)
- Board
- Contacts: filter by tagFeatureWrite a short spec first
- Admission
- Opens only with capacity, budget, no other writer and a healthy app
- Stages
- TriageReproduce or specPlanImplementReviewVerifyCloseout
- Verify
- Selecting a tag shows only contacts with that tag
- Clearing the filter shows every contact again
- The filter survives a page reload
- Delivery
- Push once, confirm the served commit, health and pipeline
- Ledger
- One receipt per attempt
what it proves.
680
cards delivered in eight weeks
Cards delivered per week with the deploy witnessed, 14 September – 8 November 2026. From Sinawy’s own ledger. Delivered is not yet accepted: a person still checks each one.
The October record
1–30 October 2026
- Cards delivered, deploy witnessed509
- Repositories with a delivery, one of them an external customer’s16
- Median machine time per card (90th percentile 57 min)18 min
- Median from first stage to delivery (90th percentile 6 h)53 min
- Fix rejected by an independent stage before delivery: the gates working, not a defect rate118 of 509
- Returned for more work after delivery, a floor as QA can lag39 of 509
Examples
- Contacts filter, CRM product. The verifier rejected the first build; the rework passed.78 min filed to delivered
- PDF option layout, forms product. Browser verification rejected the first build, passed the second.2 verify runs
- Incomplete German translation, project tool. Review rejected it before any browser time.25 min machine time
- The outlier: a card in a signage product needed six rejections before it passed.139 min machine time
Where it stops
- Verification is as good as the acceptance criteria a person wrote.By design
- Browser verification runs on a local build; after the deploy the engine checks commit, health and pipeline.Local walk
- Delivered means the deploy was witnessed, not that a person accepted it.Human QA
- No human baseline or controlled benchmark exists yet. A pilot would establish one.Not measured
Ways to work with us
For venture studios, startups, software engineering teams and organisations modernising how they deliver. Every engagement is scoped with you; there are no fixed packages.
| ConsultationA conversation | PilotA live backlog | AdoptionYour organisation | |
|---|---|---|---|
| Who it suits | Leaders weighing AI-native delivery | A team with a real backlog and a deployable product | Organisations changing how engineering runs |
| What happens | A walk-through of real card receipts and how the loop runs | Sinawy works cards from your backlog under agreed scope and access | We plan how the operating model fits your teams, tools and governance |
| Your part | An hour and your questions | Cards with acceptance criteria, product answers, QA of results | A sponsor, a pilot result, and the people who will own it |
| What you get | A clear view of fit and limits | Delivered changes, every receipt, and a measured baseline | A roll-out plan built on the pilot's evidence |
| Commitment | None | A defined pilot scope | Based on pilot results |
| Book a walk-through | Discuss a pilot | Talk about adoption |
ConsultationA conversation
- Who it suits
- Leaders weighing AI-native delivery
- What happens
- A walk-through of real card receipts and how the loop runs
- Your part
- An hour and your questions
- What you get
- A clear view of fit and limits
- Commitment
- None
PilotA live backlog
- Who it suits
- A team with a real backlog and a deployable product
- What happens
- Sinawy works cards from your backlog under agreed scope and access
- Your part
- Cards with acceptance criteria, product answers, QA of results
- What you get
- Delivered changes, every receipt, and a measured baseline
- Commitment
- A defined pilot scope
AdoptionYour organisation
- Who it suits
- Organisations changing how engineering runs
- What happens
- We plan how the operating model fits your teams, tools and governance
- Your part
- A sponsor, a pilot result, and the people who will own it
- What you get
- A roll-out plan built on the pilot's evidence
- Commitment
- Based on pilot results
Plain answers
Is Sinawy a coding assistant?
No. An assistant helps a developer write code in an editor. Sinawy takes a card with acceptance criteria and carries it unattended through planning, implementation, review, browser verification and a witnessed deploy, then hands it to a person to accept.
How do you know a change is correct?
Each stage must return a schema-checked result to advance. The repository's own lint, typecheck, tests and build run in the harness, not in the model's report. A separate invocation that never wrote the code walks every acceptance criterion in a real browser and cites evidence. Then a person accepts the result. Verification is only as good as the criteria, which is why people write them.
Where do people decide?
People decide what gets built, answer product questions and accept or reject the delivered result. Engineering choices between those points stay with the engine, and each one is recorded on the card.
Does it work on an existing codebase?
It works on existing products. 16 repositories had a card delivered in October 2026, including one external customer's codebase, which deploys to that customer's staging. Work arrives as cards on a board and ships through the repository's own deploy pipeline. Adding a repository is mostly configuration.
What about security and access?
Agents cannot push: only the controller ships, once per run, after the gates pass. At most one writer touches a repository at a time. For a pilot, scope, access and data handling are agreed with you before any access is granted.
Which AI models does it use?
Commercial models from more than one provider. Stages are routed by role, and implementation normally runs on a different model family from planning and verification, so the work is not judged by the model that wrote it. We do not publish routing details.
What does it not do?
It does not re-walk the criteria on the deployed build; after a deploy it checks the served commit, health and the pipeline. It does not perform production operator steps. It does not invent product decisions; it stops and asks. A card that ends blocked ships nothing.
What does a pilot look like?
A bounded set of cards from your real backlog, with agreed access and acceptance. You get the delivered changes, a receipt for every stage, and a baseline to compare with your current process.
Have a backlog in mind?
Leave your email and we’ll write back about a walk-through, a pilot or adoption.
- info@eleventures.ai
- Company
- eleventures GmbH
- Based in
- Kaarst, Germany