Realpad Payments

Context

Realpad is a B2B SaaS platform for real estate developers across Europe. Developers use it to run deals end to end - including how money moves on a project: payment schedules, contract terms, collection, and reporting. Payments are core to why clients buy the product, not a side module.

Problem

The payments stack was built for Realpad's first markets. As we pushed into more European countries, the same workflow broke on local law, VAT boundaries, contract norms, and how developers actually run projects. Sales and delivery needed one configurable flow; engineering could not keep forking country logic forever. At the same time, existing clients could not be forced onto a new model overnight.

My role

I owned product discovery and delivery for generalizing payments across markets: scope boundaries, rollout sequencing, and tradeoffs with engineering, sales, and early adopters in new countries.

Constraints

• Installed base: Czech and other live clients had to keep working while Germany and the next markets came online.
• Regulation and trust: Real estate payments are conservative; pilots were still evaluating us.
• Scope discipline: Clients already run ERP or accounting tools. We are not accounting software - no filing VAT, no becoming their general ledger.
• Proof without over-building: Cover the next countries without gold-plating every edge case before we had paying users.

What I did

• Ran structured discovery in target markets on schedules, contracts, collection handoffs, and reporting developers expect.
• Defined the product boundary: Realpad owns the real-estate-specific slice (schedules, contract language, collection workflow, deal-level reporting); ERP stays ERP.
• Worked with engineering on parallel paths and abstractions so country-specific rules did not break existing tenants.
• Staged rollouts with tight feedback loops from early adopters instead of a single big-bang rewrite.

Key decisions

• Reusable abstraction over per-country forks: Country mess had to collapse into configurable product rules, not a new branch per market.
• Explicit non-goals: Saying no to "become the accounting system" kept the team focused and protected positioning.
• Staged proof: Validate the model with pilots before claiming full European coverage.

Result

Clients in new markets could run more of their payment workflow inside Realpad. Sales and international expansion had a clearer story; existing clients were not disrupted. The work supported Realpad's push into additional European markets without turning payments into a bespoke services line.

What this shows

This project is a good example of the kind of work I do best: taking a messy operational reality (country-specific payment and contract rules) and turning it into a product system people can actually use - with clear scope and discipline so we did not become accounting software.