The software life cycle, in one place

Plan it, design it,
ship it in a day.

Sydla holds your initiatives, docs and screens next to the work itself. Launch a piece of work and one orchestrator, running in your own Claude Code, Codex or Antigravity, frames, designs, proves, builds and ships it — and brings every decision back to you, with its cost known before it starts.

Start free See how it works

Free for everyone — no plan, no card.

One placeplan, docs, design, code
Priced firstestimate and cap
Your gatesevery decision is yours

orchestrator· Export an initiative as CSVsample

Estimate 0.80 – 1.60 €spent 0.06 € · cap 2.40 €

Frameworking…
Designdesign gatenext
Prove firstscope gatenext
Buildnext
Verifynext
Shipmerge and release gatesnext

frameExport an initiative as CSVFramed in Sydla Docs: goal, users, what is out.

How it works

One orchestrator. Every decision yours.

You launch a piece of work. The Sydla orchestrator, in your own coding tool, holds its whole context and carries it to the end — running only the steps it needs, doing each itself or handing it to an agent you configured.

A gate per decisionAsked once, with options.

Proof per criterionWritten before the code.

Read the manual

Frame01
- Writes what the piece must achieve, for whom, and what is out, in a Sydla Docs page linked to the initiative.
- Turns open questions into questions for you instead of guesses.
Rule · Never guesses: a question is asked once, with options.
```
Goal  owners export their initiative as CSV
Out   PDF export, scheduled exports
```
Design02 · then your design gate
- Only when the interface changes: draws the screens and their states in Sydla UX.
- Links them to the piece, then asks you to pass the design gate.
Rule · No code is written on a screen you have not approved.
```
Export dialog · empty · loading · error
3 states linked to the piece
```
Prove first03 · then your scope gate
- Before any code, turns the acceptance criteria into an executable proof: tests, a browser scenario, a checklist for a study.
- The proof is the contract: you approve it at the scope gate.
Rule · Done means the proof is green, not “looks good”.
```
AC1 a CSV with one row per epic
AC2 budget and spend in euros
AC3 refused for a viewer
```
Build04
- Codes in its own Git worktree, never in your checkout, until the proof is green.
- Commits only the files it names and opens a merge request on your code host.
Rule · Never pushes to main.
```
!41 feat(initiative): CSV export
proof 3/3 green · 4 files
```
Verify05
- A separate session, never the one that wrote the code, tries to break it.
- Records a result per criterion, with the evidence.
Rule · Nothing grades its own work.
```
AC1 ✓  AC2 ✓  AC3 ✓
evidence attached to each
```
Ship06 · then your merge and release gates
- Asks you to pass the merge gate, then drafts the release notes.
- Publishes only after you pass the release gate.
Rule · Merging and releasing are your decisions.
```
v0.4.0 — release notes drafted
waiting for your release gate
```

1orchestrator per piece of work

4gates only a person can pass

0launches without you

Step outputs shown are samples. The GitLab board is updated as a mirror of each step.

One place

The whole cycle, from the plan to the release.

Plans, docs, screens and the work itself live together, so the orchestrator reads the same truth your team does. Agents read and write all of it through the Sydla MCP.

Planinitiatives · epics

Initiatives with a goal, an owner and a budget; epics and their dependencies; a plan of work where you choose who does each piece.

Instead of your tracker's roadmap

Sydla Docsstudies · specs · decisions

Versioned documents in spaces and folders, with diagrams and live references to initiatives, epics and screens.

Instead of a separate wiki

Sydla UXcanvas · components

A design canvas with your components, screens and every state, linked to the work that builds them.

Instead of your design tool

Buildorchestrator

Code written in its own worktree against a proof that already exists, ending in a merge request on your code host.

Proveindependent check

Acceptance criteria made executable before the code, then verified by a separate session, with evidence per criterion.

Shipmerge · release

Merge and release behind your gates, release notes drafted, the board kept as a mirror for the people who watch it.

The cycle:InitiativeStudyPreparationDeliveryMaintenanceProgress and cost per initiative, from the recorded work.

Cost

Know the token cost before you start.

Every piece of work gets an estimate in tokens and money before launch, and a cap. What it really spent is measured and shown against the estimate and the initiative's budget.

From your history

Recorded runs of comparable work in your workspace, shown as a range with its basis.

From a forecast

Too little history: the orchestrator forecasts the tokens, priced at your workspace's model prices, and it is labelled a forecast.

Or no number

With neither, Sydla says “no estimate yet”. It never makes a number up.

Before and after

You see the price, then you decide.

Model prices are set per workspace and you can edit them. The orchestrator records its tokens and cost at the end of each run.

A cap on every launch. The orchestrator checks what it spent before each costly step; close to the cap it stops and asks you.
Measured, not guessed. What each run really cost is recorded, against the piece, the initiative and its budget.
Estimates you can check. Each piece shows its estimate next to its actual cost, so you see how good the estimates are.

Self-serve exports · plan of worksample

Export an initiative as CSVorchestrator · your Claude Code

Estimate: 0.80 – 1.60 €; from 12 similar runs
Cap: 2.40 €; the run stops and asks
Budget left: 4 688 €; on the initiative
Gates: scope · merge; yours to pass

LaunchI'll do it

After the runestimated 0.80 – 1.60 € · spent 1.24 €

The human decides

The agent executes. You decide.

Everything the orchestrator needs from you comes back as a decision: the context in a few lines, the options, the one it recommends and why, what each costs, and what waits on it.

Nothing starts without you

A piece of work runs only when a person launches it, with its estimate in front of them and a cap. The orchestrator may propose and ask; it never launches.

Proof before code

The acceptance criteria become an executable proof first, and you approve it. Building means making that proof green.

Checked by other hands

The verification runs in a separate session from the one that wrote the code, and records evidence for each criterion.

Decisions stay human

Design, scope, merge and release are gates. An agent can request one; the Sydla server refuses an agent that tries to decide it.

Integrations

Plugs into the tools you already use.

Each one says what works today and what is still to come.

Code

GitLabWorks todayMerge requests, releases, and a board kept as a mirror of the work.
GitHubPlannedPull requests on GitHub repositories.
JiraPlannedTickets mirrored to an existing Jira project.

Where the orchestrator runs

Claude CodeWorks todayThe orchestrator as an agent; runs the work you launch.
CodexWorks todayThe orchestrator as a skill.
AntigravityWorks todayThe orchestrator as a skill.

Open to your agents

Sydla MCPWorks todayPlans, docs, designs, criteria, gates and run costs, read and written by any MCP client.
SlackConnect now · more soonConnect your workspace from the dashboard.

Where it runs

On your machine, in the tool you already use.

The sydla CLI installs the plugin and connects your coding tool to Sydla. Your code stays on your machine and your code host.

Claude Code, Codex or Antigravity

In your tool

Type sydla: the orchestrator says what waits, proposes what to do next with its estimate, and prepares an initiative's plan of work.

Your own model subscription pays the models
One license key in ~/.config/sydla/sydla.env
Nothing secret written in your repository

In the background, on your machine

The supervisor

Runs the work a person launches from the dashboard, one piece at a time, under the cap set at launch. Nothing runs on its own.

Each piece built in its own worktree
A Stop in the dashboard ends it at its next step
The measured cost recorded either way

Price

Free. For everyone.

No plan, no trial, no card. The orchestrator runs on the model subscription you already have.

Start free

Plans, Sydla Docs, Sydla UX and the orchestrator
Unlimited projects and teammates
Open-source and private projects alike
Estimates, caps and measured cost
Runs in Claude Code, Codex or Antigravity
Your own model subscription

Questions

Before you launch your first piece.

Is it really free?

Yes, for everyone: open-source and private projects, solo or in a team. There is no plan and no card. The orchestrator runs on your own model subscription.

Do I have to give up my tracker and my design tool?

No. Sydla aims to hold the whole cycle — plans, docs, screens and the work itself — in one place, but the code stays on your code host and the GitLab board is kept up to date as a mirror for the people who watch it.

Is this a coding assistant?

No. It is the frame around the coding agent you already use: an initiative and its plan of work, the docs and screens, a price before launch, a proof before code, an independent check, and gates that only a person can pass.

How is the cost estimated?

From the recorded runs of comparable work in your workspace when there are enough of them; otherwise from the orchestrator's token forecast at your workspace's model prices, labelled as a forecast. With neither, Sydla says “no estimate yet” instead of making a number up.

What happens at the cap?

Before a costly step the orchestrator compares what it spent with the cap. Close to it, it stops and asks you, with what is left to do and its estimate. A Stop in the dashboard ends the run at its next step; the measured cost is recorded either way.

Can I use my own agents?

Yes. The orchestrator hands a step to an agent you configured — a Claude Code subagent, or one named in SYDLA.md — when its description fits, and does the step itself otherwise. The verification always runs in a separate session.

Does Sydla push to main?

Never. Work happens in a worktree on its own branch and ends in a merge request. Merging and releasing wait for your gate.

Where do my tokens live?

Your machine holds one license key in ~/.config/sydla/sydla.env; code host credentials are fetched short-lived and never written in your repository.

Launch your first piece of work today.