WEBSITE CASE STUDY
Blessed Properties: helping visitors move from browsing to a useful inquiry
· By Jethro Frane · 3 min read
A look at property search, comparison, and payment estimates, plus the decisions behind a separate source-based portfolio demo.

Blessed Properties PH helps visitors browse properties, compare details, and find a path to an inquiry. My portfolio also has a separate demo built from its public interface, using fictional listings.
I want the two versions to be easy to distinguish.
Start with what the visitor needs
The homepage search lets someone begin with location, property type, and budget. Listing cards keep the main details together. Property pages add a gallery, specifications, and other information for a closer look.
Comparison lets the visitor inspect the same fields side by side. The loan interface shows estimates when assumptions change; it does not guarantee a financing result.
One issue that made the lesson clear
In the demo, floor-area and parking values existed in the sample records but were not passed through every property-card call. The comparison displayed missing values.
Passing the fields into the shared card corrected the matrix. That showed me why checking the visible result matters. Data being present does not mean it reaches the screen.
Make the demo safe to explore
The demo reuses public components and substitutes sample data. Its interactions are temporary. Refresh restores the sample state, and it sends no real inquiries or files.
The stack includes Next.js, React, TypeScript, Tailwind CSS, Supabase, and Vercel. The demo replaces production data connections with fixture adapters.
My approach and takeaway
I used Codex assistance to inspect the source, reuse components, and check the demo. I directed the scope and reviewed details such as image loading and comparison data.
You can visit the official site or try the fictional demo. My main lesson was to follow the information all the way from the record to the screen.
Follow one piece of information through the interface
The comparison issue gave me a concrete way to think about QA. A sample record, a listing card, and a comparison row are connected, but each layer can lose information. Checking only the source record would have missed the problem.
A useful review follows a property from the list to its detail page and then into comparison. Names, measurements, images, and labels should describe the same sample throughout that journey. Estimated payments also need clear assumptions. The public demo is a way to inspect that interface with fictional data; it is not a real listing service, a financing offer, or a record of completed client transactions.
Project screenshots


