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 of over a generation: 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 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, lacking a single catalog of error messages or accessibility standards.

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

I conducted an independent technical assessment of the digital ticketing channels, from the perspective of a Product Owner, 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 declares its inferential premise and assigns a confidence level (high, medium, or low) to each finding.

The coverage included 9 fronts: 7 digital user journeys (identified passenger registration, login/SSO, web credit purchase, recharge via app, card replacement, block/rollback, and fare exemption for seniors) plus 2 area diagnostics, one on customer service and sales, the other on the central 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 matrix of scenarios in 5 categories (happy path, common error, exception, offline/retry, and timeout/authentication); in the central flows, 64 scenarios received unique and traceable IDs. 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 the 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 sustains them. In the area diagnostics, 20 formal requirements were prioritized with RICE, and the evolution hypotheses received quantified goals, proposed as targets to validate and not as results: retries with backoff, status push in less than 30 seconds, 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 which evidence originated it and which architectural decision restricts it.

• 16 technical reports delivered in 8 weeks, with standardized structure and versioned document governance
• 9 fronts covered: 7 digital user 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 legacy code, as long as each assertion 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.