Client delivery · 2024 – 2025

Real-Estate Investment Platform

A real-estate investment platform spanning a Flutter investor app, sponsor/admin portal, onboarding and bank/payment flows, funding dashboards, ledger state, and a Solidity/Hardhat verification layer for offering proofs. Client project, shown anonymized under NDA.

01 / 04 · System overview

Trust state across the investment journey

Anonymized investment platform connecting investor, sponsor, funding, ledger, and verification state — A sanitized system view of investor and sponsor products sharing funding, ledger, and verification state.

01 Scope

The product context behind the work.

Problem

The product needed to make a regulated investment journey feel clear for two audiences at once: investors discovering property deals and tracking their portfolio, and sponsors managing properties, offerings, investor profiles, funding state, and payouts. The sensitive parts - identity verification, bank status, payment events, and investment records - had to stay consistent across mobile, portal, API, and ledger layers.

My contribution

Worked across the Flutter investor app for onboarding, property discovery, investment review, portfolio snapshots, transaction history, milestones, updates, and payouts
Supported the sponsor/admin portal for properties, projects, offering setup, assumptions, funding dashboards, expenses, investor profiles, and user investments
Connected regulated onboarding and funding flows through KYC status, bank verification, customer/account setup, payment events, webhooks, polling, and email/status notifications
Worked with the data and trust layer: Supabase/Postgres state, Express APIs, SPV ledger records, Redis-backed polling state, and Solidity/Hardhat contracts for offering and Merkle-proof verification

Selected production stories

Story 01 · Workflow recovery
Confirmed repaired flow
Repaired a crashing property-to-project publishing workflow
Problem
Publishing a property as an investment project crashed the sponsor dashboard, while assumptions and calculation state were inconsistent across the conversion flow.
My contribution
I reworked property-to-project conversion, persistence queries, assumptions state, calculations, validation, transaction handling, and budget allocation.
Verified result
I shared a working preview and walked through property creation, assumptions, publishing, editing, and transactions; the stakeholder acknowledged the repaired flow.
Proof boundary
A teammate handled schema cleanup, and historical CI records are unavailable.
Story 02 · Cross-platform feature
Cross-surface implementation confirmed
Delivered sponsor-to-investor project updates across web and mobile
Problem
Sponsors needed to publish progress photos and status updates while investors needed a clear carousel and full update history.
My contribution
I built dashboard CRUD, validation, data queries, multi-image upload, previews, and deletion, then implemented the Flutter model, carousel, cards, full list, empty states, and multi-image viewing.
Verified result
The web pull requests were integrated and the mobile commits are preserved in the main delivery history.
Proof boundary
A teammate supported schema and surrounding mobile work, and feature-specific production acceptance was not recovered.
Story 03 · Release stabilization
Confirmed App Store release
Stabilized a mobile investment app and carried the release through App Store approval
Problem
A release-blocking checklist covered an incorrect privacy link, support-chat initialization, account deletion, investment availability, and the completed-project experience.
My contribution
I repaired those flows, rebuilt the completed-project detail path, restricted investing to eligible and open opportunities, and prepared the iOS release.
Verified result
Apple approved the release and the new version went live on the App Store.
Proof boundary
Earlier related UI work included another engineer, and the approval message does not identify one exact build hash.

02 Approach

Important engineering decisions.

The product is a real-estate investment platform with two connected surfaces: a Flutter investor app and a sponsor/admin portal. The investor side covers onboarding, identity verification status, bank verification, property discovery, investment review, portfolio snapshots, transaction history, milestones, project updates, and payouts. The sponsor side covers property intake, offering setup, funding dashboards, expenses, investor profiles, and user investments.

The core challenge was keeping regulated state consistent. A user can move through legal-name capture, eligibility, source-of-funds, KYC status, bank status, share selection, investment review, and payment submission. At the same time, sponsor operations need to see the same investment and funding state through dashboards, exports, profiles, and project records.

Underneath, the system connects a Next.js portal, Supabase/Postgres state, secure server routes, an Express core API, provider-backed KYC/bank/payment events, email/status notifications, and a separate Solidity/Hardhat verification backend. The backend layer manages offerings, SPV-style ledger records, payment webhooks/polling, Redis-backed polling state, and contracts for offering and Merkle-proof verification.

Because this is sensitive client fintech work, the public case study uses architecture diagrams instead of screenshots. That keeps the case study useful for technical buyers while protecting investor data, property details, bank information, and client identity.

03 Evidence

Evidence chapters.

02 / 04 · Product journey

Investor journey

Investment journey from property and offering through onboarding, investment, ledger, and portfolio state — The journey shows product states only, without investor, property, bank, payment, or amount data.

03 / 04 · System boundary

Shared trust-state views

Investor mobile and sponsor portal sharing normalized onboarding, funding, update, portfolio, and payout state — Investor and sponsor surfaces read consistent onboarding, funding, update, portfolio, and payout state without claiming complete field-level parity or exposing production records.

04 / 04 · Delivery / verification

Trust and verification chain

Generic identity-verification and bank status leading through payment events, SPV ledger state, and offering proof verification — The frame covers generic provider state, payment events, SPV ledger records, and the verified Solidity and Hardhat offering-proof layer—not investment advice.

04 Delivered & verified

What the public proof supports.

Delivered scope

Investor journey

Onboarding -> KYC/bank verification -> property discovery -> investment review -> portfolio, updates, transactions, and payouts

Sponsor side

Property intake, offering setup, funding dashboard, investor profiles, expenses, project updates, and user investments

Architecture

Flutter investor app, Next.js sponsor portal, Supabase/Postgres, Express APIs, payment/bank webhooks, SPV ledger, and Solidity/Hardhat verification

Stack

FlutterNext.jsTypeScriptSupabase / PostgresNode.js / ExpressSolidityHardhatRedis

Reflections

For regulated fintech, trust is mostly state management: the investor app, sponsor portal, payment events, KYC/bank status, and ledger need to tell one consistent story.
The strongest public proof for this project is architecture, not screenshots - diagrams show the real operational complexity without exposing investor, property, bank, or client identity data.

Next step

Have a similar project?

If this looks close to the product work you need, book a short call and I will help scope the next step clearly.

Book an intro call