FairwayPlan does not have user accounts. It does not have reviews. It does not process payments, send emails, or let you book a tee time. There is no social feed, no leaderboard, no gamification of any kind.
Every single one of these has been suggested to me. Some of them I have suggested to myself, usually at one in the morning when the gap between "I could build this" and "I should build this" collapses to nothing.
None of them made the cut. Here is why.
Every feature is a future obligation
When you build with AI agents, features arrive fast. Describe what you want, review the output, ship it. The build cost of a new feature has dropped to almost nothing. An afternoon. A long lunch break, for the smaller ones.
The maintenance cost has not changed at all.
On a solo project, every feature is your problem personally, at two in the morning, when the deploy broke something.
Every feature you add is a thing that can break. It is a thing that interacts with other things, creating surfaces for bugs that did not exist before. It is a thing that users will expect to keep working, forever, even as the code around it changes. It is a thing that the next developer, or the next agent, has to understand before they can safely modify anything nearby.
On a team, this cost is distributed. Someone else handles the auth system. Someone else maintains the email pipeline. On a solo project, every feature is your problem personally, at two in the morning, when the deploy broke something and the error message is unhelpful.
User accounts would mean password resets, session management, data privacy obligations, and a whole authentication surface to secure. Reviews would mean moderation, spam filtering, and the slow accumulation of content that needs to be maintained even when the underlying course data changes. Payment processing would mean PCI compliance, refund logic, and a relationship with a payment provider that requires ongoing attention.
Each of these is a reasonable feature. Each of them would make FairwayPlan a larger, more capable product. Each of them would also make it a product I can no longer maintain alone. And maintaining it alone is, for now, the point.
The features that earned their place
The things FairwayPlan does have all passed the same test: does this make the core experience better, and can I keep it working?
Inline itinerary editing made the cut. After the solver generates your trip, you can swap a course, change a tee time, or convert a day to a rest day. This is essential because no solver output is perfect. The last five percent is always a human judgement call. The editing system is three CRUD endpoints that recalculate weather, clothing, and totals on each mutation. Bounded scope. Testable. Maintainable.
The share page made the cut. Every itinerary gets a public URL with a map, day cards, and Open Graph metadata. This is the growth mechanism. Someone shares their trip in a group chat, the preview looks good, and someone else clicks through. Viral loop, no marketing spend. One server component, one map component, one OG image route.
The course catalogue made the cut. Browse all 370 courses with filters for region, price, terrain, rating. This is the discovery layer. People land on it from search, find courses they did not know existed, and start a trip from there.
The blog made the cut. Nearly twenty posts and growing. Content that brings in organic search traffic and gives the site a voice beyond the tool itself. A blog is just static files. It does not break at two in the morning.
Reading the diff
The flip side of building fast is reviewing fast. When you work with an agent all day, you read a lot of diffs. After a few hundred sessions, patterns emerge. There are things I now check automatically, the way a proofreader's eye catches a misplaced comma before they have consciously read the sentence.
The first thing I check is what was deleted. New code is exciting. Deleted code is where the bugs hide. If the agent removed a null check, a fallback path, or an error handler, I want to know why. Sometimes the removal is correct: the check was redundant, the fallback was dead code. Sometimes the agent restructured a function and quietly dropped a guard clause that was load-bearing. Deletions get more scrutiny than additions.
The second thing I check is the boundaries. Where does this code touch other code? If the change is inside a single function and the inputs and outputs are unchanged, the blast radius is small. If the change modifies a shared type, a database query, or an API response shape, every consumer of that interface is potentially affected. I trace the edges before I approve.
The third thing I check is what the agent assumed. Agents fill gaps. When your prompt is ambiguous or incomplete, the agent makes a choice. These choices are usually reasonable. They are also usually silent. The agent does not say "I assumed you wanted UTC timestamps here" or "I assumed this endpoint should return a 404 rather than an empty array." You have to spot the assumptions in the code itself.
I look for hardcoded values. Default parameters that were not in the spec. Error messages that imply a particular user flow. Variable names that suggest the agent interpreted the requirement differently from how I intended. These are small things. They are also the things that create the weird, hard-to-reproduce bugs three weeks later when something downstream relies on the assumption the agent baked in.
The discipline is the same
Deciding what to cut and knowing what to look for in a diff feel like different skills. One is product judgement. The other is code review. But they run on the same underlying discipline: restraint.
When the agent produces a clean diff that adds a feature you did not ask for, you cut it. When your own brain produces an idea for a feature that sounds good at one in the morning, you cut it. When the code looks right at a glance but you have not checked the boundaries, you slow down and check.
The agent makes building easy. It does not make deciding easy. The deciding is still yours, and it is the part that determines whether the thing you are building stays manageable or slowly becomes something you dread opening.
FairwayPlan is small on purpose. Everything it has earned its place by being worth the ongoing cost.
FairwayPlan is small on purpose. It does a few things well. Everything it does has earned its place by being worth the ongoing cost. And every diff that lands on main has been read by someone who has learned, through repetition, where to look.