Back to AI Engineering

Fleame

Building the product around the model

Full-stack marketplace development and AI-ready product architecture.

Full-stack development · Product architecture

Fleame’s bilingual residence marketplace landing page, captured from the implemented app.Fleame’s Discover page with a synthetic test listing for a shared oak chair.

Actual app screens · Local tests with a synthetic listing

Actual Fleame landing and Discover screens from local browser tests. The displayed listing is a synthetic test fixture.

The problem

A student-residence marketplace has to make nearby items easy to find without exposing sellers’ private contact details. Joining, publishing an item, contacting its seller, and marking it sold need to work as one journey on a phone.

My work

I’m building Fleame, a bilingual German/English second-hand marketplace that starts within a student residence in Münster. The implemented product covers residence joining, manual listing publication, photo curation, public listing pages, discovery, private contact preparation, and sold-item management.

The screenshots above show the implemented interface in local browser tests. The displayed item and seller are synthetic fixtures, not customer activity.

System decisions

The app uses Next.js and a Postgres-backed service layer with server-verified membership and row-level access policies. Public listing pages receive a narrow public view of listing data; the seller’s private phone number is selected server-side only for an authorized contact request.

Publication is designed to survive retries. Photo sanitization and temporary-media cleanup are part of the listing flow, and room visibility is an explicit per-listing choice that starts off. Contact preparation uses a retry identifier so a lost response can be retried without creating duplicate events.

AI assistance is planned as a separate capability. The current product description does not imply that automated photo interpretation or AI listing generation is already released.

Evaluation

The project’s checks exercise real database policies and complete mobile journeys with an external test fixture. The recorded scenarios include joining, publishing, discovering as a different user, preparing contact, managing photos, marking an item sold, and recovering from lost responses.

View measurement distinguishes daily views from repeated reloads. A Contact event records an authorized handoff being prepared; it does not prove that a WhatsApp message was sent. Sold attribution remains unknown until a seller supplies it.

Limitations

The pilot remains unreleased. Local and protected-preview acceptance establish specific implemented journeys, not production reliability or marketplace traction. Clearing cookies, changing devices, or refusing JavaScript can affect measurement. The portfolio links to no private join codes or protected deployment credentials.

Continue exploring

UtiliQ