Don't Buy a Platform: AI-SDLC on a Ready Stack

A vendor builder platform promises an all-in-one solution, but in practice it creates three problems: lock-in to the vendor, a queue to IT for every change, and gates that the process owner starts working around.

The answer is not "no platform," but the thinnest platform you build yourself and own.

It is assembled from commodity off-the-shelf tools and wins because it is more convenient than the workaround.

Be clear about the stack: git and CI are open, and MCP is an open protocol for exchanging context between agents and systems.

Claude Code and Codex engines are proprietary paid clients that you rent and can replace with another at any time.

The advantage is not that everything is open source, but that there is no bespoke platform you cannot leave.

This is the same engineering foundation as our service AI-native development; here we are not dissecting a service, but how to assemble the setup itself and why it wins.

It is equally readable by a human and an AI agent: the agent can use the registry to understand where the needed process lives, which skill changes it, and where to write the result. We keep such a registry ourselves.

Our power-user boilerplate is REGISTRY.md as a single artifact catalog and a mirrored structure of skills, agents, and servers subgroups that matches the GitLab group.

By default, a new service is created as a shared platform: it is deployed from a shared path, not from one developer's home directory, and other authorized agents access it through a shared authenticated setup without transferring secrets.

The registry answers the question "what changes and where."

Who has the right to change prod independently, and at what maturity level, is a separate topic; we cover it in the article about Developer and PM levels L10-L60.

This gives every change provenance: you can see which request produced which diff.

The key word is provenance, not audit.

The log file is edited with a normal commit, just like any other file: our own log was once deleted and added back again.

It provides traceability and a record source, but not a tamper-proof audit trail.

Full audit means branch protection, commit signing (git commit -S), and a CI record requirement; the log file is the pragmatic first layer beneath them. And this is a young convention recently adopted by us, not a system battle-tested for years.

This is living proof of the MCP plus git-native memory combination, not a slide.

We moved the financial logic out of fragile spreadsheets into SQL and executable skills that the agent accesses through MCP.

The context layer is sloy-KT: chats, meetings, files, tasks, and finances become machine-readable context in GIT, split by project.

The registry and structure are our power-user boilerplate with REGISTRY.md. And this site is that same setup in action: it is edited by an AI agent on top of the repository, with the prompt log next to the changes.

We state the boundary honestly: the setup lets the process owner change prod themselves, but within their maturity level - the registry, agent, and light gate compensate for the gap, they do not remove it. AI without engineering fundamentals reduces stability, and DORA metrics show this directly, so a gate is needed, but a light one.

You can build the first working lever on a live task in 1-2 weeks, with payment due after the result is accepted.