ForkIt! Case Study: Fine, I'll Build It Myself (with LLMs)

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 don't make decisions.
I observe pain points, ask targeted questions, make suggestions, and provide a space for data to sit before it can be pushed somewhere it gets turned into information
For a while, I sat in sprint reviews and got to watch how dev teams work: how they scope, how they communicate, how they respond to changing requirements. Those stopped a couple of years ago, and I miss them. But that exposure is where the instinct came from.
Now I work with groups as they build tools for end users: dashboards, toolkits, guiding documentation. I started asking "Can I get Google Calendar to tell Slack a meeting is coming up?" That led to Google Apps Scripts, then automating my own workflow, then building an internal project website from scratch
I'd used drag-and-drop builders for my business and seen the back of a WordPress site. That's not dev experience; that's tinkering. But tinkering is how ForkIt! started too.

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.

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.

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, Clerk, RevenueCat, 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.

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: 13 services, most on free tiers. 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.

Fine, I'll Build It Myself

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.

Every one of you has expertise that transfers to something you haven't tried yet. The tool just has to meet you where you are.

You don't need to become an expert. You need to build systems that catch what you can't, and bring what you already know.

ForkIt I'll Build It Myself (with LLMs)