The Business
Case
(13 Services → 7, $0/Month)

What Changed

V4 asked: "Does this service serve sustainability or conversion?" At fewer than 100 users, the answer for auth, database, and purchase middleware was: neither. Clerk was removed (no accounts needed). Neon was removed (local storage + export/import). RevenueCat was removed (react-native-iap talks to stores directly). The API cost dropped from $49/month to $0 by switching free users from Enterprise field masks to Pro field masks (same data the user sees, different billing tier).

The Pricing Discovery

The LLM stated that Google Maps Platform included a $200/month free credit. Architecture decisions, cost projections, and the free tier design were all built on this assumption. The credit had been eliminated over a year before the project started. The LLM's training data was stale. Every cost calculation based on that number was wrong.

On top of that, Nearby Search and Text Search hit Enterprise SKU pricing (higher per-call costs than the Basic endpoints used for simple geocoding). The app was hitting the most expensive tier of an API with no credit to offset it.

Lesson: never trust LLM pricing knowledge. Verify vendor pricing pages directly before making cost-driven architecture decisions.

v2: Two Tiers (The Margin Problem)

Free users got 20 searches and cloud sync. Pro ($1.99) got unlimited everything. The problem: every user (including free users) hit Neon, Clerk, and the backend for sync. A power Pro user who searched 50 times a month cost ~$1.60 to serve and paid $1.69 net. That is a $0.09 margin on the most engaged users.

The users who cost the most paid the same as the users who cost the least.

Usage Enforcement at Scale

Free tier limits are tracked per-device via AsyncStorage with monthly resets, not per-account (accounts were removed in V4). A determined user could bypass them by clearing app data or reinstalling. At ~100 users and $1.99/month, the incentive to game it is near zero. But the architecture doesn't scale.

Server-side usage tracking (keyed by device ID or fingerprint) is the obvious fix. The question is when the risk justifies the complexity. Right now, the answer is: not yet. The cost of a handful of users gaming the free tier is less than the cost of building and maintaining server-side enforcement.

Vendor Dependency

7 services. Most on free tiers. Google already killed its $200/month API credit without warning (March 2025). The remaining dependencies: Vercel, Google Places API, Sentry, Redis (Vercel KV). Any of them could change pricing or terms.

How does a solo dev build resilience against platform risk when every alternative means rebuilding? The answer, right now, is: you don't. You monitor, you keep alternatives in mind, and you accept that the free tier is rented ground. The 31-review suite includes Review 25 (Dependency Health) for exactly this reason, but a review can flag the risk. It can't eliminate it.

Update (March 2026): A full evaluation of Foursquare, OSM, HERE, and Apple MapKit confirmed that Google lock-in for restaurant data is real; no alternative provides the ratings and price data that ForkIt's filters require. The mitigation isn't to switch providers but to minimize call volume through aggressive, mode-aware caching. The research is documented in the project's issue tracker for future revisiting as the market evolves.

Will People Pay?

Probably not many. The problem ("where should we eat?") is real but feels trivial. People don't pay to solve problems they think they can push through. Similar apps have struggled; UrbanSpoon got acquired and dissolved. Most "random restaurant" apps have under 1,000 downloads.

The differentiator (no ads, honest randomization) is appreciated, but principles are not features people open their wallets for.

Where the money is, if anywhere: Group Fork. It has a "right now" moment (group dinner, everyone arguing). People pay at the point of pain, not in advance. The tiered model puts that behind Pro+, which is where it should be.

v1-v2: All Free, All Enterprise (January-March 2026)

Every user got the same API calls. Every search hit Google's Enterprise tier because the field mask included rating, priceLevel, and currentOpeningHours. Free and paid users were identical from Google's billing perspective.

The assumption: a $200/month Google Maps credit would cover it. That credit had been eliminated a year before the project started. The LLM's training data was stale. By the time real billing data arrived, the architecture was locked in.

Result: ~$43/month API cost (Feb 2026 actual: $42.77) for ~100 users, 100% of it from Nearby Search Enterprise. Everything else (Place Details, Text Search, Autocomplete) fit within free caps. V4 eliminated this cost entirely.

The 15% Discovery

Apple's Small Business Program reduces the App Store commission from 30% to 15% for developers under $1M in annual revenue. Google Play's 15% on the first $1M is automatic. This nearly doubles the per-user margin.

At 15% cut, a Pro subscriber at $1.99 keeps $1.69 (not $1.39). A Pro+ subscriber at $2.99 keeps $2.54 (not $2.09). The difference between "barely profitable" and "solid margin" was a form submission.

Lesson: check your store commission rate before building a revenue model. The default assumption of 30% may be leaving 15% on the table.

The Honest Ceiling

Even in the most optimistic viral scenario (100K installs, App Store feature), ForkIt nets ~$500-1,000/month by month 12 at $1.99/$2.99 pricing. This is a niche utility app, not a social platform. ~80% of installs churn in week 1. ~3-4% of active users convert to paid. Paid subscribers cancel at ~8-10%/month.

This is not "quit your job" money. The ceiling is a meaningful side income, not a startup outcome. The things that move the needle more than virality: retention past week 1, conversion rate improvements, and reducing subscriber churn.

The architecture ensures the app doesn't lose money at any scale. That's the win. Everything above $0 net is a bonus.

The Restaurant Owners

Two restaurant owners, separately, asked the same question: "Can we pay to show up more often?"

The answer was immediate and easy. No. The app picks randomly. If you can buy placement, the randomization is dishonest, and the entire value proposition collapses. Users trust the pick because nothing influences it except their own filters.

The moment someone can buy a better result, the app becomes an ad platform. That is a different product.

The Yelp 2.0 Prediction

A friend, watching the app grow, predicted: "You're going to end up building Yelp 2.0. Reviews, business pages, sponsored content. That's where the money is."

He was describing the standard playbook. Build the audience, monetize the attention. Every food app eventually becomes an advertising platform for restaurants.

That prediction became the clearest articulation of what not to build. The constraint isn't "we can't afford ads." It is "ads would destroy the thing that makes this useful."