blessed_moon@studio
studio: Blessed Moon Studio
discipline: Strategy · Design · Engineering
stack: Next.js · Tailwind · WebGL
scene: ASCII moon · 5 keyframes
type: Space Grotesk / JetBrains Mono
accent: #ff6a1f
sound: muted
status: ready
B / S / MCASE_04 / 26

— Case study 04

Prumo

Credit pre-qualification before apartment browsing, for MCMV buyers

All work
prumo.capture● verified
Prumo homepage stating the credit-before-apartment order

project overview

A marketing and pre-qualification site for a Rio real-estate broker, where a family gets an honest MCMV credit verdict in about a minute, before they ever compare apartments.

shipped outcome

A live product where a visitor gets a real MCMV verdict without typing a CPF, and where a shared proposal always shows both the installment paid today and the INCC-projected one at handover, because the data model makes it structurally impossible to show only one.

Role
Full-stack product engineering
Timeline
Ongoing
Year
2026
Team
Solo delivery
The problem01

The broker doesn't own inventory or set prices — she resells the same Cury Construtora launches, from the same PDFs, as every other broker in the city. In Minha Casa Minha Vida specifically, the real anxiety is credit approval, not finishes, yet nearly every listing site in the segment answers 'which apartment' first and leaves qualification for a phone call.

The approach02

The product puts the credit question first: a six-step pre-qualification flow returns one of five honest outcomes — never a binary yes/no — with zero bureau lookups and zero document uploads. Every policy-sensitive number behind it lives in a CMS global instead of in code, flagged as an illustrative suggestion until confirmed against Caixa's current tables. A proposal sent to a qualified lead freezes its own commercial numbers at creation and refuses outright to generate if its price table has expired.

The result03

A live product where a visitor gets a real MCMV verdict without typing a CPF, and where a shared proposal always shows both the installment paid today and the INCC-projected one at handover, because the data model makes it structurally impossible to show only one.

— Interface evidence

The product, not a placeholder

These are the verified interface captures from the project build. Scroll inside taller frames to inspect each complete page.

Prumo homepage stating the credit-before-apartment order01 / 04
Prumo homepage stating the credit-before-apartment order
Prumo catálogo listing Cury launches by neighbourhood02 / 04
Prumo catálogo listing Cury launches by neighbourhood
Prumo pre-qualification flow with the plumb-rail progress indicator03 / 04
Prumo pre-qualification flow with the plumb-rail progress indicator
Prumo shared proposal page, a personal letter with frozen commercial numbers04 / 04
Prumo shared proposal page, a personal letter with frozen commercial numbers

— Delivery process

From operating constraint to shipped system

The work is sequenced around risk. Domain rules and failure states come before interface polish; automation arrives before handoff.

01

Scaffold and legal identity

Next.js and Payload CMS 3 scaffolded together, with the broker's CRECI signature — name, license number, photo, strict proportion rules — built before any page that would need it, since it's a legal requirement on every surface rather than a design nicety.

02

Catálogo and the publication gate

Property and commercial-condition records that Payload itself refuses to publish until registro and cartório fields are filled — an incomplete legal record can't reach a real visitor by construction.

03

The pre-qualification engine

MCMV bracket arithmetic, a plumb-rail progress indicator built as a physically simulated rope rather than a keyframed clip, and a result screen that returns every qualification blocker at once instead of one at a time.

04

The shared proposal and first deployment

A single-use proposal link that freezes its own numbers at creation and hard-blocks generation on an expired price table, shipped to Neon Postgres and Vercel Blob via the Vercel Marketplace integration.

— System architecture

Clear boundaries, explicit responsibilities

Each layer has one job and a narrow contract. That keeps external services replaceable and product behavior testable.

Next.jsTypeScriptPayload CMSPostgreSQLTailwind CSSshadcn/uiVercel Blob
prumo.sys● online

unidade

Studio 32m²

Porto Maravilha, RJ

faixa indicativa

R$ 210.000

consultar disponibilidade

pré-qualificação

Renda[x]
Entrada[x]
Restrições[x]
Faixa MCMV[x]
Localidade[x]
Score[ ]
dentro da faixa 2
Client

Next.js App Router

Public marketing, catálogo, pre-qualification, and proposal routes sharing one app with the CMS admin.

CMS

Payload CMS 3

Publication-gated property records plus a policy-numbers global flagged as suggestions until confirmed.

Data

Neon Postgres + Vercel Blob

One managed database across environments, object storage for renders and floor plans.

— What shipped

Product capabilities

01

Five-outcome pre-qualification

Approved in-band, approved in a different faixa, above the faixas, outside the program, or an honest 'not yet' — the last returning every blocker at once.

02

Frozen, hard-gated proposals

Commercial numbers copied into the document at creation; generation blocked outright by an expired price table.

03

Flagged, not hardcoded, policy numbers

MCMV faixas, rates, and subsidy bands live in the admin behind a visible confirmation flag, never shipped as literals in code.

— Engineering pressure

Challenges resolved

01

Housing policy that moves faster than a codebase

MCMV brackets shifted by federal portaria mid-project, which pushed unconfirmed numbers into a flagged, admin-editable global instead of code.

02

An honest 'not yet'

The fifth outcome had to read as useful rather than a rejection — a returned list of every blocker, not just the first one found.

next transmission

Need a system this deliberate?

Bring the operating problem. We will shape it into a clear product brief and a buildable next step.

Start a project