Estate Sales Bakersfield

Estate Sales Bakersfield brings estate and yard sales into one local directory. Shoppers can browse what is coming up, narrow the dates, and switch between a list and a map. Organizers get a separate path to create, check, and publish a sale.

I wanted the two sides to feel connected. The public experience should help someone plan a morning out. The organizer experience needs to handle the less exciting details that make those plans reliable: schedules, addresses, photos, privacy, and the exact version of a listing that gets published.

The screenshots here were captured from the live website on November 7, 2026. They show the current interface, rather than an early concept or a staged dashboard.

The homepage puts a date selector next to the main search action. Estate-sale and yard-sale paths give people another starting point, while Today, Tomorrow, and This Weekend keep common searches close at hand. Weekend dates resolve on Bakersfield time, including the remaining days when the weekend has already started.

The Explore page shares one search model between its list and map views. Filters and the current view live in the URL, so a search can be revisited or shared. Cards organize the sale information into a scan-friendly list; the map gives the same search a geographic view. Map loading waits until it is needed.

The listing is the next step for the full details. I kept discovery separate from publishing, so someone looking for a Saturday sale does not have to work through organizer tools.

The current design pairs oversized, direct typography with a quiet map texture and a moving strip of sale imagery. The opening screen explains the place and purpose before asking for anything. Forest-green controls connect the navigation and main actions, with warm gold used for emphasis and the yard-sale side of the directory.

Light, warm surfaces leave room for the photography. Rounded image cards and restrained borders keep the pages approachable without turning every section into a floating panel. The result is closer to browsing a local directory than managing inventory.

The control type stays clear and compact. Desktop has room for navigation, filters, and geographic context. On a phone, the layout gives the search and results priority, with mobile filter controls and safe-area spacing. Focus treatment, loading and error states, and reduced-motion behavior belong to the shared interface system.

The imagery introduces the atmosphere. Actual published listings remain the source of sale details; the homepage artwork is not a promise that a pictured object is available.

Organizers sign in, complete onboarding, and build a private draft through a five-step flow. They enter the sale details and schedule, confirm the location and privacy choice, manage photos, and review the result before approving it.

Uploads are processed before a photo is treated as saved, and a cover image is required for review. The preview reflects the listing being approved. Approval belongs to a specific revision, which prevents later edits from quietly changing what was approved for publication.

The dashboard keeps the organizer’s listings and their next actions together. The payment return page does not decide whether a sale is live. That decision comes from the server after verifying the payment event.

Location entry uses server-mediated address suggestions. After selecting an address, the organizer checks a map pin and confirms it. Changing the address clears that confirmation. An unavailable lookup can leave a draft unfinished; it does not become permission to publish an unconfirmed location.

The publishing model supports an exact address, an approximate location, or an address held until the sale starts. Protected map markers use an application-owned public zone, rather than a slightly shifted private coordinate. Search results and clusters follow the same public location rules.

This affects both the interface and the data underneath it. A map that looks approximate is not enough if another response still contains the private point.

The application uses Next.js App Router and strict TypeScript. Feature modules own their rules and services; route handlers compose those modules. Prisma connects to PostgreSQL, with PostGIS supporting location data. Custom email/password authentication uses opaque database sessions.

MapLibre renders the map, OpenFreeMap provides its launch style and tiles, and Geoapify handles server-mediated address lookup. Stripe-hosted Checkout handles the beta payment handoff. Verified webhooks and immutable publication snapshots keep browser navigation separate from the authority to publish.

I kept the application together as a modular monolith. The public search, organizer workflow, media handling, authentication, and payments each have boundaries without needing a separate service for every feature.

The website is available at its custom domain. The repository still identifies it as a stable production beta with search indexing disabled and payments in test mode. A live domain does not change those boundaries.

The feature set and screenshots document the product as it exists. They do not imply a public commercial launch, live payment processing, or any particular level of adoption.

Visit Estate Sales Bakersfield or read the project on GitHub.