Home Sale Catalog

Inspiration

I started Home Sale Catalog because my family needed to sell furniture, household items and children's belongings as part of a major clear-out. Managing the same photos, dimensions, descriptions, prices and availability across separate listings and buyer conversations quickly became difficult.

I did not want to build another marketplace. Existing marketplaces are useful for reaching buyers, but the seller still needs one reliable source of truth for the items, the current terms and the history behind each conversation.

What it does

Home Sale Catalog provides a mobile-friendly catalogue in Hungarian and English. A seller can publish fixed-price and negotiable items, while buyers collect multiple items in one server-authoritative Basket.

For negotiable items, a buyer may:

• send the selection without proposing a price;
• propose prices for individual negotiable items; or
• propose one price for the complete bundle.

Submitting the Basket creates a structured Offer request. The seller can reject it with a reason, issue an Offer based on the buyer's terms, or send a Counteroffer. Buyer requests and seller-issued Offers remain separate immutable records, so revisions and responses do not overwrite history.

The Basket is deliberately not checkout. Selection and price agreement do not claim that inventory has been reserved, a sale has completed or payment has occurred.

What existed before Build Week

The repository was not created from nothing during the event. Before the Build Week cutoff it already contained the shared Laravel tenancy foundation, a bilingual public catalogue, initial catalogue administration, media and taxonomy foundations, and an earlier Item-based catalogue model.

What I added or meaningfully extended during Build Week

During Build Week I added or replaced the central buyer and seller workflow:

• a server-authoritative multi-item Basket with guest continuity;
• fixed-price and negotiable items in the same Basket;
• structured no-price, per-item and bundle-total buyer terms;
• accountless Offer-request access and recovery;
• immutable request revisions and buyer-visible history;
• seller Accept, Reject and Counteroffer handling through separate seller Offers;
• deterministic synthetic demo data and Hungarian/English Browser journeys;
• transactional, idempotency, locking and real two-connection concurrency remediation.

The exact pre-event cutoff, commit range and final submission endpoint are documented in the repository. The final submission values are:

• product/runtime evidence SHA: bb66c0d95c8065ccbbabb9fbef972df1204a2902;
• immutable release identity: openai-build-week-2026-home-sale-catalog-submission;
• canonical quality evidence: 558 passed / 3271 assertions before the isolated concurrency-worker failure;
• remediation evidence: the complete Basket concurrency suite passed 15 / 15 with 113 assertions;
• targeted Browser evidence: 8 HU/EN desktop/mobile UAT journeys on the runtime-equivalent accepted Offer Request UX;
• no final type-coverage or exact-SHA Web BMAX claim is made after the test-only remediation; bridge request #420 was cancelled by owner direction as duplicate work.

How I used GPT-5.6 and Codex

I remained responsible for the real problem, priorities, UX decisions, product boundaries, UAT and final claims.

I used GPT-5.6 in ChatGPT for research, product and lifecycle modelling, architecture discussions, acceptance criteria and independent review. The reviews identified concrete issues rather than serving as ceremonial approval.

I used Codex for repository-level implementation and remediation: Laravel migrations and Actions, transaction and locking behaviour, HTTP flows, Blade/TypeScript/CSS, Hungarian and English text, feature tests, concurrency tests, Browser journeys and exact-head proof preparation.

GPT-5.6 does not run inside the application and I am not claiming an end-user AI feature.

Challenges

The hardest part was avoiding convenient but misleading shortcuts: a buy button without a sale, client-side Basket state as authority, mutable submitted intent, bundle prices silently distributed over individual items, or seller acceptance that falsely reserves inventory.

Guest access, retries, idempotency, immutable commercial records and concurrent seller/buyer writes also required explicit contracts and repeated remediation.

Accomplishments

• one consistent Basket action across the catalogue;
• a mixed fixed-price and negotiable Basket;
• structured Offer requests with three pricing modes;
• separate buyer-request and seller-Offer authorities;
• traceable rejection, Offer and Counteroffer history;
• bilingual responsive demonstration data and Browser coverage;
• a reproducible Docker-based judge setup;
• exact pre-existing-versus-Build-Week provenance.

What I learned

Trustworthy commerce starts before payment. Separating selection, buyer intent, seller terms and physical inventory commitment makes the interface more honest and makes concurrency behaviour possible to test.

I also learned that AI review is most valuable when it produces specific remediation work and when the human owner remains responsible for scope and claims.

What's next

After the submitted scope, the next commercial boundaries are final buyer acceptance, one temporal InventoryCommitment authority, Reservation and Sale, followed by production legal and security readiness.

Payment, fulfilment, automated marketplace synchronisation, PDF/print and analytics are not part of this submission.

Built With

• blade
• chatgpt
• codex
• docker-compose
• gpt-5.6
• laravel-13
• mariadb-11.8
• pest-4
• php-8.5
• playwright
• typescript
• vite