ForkIt! Case Study

About Me

Not a developer. Not pretending to be one. But not starting from zero, either.

What I've Done Before

GM of Operations & Contracts, 75-year-old company, fragmented records, 24-week backlog
Rebuilt budgeting from scratch. Backlog: 24 weeks → 6. Revenue: +24%. Customer satisfaction: 25% → 85%.
Founded a non-profit education center, sole proprietorship to multi-program non-profit with staff and volunteers
No-shows: −70%. Bookings: +35%. Profit: $10K → $70K/year. Nominated Employer of the Year (Alabama Career Center). Awarded Educator of the Year 2018 (Cullman County Soil & Water District).
Degree in accounting, post-grad in Federal Contracts, one C++ class from when I was a pure math major

What I Do Now

Project Coordinator, NSITE MO. I move information where it needs to go so decision-makers can use it to do their jobs.
I observe pain points, ask targeted questions, and provide a space for data to sit before it gets turned into information.
Sat in sprint reviews and watched how dev teams scope, communicate, and respond to changing requirements. That exposure is where the instinct came from.
Work automation led to Google Apps Scripts. The first time I ran one, Google asked: "Are you sure you trust this developer?" I was the developer. That pulled me into OAuth, API scopes, the Google developer ecosystem, and eventually the Play Store, which is how I learned publishing an app was even possible.

What Transferred

The big boss roles gave me scope discipline, budget instincts, and the ability to make decisions under pressure. The coordinator role gave me something different: a front-row seat to how dev teams work, and more recently, hands-on collaboration with teams building tools for real users.

What I learned from those experiences wasn't how to write code. It was how people who solve problems think. How they organize workloads, communicate with their team, and engage their stakeholders. That turned out to matter more than the code.

But the technical knowledge had a pipeline too. Work automation led to understanding what an API is. That OAuth warning led to understanding how developer ecosystems work. Watching dev teams led to understanding what a sprint is, what scoping means, why things break. None of that was personal project work. It was all job experience that quietly built a foundation I didn't know I was going to use.

When I finally sat down to build something for myself, I wasn't starting from zero. I was starting from years of adjacent exposure that I'd never tried to apply directly. The gap wasn't knowledge. It was confidence.

The skills transferred from the office. The work didn't. ForkIt! was built on my own time, on my own equipment. 80% of commits land on evenings and weekends, with the rest on dedicated break times or automated work from background processes.

"You Need To Remember Who Pays The Bills"

Early in a previous role, someone coached me on managing a meeting that was running long. When the exact scenario came up, I did exactly what I'd been told. The room went cold. Afterward, I was informed that I needed to "remember who pays the bills around here."

The lesson: the stated process isn't always the real process. Following instructions perfectly can still be wrong if you misread which instructions matter.

That Transfers Directly To Product Work

Someone says: "We need hard limits on meeting time."
What they mean: we aren't getting what we need out of this meeting, and trying to is just running us out of time.

Someone says: "Build me a dashboard."
What they need: a way to connect people with data. If the dashboard becomes "The Solution" instead of a tool, you've lost the thread.

With that in mind: this app doesn't solve the problem of "where should we eat?". It's a Solution to the decision fatigue that gets in the way of just living your life.

The Evolution

The Problem

"Where should we eat?"

Nobody could ever decide. Existing apps wanted me to scroll through ads and sponsored listings. I just wanted someone to pick for me.

The Core Product

One button. Set your filters: how far, how expensive, what cuisine, what rating, open now, skip the chains. Tap the button. Get a restaurant.

The filters aren't a feature; they're the point.

The Result

Name, address, rating, whether it's open. Directions, Website, Call. Save it or block it so it never comes up again.

Copycat recipes if you don't want to leave after all.

Your Spots

Google doesn't know about every good place. Custom spots let you add "that weird gas station grocery garage" or the taco truck that's only there on Thursdays.

"Can My Friends Use It Too?"

Fork Around: real-time group sessions. Host creates a session, gets a 4-letter code. Everyone submits filters. Friends join from a browser, no app required. The most restrictive filters win, and the app picks one restaurant at random.

The decision is made. Nobody's fault. Move on with your life.

Then It Got Complicated

User accounts. Cloud sync. Subscriptions. Favorites. History. The app went from one file to 13 services talking to each other.

That's when things started breaking in ways I couldn't just "paste the error" to fix.

Then It Got Simple Again

V4 asked: what do fewer than 100 users actually need? Not accounts. Not cloud sync. Not a purchase middleware. Three services removed. API costs dropped from $49/month to $0. Same app, fewer dependencies, no monthly bill.

The hardest part wasn't adding features. It was admitting which ones didn't matter yet.

Then It Earned Its Keep.

April 2026 billing came in at $0.00. Q1 had 7,374 billable Nearby Search Enterprise calls. April: 132 Enterprise plus 623 Pro, all inside Google's free monthly cap.

The V4 thesis was a prediction in March. It became a receipt in April.

Swipe or use arrows

Where Features Actually Come From

The Hostel in New York

Strangers testing my app to pick dinner. Everyone loved it until one guy said: "I want ANYTHING BUT Indian food. That's what we eat all day." I'd only built for inclusion. He needed exclusion. The real feature lives at the intersection of both.

Impact Story: Walk Mode

A user in a walkable city: "0.5mi? Maybe even 0.25. For us city folk." I'd built the app in a car-centric area. My defaults had excluded him. The fix wasn't just a walk toggle; the app now notices when you should walk and suggests switching. He told me the app lessened his sense of isolation. That was an impact I didn't design for, but it was the one that mattered.

The Monetization Test

Restaurant owners wanted to buy ad space. A hostel stranger asked if I was planning to sell. A friend described the inevitable path: sell ads, hide restaurants that don't pay. Me: "Yelp 2.0." That crystallized the guiding principle: no ads, no tracking, no sponsored listings. Ever.

Dive deeper into the SE methodology →

Different Input, Different Value

Mom groups gave cultural context. Hostel strangers gave failure points by walking away. Reddit gave structured feedback and actual testers. Three sources, three completely different types of value. The skill is knowing what each one tells you, not ranking them. I weighted the wrong source and made design decisions based on enthusiasm instead of stress-tested behavior. Full breakdown →

Philosophy As a Scope Filter

Two questions for every feature: Does it reduce friction? and Does it reduce decision fatigue? Both have to be yes, and it can't introduce new stress. That filter killed a shopping cart feature (solves one friction, creates five) and deferred food truck mode (good idea, no data source). "Not yet" is different from "no."

Recognizing the Rabbit Hole

The "fix the platform to fix the fix" loop. Android sign-in was failing for users with non-Chrome default browsers. Three sessions deep, the original bug was still there. The PM instinct: stop. Ship the workaround, not the platform fix.

What Working With LLMs Actually Looks Like

Early

"Build me a button that picks a random restaurant"

Copy, paste, run. It either worked or it didn't. If it didn't, paste the error back in. Repeat.

Later

"Here's my architecture doc. Here's the constraint. Here's what I tried. Here's the error."

The evolution wasn't about better prompts; it was about learning enough to ask better questions.

Now

"Research current web trends. Update these 5 files. Report back."

I'm not talking to one LLM anymore. I'm dispatching specialized agents in parallel, reviewing their findings, correcting course, and directing next steps. It's not a conversation. It's a team I'm managing.

What LLMs Are Great At

Speed: a working prototype in hours, not weeks
Breadth: knows React Native, Vercel, react-native-iap, Sentry, Redis, Google APIs
Patience: will explain the same concept 15 different ways
Translation: turns "I want the thing to slide up from the bottom" into actual code

What Bit Me

Confident wrong answers (told me Google had a $200/month API credit; it didn't), circular self-citation (the LLM cited its own previous wrong answer as proof), and no pushback on bad ideas. The full list of LLM failures →

Running a Team of Two

I was running a full product development workflow, just with an LLM instead of a team. Stakeholder engagement (SE), communications, product management, development, UI/UX: most of the roles a product team fills, we covered between the two of us. Not by being experts, but by knowing the workflow existed and managing the handoffs.

The roles we didn't fill are where things broke. No dedicated QA (edge cases on devices we didn't own). No legal or compliance (Apple rejected the app). No DevOps (Sentry was added after crashes, not before). No marketing or growth strategy. No accessibility audit. No data analytics. We touched all of these eventually, but touching a role and filling it are different things.

The 31-review suite now covers most of these gaps on paper. There are reviews for accessibility, store compliance, operational readiness, testing coverage, data privacy, and investor readiness. But a review that checks for accessibility is not the same as a user who depends on a screen reader. A compliance checklist is not a lawyer. The reviews catch what I think to look for. They don't catch what I've never seen.

Hover over (or click) a step to see it in action: how a check-in feature request became Group Fork.

SEGather feedback: Reddit, Slack, beta testers. Surface the need behind the request.A Reddit user suggests: "Add a check-in feature. Notify your friends list when you're at a restaurant."

CommsCraft the right questions. Organize responses. Separate signal from noise.Craft follow-up questions. Not "notify friends where I am," but "I want to make it easier to have lunch with friends right now."

ProductCategorize feedback: functional or cosmetic? Aligns with vision?Check-in means a friends list, location tracking, persistent data. The request doesn't align with the vision. The need does.

DevInvestigate. What does this cost? What does it break?Temporary session, everyone submits preferences, app picks for the group. No friends list. No tracking. Expires in an hour.

UI/UXDoes it align with the brand? Does it feel like the same app?4-letter code. Share however you want. Web joiner so friends don't need the app. Fast, simple, no friction.

ProductShip it, defer it, or kill it.Ship it as Fork Around. The requested feature was killed. The underlying need was fulfilled.

SEBack to stakeholders. Did this solve it?Back to the Reddit thread. Back to beta testers. Did this actually solve it?

CommsShape how the outcome gets explained."Fork Around. Find Out." Share a code, pick together, no account needed. One-line pitch.

ProductClose the loop.Same problem solved. Risk eliminated. Loop closed.

Things That Broke

Apple rejected the app for missing subscription compliance. A live demo failed at a restaurant because of an untested backend deploy. A "cleanup" refactor renamed working API endpoints and broke every deployed app. The LLM cited its own previous wrong answer as proof when I asked about build credits. And in April, a Dependabot PR that bundled a React Native minor bump with 28 safe-looking patches broke the entire OTA pipeline because the SDK constraint wasn't visible to the bot.

None of these were code problems. They were process gaps: no security review, no demo checklist, no vendor verification, no naming policy.

The fix wasn't learning to code better. It was building systems that catch what neither of us would think to check.

Dive deeper into what broke and why →

The Discipline Wasn't Natural

January 2026

Add debug info to response

Migrate to Places API

7 commits in one day. 0 issues. 0 docs.

March 2026

Tier 2 visual polish: 8 issues (#88, #36, #85, #92, #93, #15, #14, #31)

Tiered triage. Issue refs. 88 issues tracked.

30 commits and 68 days between the first commit and the first GitHub issue.

The response: a 31-point code review suite (5 automated, 26 manual), a tiered triage system, and a dev cycle that doesn't ship until the loop closes. Build → Review → Loop Back. Functional before cosmetic. Always.

Cost discipline: peaked at 13 services, simplified to 7 in V4. API costs: $0 in April actuals, the first full month post-V4. Guiding principle: keep it as free as possible.

See the review suite and dev cycle → · See the cost breakdown →

What I Wished I'd Had

The code was never the hard part. These are the toolkits that don't exist for solo builders, the things I had to figure out by getting burned.

Stakeholder Engagement Templates

How to evaluate what cultural or ambient biases are shaping user feedback. When to approach someone for live testing vs. when to back off. I made someone mad by picking the wrong moment. How many questions are too many before you're a nuisance. Who to ask for what and when.

Most importantly: how to ask questions that surface the experience the app provides, not aesthetic opinions. "The button doesn't even work, yo. THAT'S what we're testing today", not "I liked the orange highlights a little thicker."

Branding Guidelines

I built a color theory (orange = problem, teal = solution), a typography system (Montserrat), and a design governance doc through trial and error across months. Every new feature gets measured against these before a line of code is written. Without them, scope creep would have won.

No one hands you a design system when you're a solo dev. You build it, or every screen feels like a different app.

An Easy Way To Learn From Others

How are subscription flows typically structured? What's the standard pattern for group sessions? How do apps handle forced upgrades? What's the right testing assertion strategy? How should API versioning work in serverless?

These are questions that would take 5 minutes from a mentor. I asked an LLM instead, not because it was better, but because it didn't make me feel like a nuisance.

Product Development Lifecycle Techniques

I organically built a tiered triage system, a dev cycle (Build → Stabilize → Ship), deploy sequencing, a 31-review code quality suite, and testing gates. All learned through mistakes, not from a playbook.

The hardest skill: telling a tool that can build anything you ask for "not yet."

Feedback Evaluation Frameworks

A way to distinguish what kind of value each source provides. Mom groups gave cultural context about how families think about food apps. Hostel strangers gave behavioral data by walking away. Reddit gave structured feedback, bug reports, and actual testers.

Three sources, three completely different types of value. The skill is knowing what each one tells you, not ranking them.

What I Haven't Solved Yet

Shipping the app didn't close the loop, but V4 closed the cost one. After evaluating every alternative provider (Foursquare, OSM, HERE, Apple MapKit), Google remained the only one with the ratings and price data users' filters depend on. The cost lever wasn't switching providers. It was aligning API billing tiers with subscription tiers: a deep-dive into Google's field-to-SKU mapping revealed that four fields (rating, priceLevel, currentOpeningHours, userRatingCount) locked every search into Enterprise billing. Removing them for free users dropped to Pro billing, where current volume fits entirely within the free cap. That field mask change shipped in V4 Phase 1: $49/month to $0/month. Filters that require those expensive fields are now gated to Pro ($1.99/month). The pricing model, the feature gates, and the API architecture were the same decision, and they're live. The full cost analysis and pricing deep-dive →

Solo Sustainability

One person. If I step away for a month, the app runs, but nothing improves and nothing gets caught.

What does long-term maintenance look like for a solo-built, LLM-assisted product? I don't have a model for that yet. Nobody does.

Why Isn't Anyone Reviewing?

Three weeks of v4 in production. Active devices and paid transactions both exist. Total reviews across both stores: one on the App Store (a 3-star addressing chains, since fixed in v4.3) and zero on Google Play.

The implementation is straightforward: a system review prompt fires after five forks, gated once-per-install. The platforms swallow that prompt silently if the user has hit their quota or disabled prompts in Settings, and there is no return value to distinguish 'shown' from 'swallowed.' V4 closed the cost question. This is the open one. Filed as issue #25; the platform-side mechanics live on the new Platform Engineering page.

Where I Am Now

This was not a coding project. It was a project management project that happened to produce code.

The LLM wrote the code. I managed the product: who it serves, what to build, what to cut, how to evaluate feedback, when to ship, and when to stop.

The failures were never about bad code. They were about missing process: no security review, no demo prep, no vendor verification, no stakeholder register. The skills that fixed them were not technical. They were organizational.

I have a lot left to learn. I can read a stack trace now, but I couldn't write one from scratch. I understand why architectural decisions matter, but I'm still learning which ones to make. I can manage a product through 150 issues across 13 services (peaked), simplify it down to 7, and ship a version that costs $0/month to run. I don't know where the ceiling is on what I can build this way. I'm not sure anyone does yet.

I'm not a complete novice anymore. I'm probably an amateur: someone who knows enough to build something real, and knows enough to know how much she doesn't know. The limits are out there somewhere. I haven't found them yet, and I'm not going to pretend they don't exist.

April 2026: I published the client source on GitHub under PolyForm Noncommercial at forkit-open. Anyone can read it, fork it, submit a PR. The backend stays closed; that's where the API key, billing, and curation work live. Open enough for learning; closed enough to protect future options. The case study became the source code too.

4 versions. 3 OTAs since launch. 7 services. $0 in April actuals. 1 person who didn't know what a commit was in January.

ForkIt I'll Build It Myself (with LLMs)