Part 2: The FoodShare Pivot - Finding the Real Problem | Building Asset Hatch

The 83-Day Gap

Between August 13 and November 5, 2025, the repository sat mostly quiet. A handful of commits added MCP servers, updated dependencies, and refined the starter kit. But no real application emerged.

Then, on November 5th, everything changed with a single commit: f106882 - chore: bootstrap FoodShare project.

This wasn't just a code change. This was a pivot - the moment when a generic starter kit became a mission-driven application to address food insecurity.

The Problem Space

Food insecurity affects millions of Americans, but existing solutions have gaps:

Food banks and pantries exist, but:

People don't know which ones are nearby
Hours and services vary wildly
Finding current information is difficult
Making the first visit feels intimidating

Community sharing happens, but:

Facebook groups are cluttered and unstructured
Nextdoor is too general-purpose
Buy Nothing groups lack food-specific features
There's stigma in asking for help publicly

AI chat assistants could help, but:

Generic ChatGPT doesn't know local resources
They can't provide real-time hours or directions
They can't connect you with nearby neighbors
They lack the context to be truly helpful

The FoodShare Vision

The insight was simple but powerful: combine all three.

Build a hyperlocal food-sharing network that connects people experiencing food insecurity with:

Nearby Resources: Food banks, pantries, and community programs (AI-powered discovery)
Neighbor Support: Peer-to-peer food sharing within 2-5 mile radius (community potluck)
Empathetic Guidance: AI sous-chef for meal planning, directions, and resource navigation

The magic word? Hyperlocal. Not citywide. Not nationwide. Neighborhood-by-neighborhood, starting with Sacramento's Midtown district.

Why This Mattered

This wasn't just another food-sharing app. The design had several crucial differentiators:

1. Dignity-Preserving Design

Requests and offers would look identical in the interface. No visual hierarchy marking who's asking vs. giving. Only a subtle kind field in the database:

// src/lib/schema.ts
export const posts = pgTable("posts", {
  id: text("id").primaryKey(),
  userId: text("user_id").notNull().references(() => user.id),
  content: text("content").notNull(),
  kind: text("kind").notNull(), // 'share' | 'request' | 'update'
  mood: text("mood"), // 'hungry' | 'full' | 'neutral'
  // ...
});

This single decision - making requests indistinguishable from offers - removes stigma and preserves dignity for those in need.

2. The Sous-Chef Metaphor

Not a "food bank finder." Not a "social network." But a sous-chef - a helpful assistant who:

Knows your kitchen (saved locations)
Understands your needs (chat context)
Suggests recipes (meal planning)
Points you to ingredients (food banks)
Connects you with neighbors (community)

The metaphor mattered. It reframed the experience from "asking for help" to "cooking together as a community."

3. Walkable Radius

Most food-sharing apps think in terms of cities or zip codes. FoodShare thought in terms of how far you can walk or bike:

2-5 mile radius for community posts
Map-based discovery (not list-based)
Geolocation-first design
Mobile-optimized interface

This wasn't arbitrary. Many people experiencing food insecurity lack reliable transportation. Walking distance matters.

The Technical Pivot

The beauty of having a solid starter kit? Pivoting to a new domain was fast.

Day 1: Bootstrap (Nov 5)

The initial FoodShare commit added:

// Initial food bank schema
export const foodBanks = pgTable("food_banks", {
  id: text("id").primaryKey(),
  name: text("name").notNull(),
  address: text("address").notNull(),
  city: text("city").notNull(),
  state: text("state").notNull(),
  zipCode: text("zip_code"),
  latitude: real("latitude").notNull(),
  longitude: real("longitude").notNull(),
  phone: text("phone"),
  website: text("website"),
  services: text("services").array(),
  hours: json("hours").$type<HoursType>(),
  createdAt: timestamp("created_at").defaultNow().notNull(),
});

Clean, focused, and immediately actionable. No over-engineering. No premature optimization. Just the essential fields to make food banks discoverable.

Day 2: Branding (Nov 6)

Commit 41149ed completed the branding pivot:

Renamed to "FoodShare"
Added branded components (location-card.tsx, status-badge.tsx)
Implemented "Save Location" feature
Connected auth system to user preferences

The speed here is instructive. Because the authentication, database, and UI foundations existed, I could focus entirely on domain logic rather than infrastructure.

Product Strategy Decisions

Several early product decisions shaped everything that followed:

Decision 1: Sacramento First

Why start in Sacramento, not SF or Oakland?

Solo founder lives there (know the neighborhood)
Diverse community (mix of sharers and seekers)
Walkable (Midtown's grid layout)
Less competition (untapped market)
Human scale (can manually moderate early users)

This wasn't a scalability play. This was a beachhead strategy - prove it works in one neighborhood, then replicate.

Decision 2: Manual Seeding

Rather than building a nationwide food bank aggregator, I decided to manually seed Sacramento data:

# scripts/seed-food-banks.ts
// Hand-curated food banks with verified hours, services, and locations

Why manual? Because data quality matters more than quantity. Ten accurate, up-to-date food banks are more useful than 1,000 stale listings.

This decision had a hidden benefit: it forced me to understand the domain deeply. I learned about CalFresh, emergency food boxes, and the difference between a food pantry and a food bank by researching each location.

Decision 3: Managed Community

The plan: founder acts as first "guide" - manually facilitating exchanges, ensuring safety, building trust.

This avoided building complex moderation tools upfront. Instead:

Recruit 10-15 founding members personally
Manually match offers/requests
Gather feedback in real-time
Iterate on UX based on actual usage

It's the Airbnb approach - do things that don't scale to learn what matters.

Decision 4: Measure Real Exchanges

Success metric: completed food exchanges, not:

Number of posts
App downloads
Time spent in app
Likes or comments

This single metric forced product decisions toward real-world impact rather than engagement vanity metrics.

The Market Validation

Before committing months of development, I did lightweight validation:

Talked to 3 food bank coordinators:

Confirmed they struggle with outdated online listings
Heard they'd welcome better discovery tools
Learned about gaps in existing food-sharing networks

Interviewed 5 potential users in Midtown:

Validated that Facebook groups are frustrating
Confirmed transportation is a barrier
Heard requests for meal planning help (not just food finding)

Researched competitors:

Buy Nothing Project: Great for general items, but not food-focused
Olio: UK-based, limited US presence
Too Good To Go: Restaurant surplus, not neighbor-sharing
Nextdoor: Too general, poor food-sharing UX

The gap was real. No one was building hyperlocal, dignity-preserving, AI-assisted food sharing.

The "Why Now?" Moment

Several trends converged to make November 2025 the right time:

LLM maturity: Models like Claude Sonnet 4.5 could handle nuanced, context-aware conversations
AI SDK tooling: Vercel AI SDK made tool calling trivial
Better Auth stability: v1.3.34 was production-ready
Mobile-first web: PWAs rivaled native apps
Rising food costs: Inflation made food sharing more attractive

Plus a personal catalyst: I had the starter kit ready. The technical barrier was low enough that I could focus on the problem, not the plumbing.

What Could Have Gone Wrong

Looking back, this pivot had risks:

Risk 1: Too Niche

Hyperlocal means smaller addressable market
Mitigation: Start small, prove model, replicate

Risk 2: Regulatory Complexity

Food safety, liability, etc.
Mitigation: Start with packaged goods, add guidelines, defer liability concerns

Risk 3: Chicken-and-Egg

Need both sharers and seekers
Mitigation: Founder acts as bridge, manually facilitates first exchanges

Risk 4: Hard to Monetize

Social impact ≠ revenue
Mitigation: Plan for grants, 501c3, not VC funding

I accepted these risks because the problem was worth solving, even if the business model wasn't clear.

What I Learned

This pivot taught me several lessons:

Strong Foundations Enable Fast Pivots: The starter kit's quality let me focus on domain logic, not infrastructure.
Constraints Breed Clarity: Choosing Sacramento forced concrete decisions about walking radius, seeding strategy, and community management.
Dignity Matters in Design: The decision to make requests/offers indistinguishable wasn't cosmetic - it was core to the product's value proposition.
Manual Doesn't Mean Wrong: Rejecting automation early (manual seeding, manual moderation) led to deeper domain understanding.
Pick Metrics That Matter: "Completed exchanges" forced me to build features that drive real-world impact, not just engagement.

The Rapid Prototyping Sprint

With the pivot decided, the next week (Nov 6-9) was a building blitz. In 4 days, I shipped:

Interactive Mapbox map with food bank markers
AI chat with food bank search tools
User profiles with saved locations
Community feed (initial mockup)
Mobile-first bottom navigation

That sprint is the subject of the next four posts - building the map, the AI sous-chef, community features, and event hosting.

But the foundation was laid here, on November 5th, with a simple commit message: "chore: bootstrap FoodShare project."

Sometimes, the most important commits are the smallest.

Up Next

In Part 3, I'll dive into building the map discovery system - integrating Mapbox GL, seeding Sacramento food banks, implementing geolocation search, and creating an interface that puts food resources literally on the map.

Key Commits:

f106882 - Bootstrap FoodShare project
41149ed - Complete FoodShare branding and save location feature

Related Files:

context/info.md - Vision and product strategy
context/decisions.md - Product and UX decisions
src/lib/schema.ts - Food bank schema definition