Personal account
I am the founding platform architect of Brick Rewards, a UK app that rewards renters for paying rent. This account covers how rent is verified from bank data, how the pipeline stays correct and cheap, and how a change reaches production.
Evidence boundaryThis is my personal account of work at Brick Rewards, where I am the founding platform architect in a small team. The figures are ones we measured in production in August and September 2026. Customer data, financial figures, internal names, and security configuration are omitted. Public links show the product exists; they do not independently verify my contribution.
Brick Rewards is a UK app that rewards renters for paying rent on time. Points come from bank transactions read through open banking, and members spend them on gift cards and local offers. That makes the platform money-adjacent from the first line of code. Bank data arrives late and out of order. One slow endpoint can be cut off when the platform scales down. A bad production change reaches real balances. As founding platform architect, I work with the team on how this system changes without breaking any of that.
ChoiceGate every missed or overdue notice on whether bank data is synced through the date the check needs. If not, skip with a recorded reason and re-evaluate on a later pass.
Trade-offDuring a provider outage, genuine issues are evaluated late. We accepted that, because a member wrongly told their rent is overdue loses trust that a correction cannot restore.
ChoiceAdd a transaction-date predicate to the merge so BigQuery prunes partitions. Measure the cost from audit records rather than dry runs, because a dry run is a read metric and a merge is a write.
Trade-offCost now scales with rows, so batch size stopped mattering and we stopped tuning it. The remaining run time is genuine backlog, which drains as the sync catches up.
ChoiceRenew the lock at a third of its lifetime, only if this execution still holds it, and stop in the cleanup path. Keep the lifetime short so a crashed run frees it within the hour.
Trade-offSuccessful renewals log nothing, so the lock document is the only place to see them. The return of a stale-lock takeover message is the regression signal, and we watch for it.
ChoiceCloud Run allows a fixed ten seconds after the shutdown signal, and nothing can raise it. So any request slower than about eight seconds at scale-down is lost. We serve slow reads from a shared stale-while-revalidate cache, size concurrency to reduce churn, and treat latency past eight seconds as failure.
Trade-offA shared cache serves slightly stale values, and the first request after an empty key still pays the full read. The mobile client retries, so members see a slow load rather than an error.
ChoiceJourney smoke tests gate every production build. The approval-gated build proves the infrastructure diff touches only the image and version. Anything else applies only through a named, target-scoped mode with a confirmation phrase and an invariant test.
Trade-offEach new infrastructure change needs its own mode and test, which is slower. In return, nothing reaches production unreviewed, and a green staging or test build is never mistaken for a release.
ChoiceWhen a stored gift-card purchase fails a validator that tightened after it was written, sanitise or tolerate it on read. A member must always see a card they paid points for.
Trade-offA tolerated row stays readable but not writable, so its state transitions still need the write-path fix. Expiry is itself a write that releases the member's points, so a write defect blocks both.
Review the public service context separately from this personal account. It describes the service behavior and does not independently verify my personal contribution.