AI SDLC platform
An AI-native SDLC platform you can host or self-host.
The same software we run client work on. A feature request becomes an artifact, a run carries it through governed states, agents do the work on runners, and people hold the gates.
Start a project- governed states
- 9
- artifact types
- 11
- ways to run it: hosted or self-hosted
- 2
What the platform gives your team
-
State is the truth
A run is in exactly one state. Transitions are explicit. The board cannot drift from reality because the board is the state.
-
Artifacts are the record
Eleven artifact types from feature_request to release_candidate. Agents communicate through them, never through chat history.
-
Agents as jobs
Research, plan, design, build and test run as bounded jobs on runners, with skill files and policy definitions.
-
People at the gates
Design approval and manual review stop the run until a person acts. Every run, no exceptions.
-
Runners you control
Managed by us, or self-hosted inside your network. Runner state is visible: online, busy, offline, disabled.
-
Project memory
Context that persists across runs, so the next feature request starts where the last one ended.
When a team needs a governed SDLC
AI has made the work faster. It has not made the record better. These are the signs the gap is costing you.
- 01
AI-written code arrives without a trail
Pull requests appear with no requirement, no design and no account of what the model was asked.
- 02
Review is the bottleneck
More output than people can read, with no structure that says what needs a human and what does not.
- 03
Every developer has a different process
Tools, prompts and agents vary per person. The outcome depends on who picked up the ticket.
- 04
Approvals are informal
Design sign-off is a thumbs-up. Release approval is whoever is around.
- 05
You cannot replay a decision
When something ships wrong, nobody can reconstruct what was known at the time.
- 06
Compliance wants to know what the AI did
Which model, which inputs, which outputs, approved by whom. Your tools cannot answer.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
What is in the box
-
Workflow engine
Nine governed states, explicit transitions, one run per feature request.
-
Artifacts
Eleven artifact types as the system of record, versioned and attached to runs.
-
Agents
Research, plan, design and build jobs bounded by skill files and policy definitions.
Read more -
Runners
Self-hosted or managed execution, with visible runner state and job history.
-
Gates
Design approval and manual review as first-class transitions a person must make.
-
Audit log and project memory
Every transition, job and artifact with its actor, plus context that carries across runs.
How a feature runs through the platform
- 01
Backlog
A feature request is written down as the first artifact of a run. Nothing moves until it exists.
In the record feature_request
- 02
Design
Research, PRD and design package are produced by agents as jobs on runners.
In the record research_report, prd, design_package
- 03
Design approval
A human gate. The run waits for a person to approve the design package.
In the record design_approval transition
- 04
Development
Implementation runs as jobs. The implementation package grows in the record with every job.
In the record implementation_package
- 05
Automated QA, then manual review
QA runs first and writes a report. Manual review is the second human gate. Failures escalate.
In the record qa_report, review_report
- 06
Ready and released
Ready means every gate passed and the record says so. Released is the last state, and the start of the next request.
In the record release_candidate, released
Hosted or self-hosted
| Item | Self-hosted | Hosted by Sydeso |
|---|---|---|
| Software | The same public core | The same public core |
| Runners | Yours | Managed, or yours |
| Storage, backups, upgrades | Yours to operate | Operated by Sydeso |
| Support | Community, GitHub issues | The people who built it |
| Requirements | Node.js 22+, PostgreSQL, Redis, S3-compatible storage | A browser |
| Licence | BUSL-1.1, AGPL-3.0 from 1 June 2030 | Subscription |
| Price | Free | Per workspace, monthly |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
Questions
- What does AI-native SDLC mean here?
- The lifecycle is modelled as states and artifacts that agents can read and write directly. AI is not bolted onto a ticket tool; the workflow is designed so that bounded agents do the work between human gates.
- Can we self-host in production?
- Yes. Internal and self-hosted production use is permitted under the Additional Use Grant in the BUSL-1.1 licence. On 1 June 2030 the licence converts to AGPL-3.0.
- What do we need to run it ourselves?
- Node.js 22 or later, a PostgreSQL-compatible database, Redis and S3-compatible object storage. A Docker Compose stack for local use is in the repository.
- Is the hosted platform the same software?
- Yes. The hosted platform runs the same public core with managed runners, storage, backups and upgrades operated by Sydeso.
- Can we bring our own agents and models?
- Agents are jobs on runners, bounded by skill and policy files. You can write your own, choose the models they call, and run them on your own runners.
- Can we offer it to our own customers as a hosted product?
- Not before the change date. Competing hosted, managed or embedded commercial offerings are restricted until 1 June 2030, when the licence converts to AGPL-3.0.
Run it with us.
Tell us what should ship first and we will run it on the platform, hosted or on your own infrastructure.
Start a project