NeighborhoodShare: AI-Powered Community Tool Sharing Platform

Full-Stack Development | AI Integration | Community Platform

Project Timeline: February - September 2025
Status: Prototype | 170 Users | 20 Active Communities
Tech Stack: React + TypeScript | Node.js + PostgreSQL | OpenAI GPT-4o Vision

Overview

NeighborhoodShare is a full-stack community tool-sharing platform that enables neighbors to lend and borrow tools within their local area. Built in 2025 as a solo project using AI-assisted development, the platform demonstrates sophisticated full-stack capabilities, AI integration, and professional engineering practices.

Platform Results:

• 170 total users across 20 active zip codes
• 75-80 tools cataloged using AI categorization
• 6-month development cycle (Feb-Sept 2025)
• Solo developer using AI-assisted development
• $1,500 total development cost

Key Technical Achievements:

• AI-powered tool categorization from photos (OpenAI GPT-4o Vision)
• Dual-authentication state machine preventing disputes
• Geographic expansion strategy with zip code clustering
• Multi-channel notification system (email, SMS, in-app)
• Security incident response with API monitoring
• Professional dev/prod database separation

What This Demonstrates:

1. Full-stack capabilities - Complete application from authentication to deployment
2. AI integration expertise - Novel use of GPT-4o Vision for practical problem-solving
3. Systems thinking - Complex state management, geographic strategy, governance design
4. Professional practices - Security response, monitoring infrastructure, scalability
5. AI-assisted development - Effective use of modern development approaches
6. Learning from validation - Technical success + market insights = valuable experience

The Problem

The project began with a simple observation: neighbors have the tools, skills, and capacity to help each other, but most people don't even talk to their neighbors.

Origin Story: The Angle Grinder Moment

A neighbor needed help lowering a bike seat post. I suggested using an angle grinder—a simple 5-minute fix. He stared at me blankly. "Angle grinder?" He'd never heard of one.

I invited him over, showed him the tool, demonstrated how to use it, and fixed the problem in minutes. That moment sparked a realization: the solutions to our problems exist all around us. Neighbors have the skills, capacity, and tools to help each other—but we lack the infrastructure to connect people with resources.

Core Challenges

Discovery: How do you know what tools your neighbors have?

Friction: Cataloging tools manually is tedious—nobody will do it. Traditional inventory systems require entering tool name, category, brand, model, condition, and description. This creates a barrier that kills adoption.

Coordination: How do you request, track, and return borrowed items without constant back-and-forth messaging?

Trust: How do you ensure items get returned on time and in good condition, especially between strangers? What prevents "he said, she said" disputes?

Geographic Scale: "Neighborhood" means different things to different people. Urban San Jose: 2 miles. Rural communities: 25-50 miles. The system needed flexible boundaries.

Technical Approach

Architecture & Tech Stack

Full-stack web application built with AI-assisted development in Replit:

Frontend:

• React 18 + TypeScript (type safety throughout)
• Vite build tool (fast development, optimized builds)
• Wouter routing (lightweight alternative to React Router)
• Tailwind CSS (rapid UI development)

Backend:

• Node.js with Express
• PostgreSQL database (hosted on Neon)
• Drizzle ORM (lightweight, no code generation)
• Passport.js authentication
• Express-session with PostgreSQL storage

AI & Integrations:

• OpenAI GPT-4o Vision API (tool categorization from photos)
• Resend (email delivery)
• Twilio (SMS notifications)
• PostHog (product analytics)

Development:

• AI-assisted development using Replit agent
• First "vibe coding" attempt
• Detailed PRDs + feature specs → AI implementation
• 30 years of product/QA experience directing AI

Database Architecture:

• Single Neon PostgreSQL database
• Development environment: public schema (safe testing)
• Production environment: production schema (live user data)
• Schema switching via config file
• Admin dashboard warns prominently when operating on production

This separation enabled testing schema changes without breaking production—professional practice even for an MVP.

Key Technical Features

1. AI-Powered Tool Categorization

The Innovation: Users photograph tools from 2-4 angles. OpenAI GPT-4o Vision API processes images (30-60 seconds) and automatically fills in:

• Tool name ("Cordless Drill", "4-1/2 inch Angle Grinder")
• Category selection (Power Tools, Hand Tools, Gardening, etc.)
• Brand identification (DeWalt, Milwaukee, even sewing machine models)
• Power type (battery/electric/manual)
• Condition assessment (New, Like New, Good, Fair, Poor) based on visual inspection
• Model number extraction from visible labels
• Generated description (2-3 sentences about the item and typical uses)

Impact: Dramatically reduces friction. Instead of tedious form-filling, users just photograph their tools. No manual typing required.

Development Challenge: Prompt engineering took ~1 week to refine. System needed to:

• Identify specific tool models from visible text
• Assess condition from wear/damage in photos
• Gracefully handle edge cases (return "cannot identify" rather than guessing)

Success Rate: High accuracy after refinement:

• Tool identification: Very accurate for common tools
• Brand recognition: Excellent for major brands AND niche items
• Condition assessment: Reasonable accuracy, users can override
• Model extraction: Works when visible in photos

Key Insight: The AI was particularly good at saying "I can't identify this thing" rather than making wild guesses—building user trust through honest limitations.

Cost Consideration: At $10/month OpenAI budget, never exceeded limits during beta. Each tool entry = 2-4 images = ~$0.10-0.20 per cataloging operation.

2. Dual-Authentication State Machine

The Challenge: How do you prevent "he said, she said" disputes about item pickup and return?

The Solution: Loan state machine with dual authentication at key transitions.

Loan Lifecycle:

available
  ↓ borrower requests
requested (pending approval)
  ↓ lender approves
approved (waiting pickup)
  ↓ borrower confirms pickup
pending_lender_pickup_confirmation
  ↓ lender also confirms pickup
checked_out (item with borrower)
  ↓ return date passes
overdue (escalating reminders)
  ↓ borrower confirms return
pending_lender_return_confirmation
  ↓ lender also confirms return
returned (transaction complete)

Dispute Prevention: Both borrower AND lender must confirm pickup and return. Creates audit trail where both parties agree on every state transition.

Notification Escalation:

• Day before due: "Pickup/return tomorrow" (both users)
• Day of due: "Pickup/return today" (both users)
• 3 days overdue: First escalated reminder
• 5 days overdue: Second escalation
• 6+ days: Daily reminders

Philosophy: "Mutual Annoyance"

Both parties receive all overdue reminders. The system creates incentive to resolve situations quickly rather than letting transactions languish. By annoying both parties equally, the system motivates them to coordinate return.

Technical Implementation:

• PostgreSQL loan table tracks state + confirmation flags
• Event-driven notifications trigger on state changes
• Cron jobs run twice daily (9-10am, 5-6pm Pacific) for time-based reminders
• Duplicate prevention via last_reminder_sent timestamp

3. Beta Expansion System with Captain Governance

Geographic Strategy: Sophisticated zip code clustering for neighborhood activation.

Activation Criteria:

• Primary: 20+ users in single zip code, OR
• Adjacent: 18 users in primary + 2 in adjacent zip code (within 5-mile radius)

Admin Dashboard Metrics:

• Total users: 170 at peak
• Active zip codes: 20
• Interested users awaiting activation: 82
• Watch list (15+ users, needs captain): Tracks neighborhoods ready for launch
• Zip codes ready to activate: System calculates automatically

Captain System (Designed, Not Yet Deployed):

Neighborhood moderators with authority to:

• Authorize new users in their zip code
• Manage local disputes
• Email neighborhood members
• Promote community engagement

Design Philosophy: Decentralized community moderation enables platform scaling beyond single admin. Captains handle neighborhood-level issues, escalating to platform admin only when necessary.

Why It Matters: Demonstrates systems thinking about organizational scaling—recognizing that technical success requires governance infrastructure.

4. Security Incident Response

The Incident: OpenAI API key stolen from public Replit project, resulted in ~$50 unauthorized charges over 2 weeks.

Discovery Process:

1. Mike noticed visitor to Replit project (projects default to public)
2. Made project private, thought problem solved
3. Weeks later: OpenAI budget exceeded notification
4. Compared app usage analytics (PostHog) to OpenAI token usage
5. Mismatch discovered: Way more API calls than user activity
6. Realization: API key stolen before project made private

Root Cause:

• Replit projects default to public visibility
• API keys not properly obfuscated using Replit Secrets
• Environment variables exposed in multiple code locations

Response Actions:

Immediate (within hours):

• Disabled compromised API key
• Generated new key
• Conducted security audit with Replit AI
• Found all exposure points
• Properly implemented environment variable usage

Short-term (next week):

• Implemented rate limiting (10 queries/hour per verified user)
• Added origin verification (API calls must come from app domain)
• Created AI Monitoring dashboard tracking usage patterns

Long-term:

• Regular security audits
• Project permanently private
• All API keys in Replit Secrets

Learning: Professional incident response demonstrates:

• Quick detection (monitoring spend alerts)
• Root cause analysis (audit codebase)
• Immediate mitigation (disable key)
• Long-term prevention (rate limiting, monitoring)
• Ongoing visibility (admin dashboard)

Additional Technical Features

Privacy Controls:

• Exact address hidden until loan approved
• Alternate pickup locations (coffee shop, library instead of home)
• User-controlled address visibility toggle
• Public display shows city/state only

Authentication:

• Email + password only (deliberate simplicity, privacy-respecting)
• Email verification required before borrowing
• Bcrypt password hashing
• Session management via PostgreSQL storage

Notifications:

• Multi-channel delivery (in-app, email, SMS)
• User preference controls
• Deep links to action screens
• Escalating reminder frequency

Search:

• Adjustable radius (2-50 miles) for urban/suburban/rural contexts
• Geographic distance calculations using PostGIS patterns
• Location-based tool matching

Admin System:

• Remote management without database queries
• User management (verify, block, promote to admin)
• Tool moderation
• Loan tracking and dispute resolution
• Beta expansion monitoring
• AI API usage tracking

Transaction History:

• Complete audit trail stored for dispute resolution
• All notifications logged
• Loan state changes preserved with timestamps
• Communication history in JSONL format

Development Process

Timeline & Effort

February 2025: Planning

• Created detailed PRD (Product Requirements Document)
• Defined MVP scope
• Researched tech stack options
• Decided on Replit for AI-assisted development

March-April 2025: Initial Development

• Built authentication system
• Implemented database models
• Created basic UI with React + Tailwind
• AI categorization proof-of-concept
• 5-20 hours/week

May 2025: Prototype Launch

• Functional MVP: add tools, browse, basic borrowing workflow
• Internal testing
• Refinement of AI prompts

June 2025: Beta Opened

• Expanded to local neighborhood (door-to-door recruitment)
• ~30 signups from San Jose community
• Added SMS notifications
• Built admin dashboard
• 20-30 hours/week

July-August 2025: Beta Expansion

• Promoted on Resilient Tomorrow Substack
• Added beta management system
• Captain system designed
• Reached 170 total users across 20 zip codes
• API security incident and response

September 2025: Development Paused

• Adoption analysis: tool borrowing insufficient engagement frequency
• Strategic reassessment
• Decision to pivot to broader community platform

Total Investment: ~$1,000-1,500 over 6 months (Replit hosting + API costs)

AI-Assisted Development: First "Vibe Coding" Project

Key Quote: "I could not have written this product. I'm a product manager and designer. I know my way around code but don't know syntax. This was largely AI-generated with me making decisions about approach."

Development Approach:

Phase 1: Detailed PRD

• Wrote comprehensive product requirements
• Defined all user flows
• Specified data models
• Outlined feature priorities

Phase 2: Replit Agent Implementation

• Provided PRD to Replit AI
• AI generated initial codebase
• Iterative refinement through conversation

Phase 3: Feature Specs for Post-MVP Additions

• Used ChatGPT to write feature requirements
• Created Mermaid diagrams for complex workflows
• Provided detailed specs to Replit agent for implementation

Key Insight: "Back to Waterfall"

"For the past 25 years in product development I've been working in a very agile system... and now we're back to coming up with full specs and handing that over for development. Hey kids, that's what waterfall is!"

AI works better with detailed upfront specs than iterative Agile-style development. This doesn't mean Agile is dead—it means AI-assisted coding benefits from different processes than human team collaboration.

Directing AI with Product Expertise:

30 years of product/QA experience enabled effective AI collaboration:

"I'd often times when the AI was doing something that I'm like, 'I don't think you're doing the right thing,' and it would say, 'No, this is how you have to do it.' I'd push back on it, and most of the time we could figure out what was broken together. A lot of times when the AI would be trying to diagnose something, I'd be like, 'I don't think that's the problem. I think the thing you're chasing is wrong. I think we should be looking here.' And I would say 8 out of 10 times, I was right."

What AI Did Well:

• Generated boilerplate code quickly
• Implemented standard patterns (CRUD operations)
• Created database queries
• Built form validation
• Structured React components

What Required Human Direction:

• Business logic decisions
• User experience flows
• Security considerations
• Edge case handling
• Debugging when AI went down wrong path

Value of Domain Expertise:

Domain expertise + AI assistance can substitute for coding expertise in many contexts. The skill is directing AI effectively, not writing every line yourself.

Results & Validation

Technical Success ✅

Achieved:

• ✅ Fully functional platform delivered
• ✅ All MVP features implemented and working
• ✅ Professional development practices demonstrated
• ✅ Multi-service integration operational
• ✅ Production-ready deployment
• ✅ Security incident resolved with monitoring

Platform Metrics:

• 170 total signups
• 20 active zip codes
• 75-80 tools listed
• 82 users awaiting neighborhood activation

Technical Execution: Platform works beautifully. Users can successfully browse, request, borrow, and return tools with dual authentication, multi-channel notifications, and state tracking.

Market Validation Learning 📊

Key Finding: Tool borrowing alone provides insufficient engagement frequency for sustained platform growth.

Engagement Analysis:

• Users excited about the concept ✅
• Easy signup process ✅
• AI categorization reduced friction as intended ✅
• Neighborhood-focused approach resonated ✅

But:

• Low tool listing rate (only ~6% of users listed tools)
• Minimal borrowing activity
• Tool borrowing frequency: infrequent (every 6 months maybe)

Root Cause Insight:

Borrowing a tool is not something you do daily or weekly like social media. Network effects require critical mass, but usage too sparse to build momentum.

Strategic Assessment:

"We don't need another platform where we just are talking; we need a platform for organizing."

Tool-sharing should be a feature within a broader community organizing platform, not a standalone product.

What This Demonstrates

For Employers:

1. Full-stack capabilities - Complete application from auth to deployment
2. AI integration expertise - Novel use of GPT-4o Vision for practical problem
3. Systems thinking - State machine, geographic strategy, governance model
4. Professional practices - Security response, monitoring, scalability design
5. Learning from validation - Technical success + market insights = valuable experience
6. AI-assisted development - Effective use of modern development approaches

Honest Assessment:

Technical execution ≠ market validation. The platform works beautifully from a technical perspective, but technical success doesn't equal product-market fit.

Not every project succeeds in market. That's okay. What matters: demonstrated sophisticated full-stack development capabilities and professional engineering practices.

These are valuable, transferable skills regardless of market outcome.

Technical Learnings

What Worked Well

AI Tool Categorization:

• Took time to refine prompts (~1 week) but result was excellent
• GPT-4o Vision highly accurate for tool identification
• Graceful failures (system says "can't identify" rather than guessing)
• Users trusted AI suggestions, rarely overrode
• Lesson: AI features that genuinely reduce user friction are worth the integration effort

Dual Authentication State Machine:

• Prevents disputes through technical design, not policies
• Lesson: Build trust into the system itself, not just terms of service

Dev/Prod Database Separation:

• Seems obvious to experienced developers, but many early-stage projects skip this
• Lesson: Professional practices from day one prevent painful data recovery later

Admin Dashboard:

• Built post-MVP when operational needs became clear
• Enables sustainable remote management
• Lesson: Build admin tools when operations become painful, not before

What Was Challenging

Replit Context Window:

• AI would "forget" earlier decisions, requiring constant reminders
• Lesson: AI-assisted development works better with frequent explicit context refresh

Loan State Machine Complexity:

• Many states, many transitions, many notification triggers
• Lesson: State machines are conceptually simple but implementation complexity grows rapidly. Diagrams essential.

API Security:

• Didn't realize Replit projects default to public
• Lesson: Default-secure practices must be intentional from project creation

Adoption Challenges:

• Technical success doesn't guarantee product success
• Lesson: Market validation is separate from technical validation. Build MVPs quickly to test hypotheses.

What Would Be Done Differently

Different Development Platform:
"I would not stay with Replit. I would move to Claude Code or similar."

Why:

• Code ownership (easy export to GitHub)
• Better context management
• More control over deployment
• Git version control from day one

Own the AI Model:
"What I would do now is train my own LLM on returning this data. Host my own LLM in the cloud."

Benefits:

• Lower per-request costs
• Not dependent on OpenAI pricing changes
• Fine-tuned for specific tool categories
• Own the training data

No Regrets on MVP Scope:
"I'm really happy with this product! I think it works great."

The right features were built. What needs to change: market approach, not technical implementation.

Future Direction

Strategic Pivot: Community-First Platform

Development paused, not abandoned.

Vision: NeighborhoodShare becomes one feature within a broader platform enabling:

• Event coordination (neighborhood meetings, block parties, workshops)
• Project collaboration (community gardens, solar installations, cleanup efforts)
• Mutual aid (meal trains, childcare co-ops, ride sharing)
• Resource sharing (tools, books, kitchen equipment, vehicles)
• Knowledge sharing (skill swaps, how-to guides, local recommendations)

Tool-sharing provides practical value. Events provide regular engagement. Projects provide meaning.

Next Steps (When Resumed)

Evaluate Mobilizon: Events-first Fediverse platform for local communities as potential foundation

Convert to Native Mobile App: Web-first worked for beta, but app distribution would help with push notifications and offline support

Library Partnership Strategy: Public libraries already operate tool lending programs—partnership could provide trust, legitimacy, and built-in user base

Connection to Resilient Tomorrow

Pillar 3: Access > Money
"Wealth is not the number in your bank account—it's the number of needs you can meet without spending it."

Tool-sharing reduces spending while increasing access. Neighbors don't need $300 drills if someone nearby has one to lend.

Pillar 7: Hyperlocal Community
"Build relationships within walking distance. Your immediate neighbors are your most important network in times of disruption."

Tool-sharing creates practical reasons for neighbors to meet and build trust before crises happen.

Long-term Vision:

Looking at the next 5-10 years, I anticipate harder times where mutual aid and hyperlocal community support will be essential. NeighborhoodShare tests hypothesis: Can practical resource-sharing bring neighbors together?

Answer: Tool-sharing alone insufficient. Needs broader community organizing infrastructure.

But the technical foundation is solid. The vision remains.

Technologies Used

Frontend: React 18, TypeScript, Vite, Wouter, Tailwind CSS
Backend: Node.js, Express, PostgreSQL, Drizzle ORM
Authentication: Passport.js, Bcrypt, Express-session
AI: OpenAI GPT-4o Vision API
Services: Neon (database), Resend (email), Twilio (SMS), PostHog (analytics)
Platform: Replit (AI-assisted development, hosting, deployment)
Development: AI-assisted (Replit agent), PRD-driven, detailed feature specs

Project Impact

Technical Demonstration:
This project showcases practical AI infrastructure skills: AI integration, full-stack development, state machine design, security incident response, admin systems, and AI-assisted development workflows.

Community Resilience:
Looking ahead 5-10 years, I anticipate harder times. This project tests ideas for mutual aid, data sovereignty, and hyperlocal support systems.

Personal Mission:
I'm building the world I want to live in—a world where neighbors help each other, where AI works for people (not corporations), where access matters more than money, where community isn't just a buzzword but infrastructure.

Case study published February 2026
Technical documentation by TED (Technical-Research-Agent)
Project timeline: February - September 2025
Solo developer: Mike Jones