Property Finder - Listings & Credits Reliability
Making listings, subscriptions, and credits flows more reliable for a scaled marketplace.
At Property Finder I worked on backend systems behind listings, subscriptions, and credits. The work focused on reducing seller friction, clarifying ownership between services, and making operational failures easier for engineering and support teams to diagnose.
The most visible outcome was a more than 50% reduction in support tickets related to credits and subscription flows, achieved by tightening invariants, fixing root causes, and improving monitoring around the paths that affected sellers most often.
Business outcomes
Credits and subscription support tickets dropped after root-cause fixes and clearer operational signals.
Listings, subscriptions, and credits flows moved toward clearer ownership and contracts.
On-call engineers gained better visibility into failures before they turned into seller-facing issues.
Product context
Property Finder is a real-estate marketplace where listing visibility, subscription entitlements, and paid credits are core business workflows. Small inconsistencies in these flows can create visible seller impact: missed listing actions, unclear credit balances, failed renewals, or support tickets that are difficult to explain.
The technical challenge was not only fixing individual bugs. The deeper work was clarifying which service owned which invariant, how failures should be retried, and how operators could tell whether a seller-facing state was correct.
What changed
Clarified business invariants: documented and enforced rules around credits, subscriptions, listing actions, and entitlement states so edge cases had predictable outcomes.
Reduced root-cause failure paths: fixed recurring sources of drift and simplified error paths that previously turned into repeated support tickets.
Improved service boundaries: helped move from a single-codebase mindset toward services with clearer contracts, ownership, and integration points.
Added operational visibility: introduced dashboards, alerts, and clearer metrics so on-call engineers could spot failures and support could understand affected flows faster.
Engineering patterns
This work maps directly to the kinds of distributed-systems problems AandZ.tech helps teams with today: credits and entitlements, service boundaries, retries, idempotency, and reporting that must match operational reality.
Boundary design: make the source of truth explicit for seller entitlements and credit movement.
Idempotent operations: treat retries and duplicate events as normal production conditions, not exceptional cases.
Support-friendly observability: instrument workflows in a way that answers business questions, not just CPU and error-rate questions.
Need help with a similar system?
Share the product goal, technical risk, and timeline. We will map the right next step from there.