Evergrn — Product Roadmap
Last updated: June 2026
This document is the single source of truth for planned product work. It covers pre-launch blockers, near-term post-launch features, and longer-horizon initiatives. Organized by phase, not by priority score — phase determines when something is actionable.
Phase 0 — Pre-Launch Blockers
See current-documentation/go-live-checklist.md for the authoritative status of all launch blockers. One remaining: mobile BASE_URL.
Phase 1 — Post-Launch Stability (Month 0–6)
Launched, first real users. Focus: reliability and provider retention.
| Item | Notes |
|---|---|
| ACH payment option | Rural older demographics prefer ACH over card. Add via Stripe as secondary payment method. |
| Automated rebooking reminders | Push/email prompts before seasonal transitions (e.g., lawn→snow in September). Directly addresses customer churn. |
| Provider success outreach | Day 7 / Day 30 / Day 90 check-in flow (could be manual via Telegram bot initially). |
| Review prompts | Automated push notification asking for review 24h after job COMPLETED. |
| Home cleaning service type | Add homecleaning to the service enum and surface it in the app alongside lawncare, snowplowing, handyman. Schema and mobile already have groundwork started. |
| HVAC, plumbing, and electrical | Expand into licensed trades. License verification infrastructure already built (LICENSED_SERVICES in licenseCheck.js, Maine registry scraper, ProviderLicense model). Provider registration, booking UI, scope-of-work, and market-rate pricing all updated. Primary remaining work: provider supply recruitment per market and state-specific license registry expansion beyond Maine. |
| Application-level message encryption | Encrypt content field in the Message table (AES) on write, decrypt on read in src/routes/messages.js. Server holds the key. Azure infrastructure AES-256 protects at disk level already, but app-layer encryption is the next step. |
| Stripe Connect for provider payouts | Replace internal ledger with Stripe Connect so payouts are handled by Stripe rather than a manual batch process. High effort but removes payout liability from the platform. |
Phase 2 — Growth Features (Month 6–18)
Platform is stable, adding ZIP clusters. Focus: conversion, retention, and differentiation.
| Item | Notes |
|---|---|
| Featured provider placement | Providers pay for priority surfacing in their ZIP. 100% margin revenue stream. Straightforward to implement once the quote-matching logic is solid. |
| Preferred Pro subscription | $39/month deducted from first job payout each calendar month. Reduced platform commission (12% vs 18%) in exchange. Documented in business-plan.md Section 4.3. |
| Provider referral program | $50 credit after referred provider completes 5 jobs. Key rural retention mechanism. |
| Customer referral program | $20 credit per referred customer who completes a booking. Cheapest acquisition channel at scale. |
| Offline-capable mobile sync | Rural broadband at 63% penetration means connectivity gaps are real. Queue actions locally and sync on reconnect. |
| Read replica (analytics) | Route the Preferred Partner Hub aggregate queries off the primary DB. Needed around Month 15–18 per infrastructure plan. |
| Provider scheduling export | Let providers export their Evergrn schedule to Apple Calendar / Google Calendar. Reduces friction for providers juggling multiple apps. |
| Multi-ZIP service area management | Currently ZIP codes are stored as a flat array. Build a proper UI for providers to manage their service territory — add/remove ZIPs, set per-ZIP availability. |
Phase 3 — Scale & Differentiation (Month 18–36)
New England expansion underway. Focus: stickiness, new revenue streams, and community moat.
| Item | Notes |
|---|---|
| Series A fundraise / revenue-based financing | Target Month 18–24 at $111K–$258K GMV/month. See business-plan.md Section 5.3. |
| Horizontal API scaling | Multiple instances behind Azure Load Balancer. Trigger: ~$258K GMV/month (Month 24). See infrastructure scaling plan. |
| Seasonal bundling | Let customers pre-purchase a full lawn season (e.g., 12 mows) at a slight discount. Creates forward revenue and reduces churn. |
| Background check integration | Third-party provider vetting (Checkr or similar). Becomes a trust signal as the platform grows and customers have more options. |
| ACH payout batching at scale | Once Stripe Connect is live, evaluate direct ACH for larger providers who prefer bank transfer over debit card payout. |
Phase 4 — Premium Community (Future)
Long-horizon. Requires moderation infrastructure and sufficient user density per ZIP to be valuable.
Concept
Both premium subscription tiers (customer and provider) get access to a ZIP-code-scoped community — a moderated forum or feed attached to their account.
Provider Community
- Share jobs they can't take ("I'm booked this Saturday, anyone in 04401 want this lawn?")
- Coordinate coverage during high-demand periods (storms, spring rush)
- Trade tips on equipment, pricing, customer handling
- Announce availability or seasonal transitions
Customer Community
- Share experiences with providers (beyond star ratings — actual conversation)
- Recommendations for specific job types ("who do you use for gutter cleaning?")
- Neighborhood tips ("heads up, road work on Elm St will affect access this week")
- Post jobs informally before creating a formal booking
Why it builds moat
The community is a network-effect layer on top of the transactional layer. Users embedded in a community are meaningfully harder to pull to a competitor than users who only transact. The ZIP-scoped model means the community is always locally relevant — no national noise.
Requirements before building
- User density: A community needs enough members per ZIP to generate organic conversation. Likely not viable until 50+ active users per ZIP cluster.
- Content moderation: Human moderators are required. Cannot rely on algorithmic moderation alone for a trust-based local community. Plan for at least one part-time community manager before launch — this is a staffing decision, not just a product decision.
- Gating: Access tied to active premium subscription. Prevents spam and keeps the community quality high. Losing a subscription means losing community access.
- Reporting and appeals: Moderation tooling needs to be built or bought (consider integrating a third-party community platform rather than building from scratch).
Build vs. buy consideration
Before building community infrastructure from scratch, evaluate whether an embedded third-party community platform (Circle, Discord with invite gates, or similar) could serve the early-stage need. Building a full forum system is high effort; the feature value is in the network, not the UI.
Deferred / Parked Ideas
These have been raised but are not yet slotted into a phase. Capture here so they don't get lost.
| Idea | Notes |
|---|---|
| Offline-first mobile app | Sync queue for job actions in low-connectivity areas. Parked in Phase 2 but may move earlier if rural broadband issues surface in field testing. |
| Provider insurance verification | Auto-verify COI documents via a third-party API. Adds trust but significant ops complexity. |
| In-app tipping | Let customers tip providers post-job. Simple Stripe charge, goes 100% to provider. Good will builder. |
| Home cleaning | Service type is partially scaffolded. Full launch requires provider supply in this category, which is a separate recruitment effort from lawncare/snow/handyman. |
| Web push notifications | Currently push is mobile-only (expo-notifications). Web customers don't get real-time updates. Could add web push via browser Push API. |
| Dark mode | Mobile only. Low priority but commonly requested on consumer apps. |
How to use this document
- When starting a new feature, move it from its phase section into a working branch and link the PR here.
- When a feature ships, remove it from this doc — the git history is the record of what was built.
- Update "Last updated" date at the top whenever you make a substantive change.
- The business plan (
business-plan.md) is the financial and strategic source of truth. This document is the product execution view of the same timeline.