Enterprise-grade delivery for apps built in a weekend.

Why enterprise grade

An app built in a weekend and a platform built for a global brand fail in the same places: an endpoint that checks who you are but not whose data you asked for, a migration nobody can roll back, a business rule nobody approved, a Monday with ten times the traffic. Enterprise teams do not avoid these by being smarter. They avoid them with process. This is the same SDLC our developers use for global brands, cut into steps your own agent can run.

It was not written for this product. The same SDLC builds large applications: enterprise systems, high-traffic e-commerce, customer-data platforms, product systems running in several countries at once. It was designed and refined over years of delivery by a team of product managers, project managers, senior architects and senior engineers at Innovate d.o.o., and what they learned is encoded in the playbooks: how a story is written, when it counts as refined, the execution rules, the coding standards, the rubrics each reviewer scores against, the dimensions of the sprint audit, the rules for a release. The MCP hands that process to your own agent, one step at a time.

• Seven gates, G0 to G7: refined, preflight, verify, review, pushed, audit, integration flows. A step that skips one is refused.
• Three independent reviewers on every change, none of whom built it.
• Due diligence across nineteen dimensions with file-level evidence, rescored after the work.
• Load testing at a year of your traffic before release, not after the first spike.
• An audit after every sprint, and a decision register for every rule nobody approved.
• The paperwork enterprises ask for: NDA, an art. 28 DPA, GDPR as home law — Innovate d.o.o., Ljubljana. When we do the work, your code and data stay in the EU; when your agent does it, your code never reaches us.

The pipeline

Eleven steps, seven gates. Planning happens once per sprint, building happens once per story, and the sprint closes only when the merged work survives an audit and the journeys across it work end to end.

What happens at each step

Every step has the same shape. Your agent does the work in your repository, where you can watch it. Our server hands out the brief, checks the preconditions before it accepts a state change, and writes the result into the ledger. Skip a gate and the server says which one, and what the next allowed step is.

It iterates until 4/5

One pass is not the product. After every sprint, the audit's findings and the retrospective go into the next backlog as stories, and the estimates are recalibrated against what the sprint actually took. The due diligence runs again on the same nineteen dimensions, the load test runs again at a year of your traffic, and the next sprint fixes what they found. The loop repeats until the app or platform scores at least 4 out of 5 — strong — on the same 1–5 scale the due diligence uses.

How many sprints that takes depends on where the project starts. The reference project went from 2.0 to 3.4 in its first run of sprints; reaching 4 takes further sprints on the licence. The report shows the score after every iteration, so you can see which way it is moving.

Your dashboard

Every SDLC licence includes the SDLC dashboard, running on your own computer over your project's ledger; what your agent does through the MCP shows up there. It is the same dashboard our own delivery runs on, with nothing held back: the board, the sprint runs, the due diligence, the decisions, the agents and what each job cost, the reports.

Illustrative screens. Numbers and stories are an example, not a client.

What the workspace contains

• Project overview
• Product vision
• Requirements
• Discovery and document intake
• Backlog
• Board
• Story pages with their refinement
• Sprints and sprint runs
• Change requests
• Dependencies
• Design and wireframes
• Software design document
• Due diligence
• Decisions taken on your behalf, and open questions
• Agents and their jobs
• Activity log
• Cost
• Timeline
• Regression runs
• Performance
• Load testing
• Monitoring
• Infrastructure
• Releases
• Reports
• Docs
• Settings and members

A sprint, as a transcript

Condensed from one session in Claude Code on a booking app. Tool calls are shown by name; the agent's work between them — editing files, running tests — happens in the terminal as usual.

> Set this repo up on the SDLC. First goal: customers can cancel their own bookings.

▸ sdlc_project_init {name: "booking", stack: ["nextjs","postgres"]}
  → project k3F9xQ2a · discovery brief
Three questions before I write stories:
  1. Can a customer cancel at any time, or only up to a cutoff?
  2. Is a cancellation inside the cutoff refunded?
  3. Who gets notified — the customer, the business, both?
> Up to 24 hours before. Both get an email. Refunds — I haven't decided.

▸ sdlc_backlog_add 4 stories
  → S-001 … S-004 stored as Draft · S-003 has 2 criteria, needs ≥ 3
▸ sdlc_decision_add "Is a cancellation inside 24 h refunded?" asked_by: owner
  → D-001 open · ships as: switched off
▸ sdlc_refine S-001 … S-004
  → G0 pass ×3 · S-003 open: R5 (scope boundary), R12 (tests per criterion)
[agent adds the boundary and a test per criterion]
▸ sdlc_refine S-003 → G0 pass · Ready
▸ sdlc_sprint_plan goal: "Customers cancel their own bookings" · S-001 … S-004
▸ sdlc_sprint_start SP-1 → active

▸ sdlc_story_start S-002 "Customer cancels a booking up to 24 h before"
  → G2 pass · builder brief · In Development
[agent builds on its branch, commits "S-002 …"]
▸ sdlc_verify S-002 → G3 fail · lint: 2 errors · attempt 1 of 3
[agent fixes the two lint errors in the story's files]
▸ sdlc_verify S-002 → G3 pass · tests 48 passed, 0 failed · In QA

▸ sdlc_review_request S-002 → 3 briefs, 3 nonces, run each in a fresh context
▸ sdlc_review_submit architecture → approve · min score 4
▸ sdlc_review_submit security → reject · auth 2
    high: DELETE /api/bookings/[id] checks sign-in, not that the booking belongs to the caller's account — app/api/bookings/[id]/route.ts:41
▸ sdlc_review_submit functional → approve · ac_coverage 4
  → G4 reject · back to In Development · 1 task · rework cycle 1 of 3
[agent scopes the query to the session's account, adds a test for another account's booking]
▸ sdlc_verify S-002 → G3 pass · 50 passed
▸ sdlc_review_request S-002 → 3 new nonces
▸ sdlc_review_submit ×3 → approve · approve · approve
  → G4 approve
▸ sdlc_story_done S-002 pushed_ref: 9c41e7a → G6 · Done
[S-001, S-003, S-004 the same way]

▸ sdlc_audit_request SP-1 → 5 dimensions
▸ sdlc_audit_submit 4 · 4 · 3 · 4 · 4 · refund path deferred (D-001, switched off)
  → G5 pass
▸ sdlc_sprint_complete SP-1 flows: sign in → book → cancel pass · cancel inside 24 h → refused with message pass
  → G7 · SP-1 completed
▸ sdlc_report → 4 stories Done · 1 verify retry · 1 review rework · 1 open decision · report page /r/k3F9xQ2a

> Refunds inside 24 hours: no.
▸ sdlc_decision_resolve D-001 → decided · story S-005 planned to switch it on

Notice what did not happen. The agent did not mark its own work Done. The refund question did not stall the sprint, and did not get answered by a guess.

What you get

• A gate ledger with provenance: every result, its time, its verdict and where it came from.
• A decision register: open rules, who decides, how each ships meanwhile.
• A refined backlog: pass-or-fail criteria, tasks, estimates, risks, owners.
• Three independent reviews per change, scored with file and line.
• Sprint audits on five dimensions, re-run until nothing blocks.
• A load-test gate before release.
• The dashboard on your own computer with the board, sprint runs, reports and everything above.
• A sprint report page per project.
• Readiness before and after: the free scan on day one and after the last sprint.

Three ways in

Short answers