☰ On this page
Why we built this
Software teams changed shape faster than their tools did. A meaningful share of the code shipped today is written with an AI agent in the loop — but the agent has no idea what the specification was, which test covers it, or why the last attempt was rejected. It starts every session with amnesia, and the team pays for it.
Existing lifecycle tools were designed for humans reading a web page. They expose a UI, not a memory. So we built Oprex around a different assumption: the newest member of your team is not a person, and it needs the same access to specifications, requirements, tests, releases, and history that everyone else has.
What Oprex actually is
One system of record for the whole lifecycle — specifications, requirements, test plans and runs, releases, bugs, helpdesk tickets, and a knowledge base — with an MCP endpoint that lets a coding agent read and write all of it.
🔗 Linked, not adjacent
A specification knows its requirements; a requirement knows its tests. A bug knows its release. Coverage is a query, not a spreadsheet somebody maintains.
🧠 Memory that outlives the session
Long-form decisions live next to the work, readable by the next engineer and by the next agent.
🔐 Isolation by construction
Multi-tenant from the first commit. Per-project access is derived from one rule and applied to lists, counts, and detail reads alike.
🎬 Testing you can record
OTP — the Oprex Test Protocol — turns a tester's clicks into test cases that a runner or an agent replays, with a screenshot at every step.
Who is behind it
Oprex is built by PT Kinetikum Indo Solusi, an Indonesian software company that also builds and operates HR, recruitment, CRM, and conversational-AI products used by real organisations. We are a small team; the product family is called Kinexa Systems.
That matters for a practical reason: we are our own hardest customer. Oprex's specifications, requirements, tests, bugs, releases, and this website's changelog all live in Oprex. If a workflow is annoying, it is annoying to us first.
Creator story
Budi Agus Santoso — System Analyst at PT Kinetikum Indo Solusi, Bekasi, Indonesia.
In July 2026, Oprex was born as an internal tool to accompany daily coding. Faced with the complexity of developing enterprise-class software like Kinetikum ERP and IndoHRM for active clients, the SDLC layer for AI emerged. Combined with AI during vibe coding, it was refined into an MCP server.
With the Oprex SDLC/ALM MCP, token usage drops by up to 90% without sacrificing traceability — from a release all the way to deployment on staging and production servers.
How we build
- Ship small, ship visibly. Releases are recorded and published; the changelog on this site is generated from the same records the team works from.
- Say what is not done. Beta means beta. Where a limit exists, we would rather write it on the pricing page than let you find it in production.
- Open where it helps. The MCP integration and the OTP protocol are meant to be adopted, forked, and argued with — not locked behind a sales call.
See it for yourself
Sign in and a workspace is created immediately. The fastest honest evaluation is twenty minutes with your own project in it.
Get started free Visit the community