Teamcentric — software for engineering teams

Focused tools for software engineering organisations.

Three independent products for the parts of engineering that are usually managed informally: what your people can actually do, what your AI coding tools have been told, and whether your technical documentation is still true.

Explore the products Get in touch

The product family

Separate applications with separate logins. Adopting one does not commit you to the others.

The problem

Engineering knowledge does not sit in one place

It is spread across repositories, documents, tickets, chat threads, instruction files and the people who remember. None of those is wrong on its own. Together they stop agreeing.

The cost is not dramatic, which is why it survives: an onboarding week that takes three, a coding assistant confidently applying a convention the team abandoned last year, a runbook whose numbers were true at the time somebody pasted them.

Teamcentric builds tools for the three places that fragmentation does measurable damage — and is specific about which one each product addresses.

A question asked in week one

“How do we handle retries on the payments API?”

  1. README.md

    In the service repository

    Last edited 14 months ago

  2. CLAUDE.md

    In two of nine repositories

    Copied, then edited locally

  3. ADR-014

    In the architecture wiki

    Accurate, rarely found

  4. #eng-backend

    A thread from March

    Contradicts the README

  5. A senior engineer

    Not written down

    Explains it again each time

Five sources, three answers, no owner. Every new engineer and every coding assistant picks one of them — and nobody finds out which until the change is in review.

One engineering question — how retries on the payments API are handled — and the five places a team would look for the answer: a README last edited fourteen months ago, a CLAUDE.md copied into two of nine repositories and since edited locally, an accurate but rarely found architecture decision record, a chat thread that contradicts the README, and a senior engineer who explains it again each time. Five sources, three answers, no owner.

The products

One product for each source of uncertainty

Each is a separate application with its own login, adopted on its own terms. What they share is a company and a way of working, not a database.

03 products · 03 independent applications

01 — Skills Closed beta

Teamcentric Skills

“Can we staff the work we have already promised?”

Connect reviewed skills and available capacity to the roles and projects that need them, so staffing, training and hiring decisions start from records rather than recollection.

  • A governed catalogue of technical and soft skills, with reviewed levels
  • Role fit and project readiness calculated from weighted requirements
  • Critical gaps, stale evidence and skills held by exactly one person
For
Engineering managers, heads of engineering, delivery leads
In the loop
Stages 01–02 · Capability, Commitment
To be clear
Repository activity is optional context. It never feeds a skill level or a readiness score.

Explore Skills

Illustration: a project readiness view showing 72% readiness, with Kubernetes as the largest weighted gap and threat modelling held by a single person.

Billing Platform

Project readiness

active
Weighted readiness 72%
  • Node.js covered
  • PostgreSQL covered
  • Kubernetes gap
  • Threat modelling single owner

Kubernetes has the largest weighted impact on readiness. Two members are one level below requirement.

Fig. 1 — Project readiness, decomposed into the skills behind it. Sample data.

02 — Context Early access

Teamcentric Context

“Are our coding agents working from the right instructions?”

Turn the prompts, rules and agent files scattered across your repositories into one versioned library with an owner, a review path and a visible record of what reached each repository.

  • Local discovery of the instruction files your AI tools already read
  • Versioned artefacts, reviewed and approved before they are published
  • CLI apply, pull-request publishing, and drift detection afterwards
For
Platform teams, staff engineers, anyone standardising AI tooling
In the loop
Stages 03–05 · Instruction, Implementation, Review
To be clear
Multi-tool support means discovery, versioning, placement and drift — not an integration with each vendor's API.

Explore Context

Illustration: a repository scan listing four AI assistant instruction files — one current with the published version, one outdated, one modified in Git, and one missing.

acme/billing-service

Assistant instructions

3 to review
  • CLAUDE.md v7 current
  • .cursor/rules/api.mdc v3 → v5 outdated
  • AGENTS.md v4 modified in Git
  • .github/copilot-instructions.md v2 missing

ai artifacts apply brings this repository back to the published versions, and records what it changed.

Fig. 2 — A repository scan comparing local instruction files with their published versions. Sample data.

03 — Forge Closed beta

Teamcentric Forge

“Is this runbook still true?”

Keep the prose in ordinary Markdown and mark the facts that change, then let a CLI resolve them from Git, HTTP endpoints, filesystems and hosts at build time — with provenance for every value.

  • Release, capacity and service facts resolved when the document is built
  • Immutable published versions and locked block dependencies
  • A record of which source produced each value, and when it was read
For
Platform and SRE teams, release managers, documentation owners
In the loop
Stages 06–07 · Documentation, Evidence
To be clear
Generation happens only where you run the CLI. The web application never executes a block or resolves a credential.

Explore Forge

Illustration: a generated release-evidence document with four factual rows, each labelled with the built-in block that retrieved it at build time.

release-evidence.generated.md

Built 4 minutes ago · version 7

4 of 4 resolved
  • Release v4.2.1

    git.latest-release

  • Commit 9f2c1ab

    git.commit

  • Disk used 61%

    filesystem.filesystem-capacity

  • API health 200 · 184 ms

    http.health-check

forge build resolved every value on this machine, and recorded where each one came from.

Fig. 3 — A generated document, with the block that resolved each value. Sample data.

Where they fit

Three arcs of one loop

The products are independent, but they are not unrelated. Each covers a different stretch of the same working loop, and the gaps between them are deliberate.

Teamcentric does not claim implementation or review — that is your team's work, and no tool should pretend otherwise. What it covers is the knowledge those stages depend on: who can do the work, what the tools have been told, and what the record says afterwards.

One working loop, three covered arcs

Stages 01–07

Skills Answers what the organisation can staff

  1. 01

    Capability

    Reviewed skills, roles and capacity

  2. 02

    Commitment

    What is taken on, and who can staff it

Context Governs what the tools are told

  1. 03

    Instruction

    The rules and agent files AI tools read

  2. 04

    Implementation

    Code written under those rules

  3. 05

    Review

    Change assessed against the same conventions

Forge Keeps the record true

  1. 06

    Documentation

    Runbooks, architecture and inventories

  2. 07

    Evidence

    Release facts read from live systems

07 → 01

What actually shipped is evidence about what the organisation can do next — which is where the loop starts again.

A seven-stage engineering loop. Teamcentric Skills covers stages 01 Capability and 02 Commitment; Teamcentric Context covers 03 Instruction, 04 Implementation and 05 Review; Teamcentric Forge covers 06 Documentation and 07 Evidence. Stage 07 feeds back into stage 01.

How we build

Claims that survive scrutiny

All three products are built for people who have to explain an answer to someone else, not merely repeat one.

01
The evidence stays attached
A readiness score leads back to reviewed levels, requirements and capacity. An applied instruction file leads back to its published version and the approval behind it. A generated fact leads back to its source and the time it was retrieved.
02
We do not guess about people
It would be straightforward to infer capability from commit history. We do not, because it would be wrong often enough to matter, and because people are entitled to know what their record says and where it came from.
03
Narrow and finished beats broad and nearly
Each product covers less ground than its category norm, and is more specific about what it does inside it. Every product page carries a list of what that product does not do.
04
We are direct about maturity
Skills and Forge are in closed-group testing. Context is in early access, onboarded as a guided pilot. None of them is sold as something it is not yet — we would rather say so here than in month three.

Tell us what you are trying to work out

Where your capability gaps are, how your AI tooling has drifted across repositories, or which document you keep correcting by hand. Every product is onboarded through a conversation rather than a signup form, so the specifics are genuinely useful.

Get in touch Why Teamcentric