Liquidimmo

From MVP to evidence-first SaaS: helping real-estate professionals prioritize and act before properties reach the open market.

Comment

Inspiration

Liquidimmo began in early 2026 as an MVP built around one observation: by the time a property is publicly listed, every real-estate agent can see it. The advantage lies earlier — identifying which properties may reach the market next, separating credible opportunities from noise, and turning uncertainty into a responsible commercial action.

The MVP validated the problem. The next challenge was to industrialize it into a dependable SaaS that real-estate professionals could use every morning.

Liquidimmo was already a live product before OpenAI Build Week. We did not recreate it during the event, and we do not present pre-existing work as new. Our Build Week contribution is a bounded, testable extension to that existing product: turning “evidence before action” into an executable commercial-pipeline rule.

Our ambition is not “more leads.” It is fewer unsupported decisions, made earlier.

What it does

Liquidimmo is an evidence-first SaaS for real-estate prospecting.

It transforms fragmented property and market signals into prioritized opportunities for French real-estate professionals. Instead of asking an agent to inspect multiple sources and manually infer what matters, Liquidimmo presents a bounded set of cases that may reach the market soon, explains why each case deserves attention, and connects it to a next action.

The product supports the operating loop:

Detection → Verification → Prioritization → Action → Pipeline → Measurement

An opportunity record separates:

  • predictive potential;
  • verifiable property attachment;
  • evidence strength and freshness;
  • current market status;
  • contact qualification;
  • the next commercially responsible action.

That separation matters. A high score alone must never create a fictional property, owner, contact, or mandate. When evidence is incomplete, Liquidimmo states what remains unknown. When a proposed action is not supported, the product can preserve the safe state and refuse the transition.

What we built during Build Week

The immutable pre-event baseline is commit c93ddb582db43a9b2750ac059d67bd1dd896529b, committed on July 12, 2026. Judges can isolate the event work with:

git diff c93ddb582db43a9b2750ac059d67bd1dd896529b..HEAD

The Build Week extension makes pipeline progression evidence-gated:

  • a card can move forward only when verifiable property evidence is attached;
  • a company event, procedure, score, counter, opaque identifier, or headquarters address is not treated as property proof;
  • a canonical probable SCI, SCCV, or SCIA liquidation case with a valid SIREN may move only from Detected to Qualified;
  • progressing that probable case to Contacted, Offer, or Signed requires verified property evidence;
  • backward moves remain available for every card, including legacy incomplete records;
  • a rejected move changes neither stage, history, timestamp, local storage, nor server state;
  • the user receives a clear business explanation without exposure of internal sources, models, providers, or architecture.

This is deliberately narrow. It changes the real professional workflow, remains easy to demonstrate, and can be tested deterministically.

How we built it with Codex and GPT-5.6

We used Codex with GPT-5.6 as a multi-agent product and engineering environment.

Several bounded agents worked in parallel on complementary questions:

  1. official rule and submission compliance;
  2. repository, GitHub, Vercel, and evidence auditing;
  3. product-contract and data-boundary review;
  4. adversarial false-positive analysis;
  5. tests, release readiness, media, and Devpost completion.

Their conclusions were fused in one primary Codex session. Parallel analysis surfaced more risks; the fusion step resolved contradictions against Liquidimmo’s canonical product rules.

The agents initially found that apparently convenient shortcuts — an asset counter, a category label, a generic ID, or a street address without a usable location — could create false positives. The final implementation removed those shortcuts and aligned the frontend transition policy with the repository’s canonical property-proof rules.

GPT-5.6 and Codex helped us:

  • trace the flow from card data to transition, UI feedback, local persistence, and server synchronization;
  • compare historical and client-safe record shapes;
  • preserve the narrow probable-liquidation exception without letting it imply a verified property;
  • turn product decisions into focused unit, integration, and browser tests;
  • update the frontend behavior contract in the same change;
  • distinguish local verification from production proof.

The founder retained the product decisions and approved the final fail-closed behavior. No credential or private token was placed in the repository or public submission text.

Challenges we ran into

The hardest problem was not generating a recommendation. It was deciding when the system should refuse one.

Property signals are heterogeneous and incomplete. A legal event, company, address, score, or contextual clue may be relevant without proving that an actionable property exists. We had to recognize real proof — such as a property-safe readiness state, cadastral reference, DPE identifier, or addressable nested property — while rejecting placeholders, masked values, counters, and opaque identifiers.

A second challenge was legacy compatibility. Older incomplete cards must remain visible and correctable. The gate therefore blocks unsupported forward progression but always permits a move to an earlier stage.

A third challenge was proof quality. A passing local test is not evidence that the same commit is live. The repository README now separates the pre-event baseline, Build Week diff, focused tests, release checks, and post-deployment SHA verification.

Accomplishments that we’re proud of

We converted Liquidimmo’s central product principle — evidence before action — into executable behavior.

The change is covered across the domain helper, UI persistence path, frontend contract, focused unit tests, integration tests, and a browser interaction fixture. The focused suites, broader targeted tests, quality gate, build, guide conformity check, and the relevant Playwright scenario pass locally.

We are also proud of the multi-agent method itself. The final patch is stronger because the agents did not merely agree: they challenged one another’s assumptions until the false-positive paths were closed.

Most importantly, the product can now refuse an unsupported commercial progression without losing data or blocking safe correction. In a predictive professional tool, a responsible refusal is a feature.

What we learned

We learned that the most valuable use of GPT-5.6 was not producing more code. It was maintaining coherence while repeatedly asking: what evidence supports this state?

We also learned that multi-agent work creates leverage only when there is one disciplined fusion step and one canonical product model.

Finally, industrializing an MVP means designing proof, not only features. Product rules, tests, release identity, and the behavior served to users must form one traceable chain.

What’s next

Next we will deploy the event commit, verify that production serves the exact submitted SHA, and measure how the evidence gate affects real pipeline behavior.

Beyond Build Week, we will continue expanding verified territorial coverage, improving evidence freshness, and measuring movement from detected opportunity to qualified commercial action.

Liquidimmo’s goal remains unchanged: help a real-estate professional understand faster, prioritize faster, and act earlier — without confusing prediction with proof.

Built With

Share this project:

Updates