Blog

I Built an App With No Coding Experience

I have never written a line of code by hand. Not one. Everything in SimCap, the tournament brackets, the GHIN integration, the four-tier mulligan system, all of it exists because I described it to Cursor in plain English and it wrote the code for me. This is not a post about why I started SimCap. This is about what it actually looks like to build a real app when you cannot code, because I get asked about the mechanics of this more than almost anything else.

The workflow is closer to my old job than you'd think. I spent ten plus years writing specs and telling engineers what to build, never how. Vibe coding turned out to be the same skill pointed at a different tool. I do not open a code editor and start typing. I open a conversation and describe the feature the way I would explain it to a teammate, in full sentences, with the reasoning behind it, not bullet points. "The mulligan should reduce the difficulty modifier, not the gross score, and it needs four levels because a mulligan on an easy course shouldn't count the same as one on a hard one." That sentence became a real feature after a few rounds of back and forth.

The part nobody tells you is that you cannot test locally. I cannot run the app on my own machine and click around to see if something broke. Every single change gets verified on TestFlight. That means every build is a real deploy, version bump in app.json, eas build, wait, install, test on my actual phone. It is slower than it sounds, and it forces a discipline I did not expect: you learn to describe exactly what you want before you burn a build cycle finding out it's wrong.

The mulligan rebuild is the clearest example of where it actually broke. It started as an on/off toggle. Getting it to four tiers, none, one, two, three or more, each with its own multiplier, sounds simple until you realize the multiplier has to touch the difficulty modifier without quietly corrupting the gross score somewhere downstream. I did not know what a regression test was three months ago. Now there's a suite that runs 28 checks before anything about scoring ships, because I got burned once and didn't want it to happen again. GHIN integration was its own fight, mostly because I was translating between two systems that were never designed to talk to each other and I had to keep re-explaining edge cases until the logic actually held.

Here's what I'd tell someone starting from zero. Vibe coding does not remove the need for judgment. It removes the need for syntax. You still have to know exactly what you want, notice when the output is wrong, and be stubborn enough to keep pushing until it's right. If you can write a clear spec and you're willing to burn a few dozen bad builds finding the right words, you can ship something real.

The other thing I'd tell someone starting from zero is get ready to QA a lot. Not a little, a lot. When you cannot read the code, testing is the only way you actually know what shipped. Every build gets clicked through on TestFlight, every flow, every edge case, every screen, because you have no other way to catch a bug before your users do. There is no glancing at a diff and trusting it looks right. You tap every button. You run the tournament flow start to finish. You check the mulligan math on three different courses because you already got burned once assuming it worked. It is tedious and it is also the actual job when you're the one who cannot read what got written. I did not know that a year ago. I know it now because SimCap is sitting on the App Store proving it.

← All posts