Skip to content

Cookie preferences

Choose which cookies and similar technologies this site may use. The strictly necessary ones keep the site working and remember this choice, so they cannot be turned off; they store nothing that identifies you or follows your browsing. Read the cookie notice

Continuumship
Menu

The SDLC Studio

Design how your company ships software.

Continuumship is not a process. It is the engine that runs yours. Write your flow once, read it as a canvas, edit it as an outline or as code, and watch work move through it.

Talk to us Features
Stages, steps of every kind, and the inspector for the one you selected.

Why teams design their own

Your process is yours. It should run like it.

  • Our process lives in a slide and three heads.

    Nobody can say which approvals a release really needs, and every team has quietly changed them.

  • Every tool ships its own idea of how we work.

    The tracker has one workflow, the pipeline another, the agent none. Stitching them together is a script nobody owns.

  • Changing the process is a leap of faith.

    We add a gate and learn a month later what it slowed down, and on whom it landed.

How it works

Write it, try it on real work, then publish.

One definition, three editors

The same draft is a canvas for the team lead, an outline for the keyboard and the screen reader, and canonical YAML for the platform engineer, with the same faults in all three.

  • No free positions: stages are columns, steps rank by what they need
  • Validated by the server, with faults marked by line
  • Design, Effective, Compare, Live and Evidence views

Steps of eight kinds

A stage holds steps ordered by what they need: decision, run, check, gate, operation, external, observe and model call. Reusable subflows carry what many flows share.

  • A Jira transition, a pipeline or an Argo CD sync as a step
  • Parallel tracks, each on its own branch, then integrated
  • An organisation's security subflow no team can remove

Replay, shadow, publish

A replay counts what a version would have required of months of real work. A candidate runs in shadow beside the enforced version before you publish it.

  • Draft by describing how your team ships; a person accepts
  • Publishing is refused when the base version moved
  • Work in flight finishes under the version it started with

One definition, three editors

Edit the flow; every editor follows.

Add a step or take one away. The definition changes once, and the canvas, the outline and the code show the same change — the same steps, in the same order, validated the same way.

Optional steps

A security scan and a canary are on; the flow is valid with 5 steps and no subflow.

Web delivery Draft Valid · 5 steps

Canvas

  1. Build

    1. Implement Person
    2. Security scan Check

  2. Review

    1. Code review Person

  3. Release

    1. Canary Check
    2. Release sign-off Person

Outline

  1. 1 Build
    1. 1.1 Implement Person
    2. 1.2 Security scan Check
  2. 2 Review
    1. 2.1 Code review Person
  3. 3 Release
    1. 3.1 Canary Check
    2. 3.2 Release sign-off Person

Code

contract: 3name: web-deliverystages:  - key: build    steps:      - key: implement        kind: run        start: manual      - key: security_scan        kind: check        uses: sast        needs: [implement]  - key: review    steps:      - key: code_review        kind: decision  - key: release    steps:      - key: canary        kind: check        uses: verify_deployment      - key: sign_off        kind: decision        needs: [canary]

Questions about the Studio

Do we start from a blank canvas?
No. Start from a template — Standard SaaS, Agent-first delivery, High-risk production, Hotfix or Regulated change — from the process discovered in your history, or by describing how your team ships.

Can our platform team keep the flow in Git?
Yes. The code view is the canonical YAML. The definition can live in your repository, and your pipeline syncs it like any other definition.

What does a drafted flow do on its own?
Nothing. A draft written from a description is validated and opened beside the current version to compare. A person reviews it, and publishing is a separate decision.

Who can change a flow, and what does it run?
Publishing a flow is a recorded decision; where you review process changes, it is a change set someone approves. Steps call your tools through your connections, runs execute on your runners, and organisation guardrails still apply.

Keep reading

The rest of the control plane.

Design how your company ships software.

Start with a thirty-day shadow pilot on one Area: connect, observe, read the report together, decide.

Talk to us Pricing