Teardown

Teardown: a marketplace prototype taken to production

The interface survived almost untouched. Everything beneath it was rebuilt — and here is exactly what and why.

Plutonapps Engineering1 min read

This is a sample entry. The structure is final; the full write-up is on its way.

A prompted marketplace looked complete and was one query away from exposing every seller's payout details. Six weeks later it was carrying live transactions.

What changed

Tables without access rules
11 of 140 of 19
Slowest listing query
2.8s110ms
Critical journeys covered by tests
09
Time to roll back a bad release
None possibleUnder 2 min

Data

Before

  • One table per screen, duplicated seller details in three places
  • No constraints — a listing could exist without a seller
  • Text columns holding amounts

After

  • Normalised schema with explicit relationships
  • Constraints that make invalid states impossible
  • Money stored as integer minor units, in one place

Access

Before

  • Permissions implied by which pages were linked
  • Payout details readable by any signed-in account
  • Admin actions indistinguishable from user actions

After

  • Row-level policies on every table, tested by trying to break them
  • Roles stored separately and checked on the server
  • Audit trail on every administrative change

What was actually wrong?

Nothing you could see. The product demoed perfectly. The problems were structural: data shaped around screens, and access control that existed only in the interface.

What did we change first?

The data model, because everything else depends on it. Reshaping it first meant the access rules and tests we wrote afterwards did not have to be written twice.

More on this: Case studies & teardowns

Built something in Lovable you want people to rely on?

We are the engineers who take it the rest of the way — secured, tested, released and supported.