Project Harvest: Making Local Agriculture Experienced Easier to Discover
Inspiration
Project Harvest began with a simple question:
What is available near me, right now?
People want to support nearby farms, markets, orchards, farm stands, nurseries, and other agricultural businesses, but finding timely information is surprisingly difficult. A conventional search engine may reveal that a farm exists without telling someone whether fresh strawberries are still available today. A social media post by a roadside market stand may be current but hard to discover. A directory may contain useful addresses but little evidence that its information is still accurate.
At the same time, many small growers/producers do not have the time, staff, or technical resources to maintain complex digital storefronts. I was inspired by the possibility of closing that gap without creating a popularity-driven marketplace/social media platform. I wanted to create a trusted discovery tool that respects both sides: a simple way for people to find local products and experiences, and a practical way for local vendors to become more visible without sacrificing privacy or control.
That idea became Harvest, a map-first platform built around reliability rather than popularity. Its purpose is not to become the “Amazon of local food" or simply a "Google Maps but focused on agriculture." Its purpose is to help communities understand what is nearby, what may be available (growing/being harvested) now, how recently the information was updated, and why a result deserves confidence.
What We Built
Harvest is a mobile-first progressive web application that allows users to explore and search for local produce and agriculture-based experiences, and open privacy-aware vendor profiles.
The platform treats farms, farmers markets, farm stands, orchards, community-supported agriculture programs, dairies, meat and egg producers, maple and honey operations, nurseries, and garden centers as important parts of the local agricultural ecosystem.
Harvest combines several kinds of evidence:
- Current vendor updates
- Recent community confirmations
- Harvest-reviewed records
- Approved public sources
Its built-in assistant, Sprout, turns natural-language questions—such as “Where can I find fresh eggs within 10 miles?” or “Which nearby nursery has native plants?”—into focused searches across Harvest’s trusted data.
Sprout is deliberately limited. It must never invent vendors, products, availability, or sources. When information is stale, uncertain, or conflicting, Harvest communicates that uncertainty and encourages the person to call ahead.
Community members can report an item as:
- Available
- Limited
- Sold Out
- Unable to verify
These confirmations provide additional evidence but never silently overwrite a vendor’s own update. Users can also change or undo accidental reports, and authenticated confirmations can persist across sessions.
We built vendor ownership, profile editing, manual approval, and three location-privacy modes:
- Exact location for vendors who want to publish a precise destination.
- Approximate location for vendors who prefer a generalized public map point.
- Shared after contact for vendors whose address, coordinates, distance, and directions must remain private.
Approval and verification are intentionally separate. A profile may be approved for publication without implying that Harvest has independently verified every claim it contains.
How We Built It
We developed Harvest through a sequence of small, testable checkpoints instead of attempting to build the entire vision at once.
The frontend uses React, TypeScript, and Vite as a mobile-first progressive web application. MapLibre powers the map experience. Supabase provides passwordless authentication, PostgreSQL and PostGIS storage, row-level security, account-backed confirmations, vendor ownership, privacy-safe public data, and structured search through database functions. Cloudflare Pages provides preview deployments and continuous delivery from the project repository.
The product evolved deliberately:
- We first proved the guest-first map and discovery experience using fictional data.
- We added availability confirmations with correction and undo behavior.
- We introduced magic-link authentication while preserving guest browsing.
- We moved Sprout’s retrieval system from bundled records to the live Supabase catalog.
- We added vendor profiles, ownership, approval states, visit details, privacy modes, and public publication rules.
- We connected live product offerings and availability while preserving clear source and trust boundaries.
- We added regression tests, validation reports, migration records, recovery procedures, and exact-build checkpoints.
- We completed an offline production-design baseline and synchronized it with the project’s source-of-truth documentation before moving into Figma construction and native visual quality assurance.
Our search philosophy can be represented conceptually as:
$$ S(v,q)=w_rR(v,q)+w_fF(v)+w_cC(v)+w_dD(v), \qquad w_r+w_f+w_c+w_d=1 $$
In this model:
- (R) represents relevance to the user’s request (q).
- (F) represents the freshness of the information.
- (C) represents confidence in the supporting evidence.
- (D) represents geographic usefulness.
This is not a popularity score. Payment and popularity do not increase factual confidence or organic relevance.
We used fictional, Pennsylvania-realistic vendors and test coordinates while validating the system. This allowed us to test discovery, privacy, conflicting reports, expiration, and approval workflows without presenting a real business as a participant or risking the disclosure of a private location.
Documentation became part of the development process rather than an afterthought. Product requirements, founder decisions, technical specifications, design contracts, validation reports, release gates, and historical evidence were maintained in a synchronized source-of-truth Library.
That discipline allowed us to distinguish among completed work, approved offline design, active engineering, and features that remain intentionally gated.
Challenges We Faced
The hardest challenge was not placing pins on a map. It was deciding what those pins could honestly promise.
“Available now” is a time-sensitive claim. Vendor updates may age, community reports may conflict, and a product may sell out while someone is driving to the farm. We had to design freshness decay, visible uncertainty, source attribution, and conflict handling so Harvest would never present weak evidence as certainty.
Privacy created another important challenge. Some agricultural businesses welcome visitors at a public storefront. Others operate from private residences or share pickup details only after direct contact.
We had to enforce those distinctions across the database, search results, map, directions, distance calculations, and public profiles. Hiding an address on one screen would be meaningless if the location could still be exposed somewhere else.
Authentication also required careful iteration. Magic-link rate limits complicated live testing, and signing out on one device raised a broader question: should another active session remain valid?
We ultimately added global logout and cross-session revocation. We then treated acceptance testing as a release gate rather than assuming that passing source-code checks was sufficient.
We encountered ordinary engineering problems as well:
- Failed deployment configurations
- Migration sequencing
- Map markers shifting during zoom
- Search-state restoration
- Refresh behavior
- The risk that a frontend update could accidentally clear a stored PostGIS location
Each issue reinforced the importance of narrow changes, recovery procedures, automated regression tests, and exact-build validation.
A less visible challenge was controlling the project’s scope. Harvest has many promising possible directions—including payments, ordering, delivery, social features, automated imports, paid analytics, and native applications—but adding them too early would weaken the promise that matters most.
We adopted explicit cost and release gates, used free infrastructure wherever practical, and deferred expansion until the core discovery and trust model could be proven.
Finally, we learned that visual design, engineering, and documentation can drift apart even when each area is strong on its own. We addressed this by establishing controlled change manifests, a documentation visual system, founder decision records, and post-synchronization discrepancy audits.
That work was meticulous, but it prevented older drafts or attractive exploratory mockups from silently becoming product requirements.
What We Learned
Our biggest lesson is that trust is a product feature, not merely a label.
A badge alone cannot make information reliable. Trust comes from provenance, timestamps, privacy rules, visible disagreement, correction paths, and a willingness to say, “We cannot verify this.”
We also learned that exploration should not require commitment. Allowing people to browse before creating an account makes Harvest immediately useful. Authentication appears only when someone wants to save, follow, contribute, or personalize the experience.
Another lesson was that disciplined boundaries accelerate meaningful progress. By keeping ordering, payments, reviews, broad social features, and premature automation outside the current release, we were able to focus on the harder foundational work:
- Reliable retrieval
- Privacy-safe publication
- Availability confirmations
- Session safety
- Clear supporting evidence
Most importantly, we learned to treat uncertainty honestly. The best answer is not always the most confident answer.
Sometimes the most useful response is a recent vendor update. Sometimes it is a community report accompanied by a warning. At other times, it is a clear recommendation to call ahead.
Where We Are Going Next
Harvest is production-connected and has reached its RC0 public-readiness phase, but it is not yet open for public registration or launch.
The approved offline design system and production component contracts are complete. The next work includes:
- Figma construction
- Native and exact-build visual and accessibility quality assurance
- Controlled tester activation
- Operational preparation for support and account lifecycle management
- Monitoring, recovery, and incident-response planning
Our long-term goal is to make Harvest the most trusted way to discover and support local agriculture—starting in Pennsylvania, learning carefully through a controlled pilot, and expanding only when the evidence demonstrates that the model works.
The vision remains the same as the question that inspired us:
Help people find what is growing, raised, made, and available near them—right now—without asking them to trade trust for convenience.
Built With
- cloudflare-pages
- codex
- gpt-5.6
- maplibre-gl
- postgresql
- react
- supabase
- typescript
- vite
