Digital Ticketing Baseline: Product Reverse Engineering Without Access to Legacy Systems

A public transport operator in a major Brazilian metropolis operates digital ticketing channels (registration, login, credit purchase, recharge, card replacement, card blocking, fare exemptions) used daily by passengers in the network. Behind these channels, a modern front-end coexists with a legacy back-end that is over a generation old: server-side pages, opaque sessions, no versioned APIs, no idempotency, and generic error messages.

The most sensitive risk of this architecture has a name: paid without credit. Timeouts between the payment gateway, checkout, and transactional core, without retries or explicit reconciliation, create opportunities for charging without credit, duplicate orders, and manual reconciliation in spreadsheets. There are also issues with duplicate registrations between systems, fragile authentication (session tied to server cookie, without standardized MFA or token revocation), and inconsistent experiences across channels, with no single catalog of error messages or accessibility standards.

The aggravating factor: there was no reliable baseline of how the product actually worked. The assessment needed to happen without direct access to legacy environments, source code, or databases. Any statement had to be supported by observable evidence from the outside.

I conducted an independent technical assessment of the digital ticketing channels from the Product Owner's perspective over 8 weeks. The central method was UI-first product reverse engineering: I navigated the actual flows as a user, captured evidence (screens, routes, network traffic), and inferred contracts, business rules, and domain states from the observed behavior. Each report states its inferential premise and assigns a confidence level (high, medium, or low) to each finding.

The coverage included 9 areas: 7 user digital journeys (identified passenger registration, login/SSO, web credit purchase, app recharge, card replacement, blocking/refund, and fare exemption for seniors) plus 2 area diagnostics, one on customer service and sales, and another on the core ticketing technology. The result materialized in 16 technical reports, all with the same structure of 5 sections: context, methodology, evidence, diagnosis, and prioritized recommendations.

Each journey began with a scenario matrix in 5 categories (happy path, common error, exception, offline/retry, and timeout/authentication); in the central flows, 64 scenarios received a unique and traceable ID. The scenarios became acceptance criteria in Gherkin, with non-functional requirements attached: P95 latency per operation, availability, and WCAG AA accessibility as the channel standard.

To unlock the coexistence between the new front-end and the legacy, I prototyped OpenAPI v0.1 contracts for 4 domains (authentication over OIDC/OAuth2, registration, purchase, and recharge), accompanied by a new↔legacy delta with differences qualified by impact. Each flow received 3 mini-ADRs (limits, fallback, and error handling), totaling 12 ADRs as decision guardrails for the team that will build the next generation.

The backbone of the method was end-to-end traceability: premise → evidence → scenario → endpoint → ADR. No recommendation was left unsupported; all point to the evidence that underpins them. In the area diagnostics, 20 formal requirements were prioritized using RICE, and the evolution hypotheses received quantified goals, proposed as targets to validate rather than as outcomes: retries with backoff, status push in less than 30 seconds, and reconciliation with minimal manual intervention.

The closure converted diagnosis into a plan: 12 backlog items in PBB (Problem–Benefit–Behavior) format, each with scenarios, NFRs, ADRs, dependencies, and explicit DoR/DoD. A new team can take any item and know exactly what evidence originated it and what architectural decision restricts it.

• 16 technical reports delivered in 8 weeks, with standardized structure and versioned document governance
• 9 areas covered: 7 user digital journeys + 2 area diagnostics
• 64 acceptance scenarios in Gherkin, with traceable IDs by flow
• 4 OpenAPI v0.1 contracts, 12 ADRs, and 12 prioritized PBB backlog items, in addition to 20 requirements evaluated with RICE

The central learning: it is possible to build a reliable product baseline without a line of access to the legacy code, as long as each statement declares its premise, carries evidence, and assumes a confidence level. Traceability is not bureaucracy; it is what transforms technical opinion into a document that supports decision-making.