Four products run on this, every day

IndoHRM

HR and payroll platform for Indonesian companies. Multi-tenant, long-lived, with regulated payroll logic that must not silently change.

IndoHRM is the deepest user. Payroll is the kind of code where 'why is it like this?' must have an answer years later — so requirements, specifications, and the decisions behind them live next to the tests that prove them.

What it uses in Oprex

• Requirements & specifications — every payroll rule traced to the regulation behind it
• Test plans & runs — payroll calculations re-verified before each release
• Coverage matrix — which payroll rules have no test is a query, not a review meeting
• Bug tracking with severity — a payroll defect and a layout defect are never the same queue
• Release plans & public changelog — customers see what changed and when
• Autopilot on the hrm repository at GitLab

Liqaa

Conversational AI and customer engagement platform. Runs the live chat and helpdesk for the whole Kinexa product family.

Liqaa is where support and engineering meet. A conversation becomes a ticket, a ticket becomes a bug, the bug ships in a release, and the customer gets told the version number — one chain, no reconciliation.

What it uses in Oprex

• Helpdesk tickets — real customer conversations promoted into tracked defects
• Knowledge base — answers kept next to the releases that make them stale
• Bug tracking & discussion — the conversation that produced a fix stays attached to it
• Releases & changelog — shipped versions announced to the products that embed it

Nidaa

WhatsApp messaging and notification infrastructure. High-volume delivery where a silent failure is invisible until a customer complains.

Messaging infrastructure fails in ways that do not raise an exception. Nidaa leans on the bug fields most teams ignore — environment, reproducibility, product version — because that is where the pattern actually shows up.

What it uses in Oprex

• Bug tracking with environment & reproducibility fields — delivery failures are rarely reproducible on demand
• Milestones — delivery-reliability work grouped and tracked to completion
• Notes & Memory — provider quirks and rate-limit behaviour written down instead of relearned
• Release plans — messaging changes staged deliberately, never shipped on a Friday

Wafraa

Commerce and storefront platform. Customer-facing, changes often, and breaks expensively.

Storefront work is fast and unforgiving. The staged release path exists because a pricing change that goes out unannounced on a Friday is how a weekend disappears.

What it uses in Oprex

• Requirements & test cases — checkout behaviour specified before it is built
• Release plans with staged rollout — Staging → RC → Stable
• Coverage matrix — no checkout requirement ships without a test attached
• Tags & asset management — product and campaign assets kept with the project

How release notes appear inside the product automatically

When one of these products ships, the people using it find out from inside the app — nobody writes a separate announcement. The mechanism is small enough to describe completely:

Wiring it into your own product

Any application that authenticates against the same SSO can do this in a few lines. It is two endpoints and no SDK.

// on app load, after the user is authenticated
const r = await fetch("https://oprex.id/api/v1/releases/whats-new", { credentials: "include" });
const { data } = await r.json();

if (data) {
  showReleasePopup(data);           // title, version, notes[]
  await fetch("https://oprex.id/api/v1/releases/whats-new/seen", {
    method: "POST", credentials: "include",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ releaseId: data.id }),
  });
}

The public changelog is generated from the same records, so the in-app popup and the public page can never tell different stories.

What we learned by being our own customer

• Statistics leak. A count of critical bugs from a project you cannot open still tells you that project exists and is on fire. Aggregates are access-controlled for that reason.
• Null owners are real. Untriaged work belongs to no project yet — hiding it would hide the queue from the person whose job is to triage it.
• Fire-and-forget integrations die quietly. We found one of ours had been silently doing nothing since the day it was written. Cross-service calls now fail loudly.
• An agent with no memory repeats itself. This is the whole reason the MCP layer exists.