A tip calculator, a stopwatch, and a lot of pesos. TL;DR: I built a USD/MXN tip calculator with Cursor for the Build a Mini App challenge during Hacktoberfest and MLH Global Hack Week. One prompt, one commit, no corrections, and the site was live on GitHub Pages eight minutes after I first asked for a prompt. The prompt is in this post so you can run the same test. What took longer than the build was writing the prompt. 8:25 in the morning. The challenge brief says "something small but real, a to-do list, a tip calculator." I'm sitting there thinking a tip calculator is the most boring thing on earth, and then I remember I'm in Mexico every few months doing pesos-to-dollars math on a napkin. So, Propina. Spanish for tip. {% github earlgreyhot1701D/propina %} Live: earlgreyhot1701d.github.io/propina What it does A single HTML page. You pick the bill currency, USD or MXN. You type the exchange rate yourself (default 18.00, no live feed, I'll come back to that). Bill amount, tip percent, number of people. Every result shows in both currencies, bill currency first, converted amount under it in smaller type. | Input | What you get | |---|---| | Bill 1,250 MXN at 15% | Tip MXN 187.50 ($10.42) | | Same bill | Total MXN 1,437.50 ($79.86) | | Split by 1 | Per person MXN 1,437.50 ($79.86) |
No frameworks. No build step. No API. The exchange rate is manual on purpose, because a live rate means a key, a fetch, an error state, and a dependency I'd have to check isn't dead in six months. For a tip at a taqueria, the rate from this morning's ATM receipt is close enough. The clock All times Pacific, all from the chat log and the GitHub commit record. | Time | What happened | |---|---| | 8:25 | Asked Claude for a prompt I could paste into Cursor | | 8:26 | Revised it: dual currency, my brand tokens | | 8:28 | Repo created on GitHub | | 8:32 | First and only commit | | 8:33 | Pushed. Pages live. | | 8:39 | I tested the math by hand. It held. | | 8:53 | Code review found one minor bug. Fixed and pushed. | Eight minutes from the first ask to a URL I could send someone. I did not redirect Cursor once. Not a single "the total isn't updating, fix it." The first commit, co-authored by me and cursoragent, is the whole build. The second commit, twenty minutes later, is the review. More on that below.
The prompt did the work Here's the thing I want to be honest about. The whole thing took eight minutes, and most of that was the spec, not the build. I had Claude write the prompt, I revised it twice, and by the time it hit Cursor there was nothing left to decide. This is the prompt, verbatim:
Look at what's in there. Hex codes. Font weights. Which element gets the orange. textContent not innerHTML. Never show NaN. And the last line, which I think did more than any other: do not add features beyond this list. Every one of those lines is a decision I'd otherwise be making in a chat window at 8:35 while Cursor waited. I made them at 8:26 instead. The agent didn't have to guess, so it didn't guess wrong. I think that's the real finding. The speed wasn't Cursor being magic. The speed was that there was nothing left to argue about. The NaN trap One line in the prompt said "never NaN or a blank screen." Here's why that line has to be there. In JavaScript, typeof NaN === "number". So a check like "is this a number" passes on garbage. An empty bill field, a rate of zero, a negative tip, all of them sail through and the page prints $NaN in your brand font. Cursor handled it the way I'd want: validate first with Number.isFinite, reject negatives, require at least one person and a rate above zero, and if anything fails, write formatted zeros with textContent instead of leaving the box empty.
That snippet is from the shipped file, not a tutorial. The money formatting is Intl.NumberFormat, two decimals, thousands separators, so 1437.5 shows as 1,437.50 without anyone writing a comma-insertion function at 8:30 in the morning. The credits ran out before the QA did I burned through my Cursor credits right after the build. No big deal, it's a free-tier morning, but it meant the final bug review I'd normally ask the build agent for didn't happen there. So Claude did the review instead. It read all 424 lines of index.html and came back with three findings: | Finding | Weight | |---|---| | Typing 1.5 in Number of People passed validation and split the bill by 1.5 | Minor bug, fixed | | The result boxes updated silently for screen readers; no aria-live | Accessibility gap, fixed | | One CSS rule that could never match | Cosmetic, left alone | Two lines changed, pushed as a second commit. Everything else it checked (empty inputs, negatives, zero rate, zero people, both conversion directions, the thousands separator) held. So the build history is: one commit from Cursor, one two-line fix from a reviewer that hadn't watched the build. I like that shape better than the pure one-shot story, because the second commit is where the "human approved" part lives. Two agents, one build log Three parties, as usual. Cursor generated index.html and README.md, ran git, created the repo with the gh CLI, pushed, and switched on Pages. One shot. It also wrote a README paragraph with two em dashes in it, which is the only thing I'd call a miss, and that's a style preference, not a bug. Claude (Fable 5.1) wrote the prompt from my two-sentence ask, revised it when I said "pesos," pulled the commit timestamps for the table above, took the screenshots, spot-checked the math on the live site, did the code review when Cursor's credits ran out, pushed the two-line fix, and made the README banner. It also could not download Google Fonts from its sandbox, so the banner uses stand-in fonts. Same colors, different letterforms. I'm telling you so you don't think the banner is the Cinzel the app uses. (Yes, Fable is overkill here but I threw token caution to the wind!) Me. Picked the idea. Said "pesos." Handed over the brand guide. Tested at 8:39. Approved. I did not write a line of code. I wrote one line of spec ("can we make it in pesos or dollars and pesos since I travel to Mexico a lot?") and the rest was direction. What I didn't need, and would use next time Cursor's desktop app has a browser pane. You open the running page inside the editor, click an element, and move it, and the agent picks up the change. I didn't touch it this build, because there was nothing to fix. The next time a layout comes back slightly off, that's where the fix happens, not in a chat message describing where the button should go. What it can't do No live exchange rate. You type it. No history, no saving, no sharing a split with the table. No rounding options. Two decimals, that's it. One currency pair. If you need euros, fork it and change two strings. The banner in the README is not in the app's real fonts (see above).
Try it earlgreyhot1701d.github.io/propina. Nothing is sent anywhere. There's no backend to send it to. Or copy the prompt above into Cursor and see if you get eight minutes too. I'd like to know if the one-shot holds on someone else's machine, or if I got a good roll. The tip calculator is just the evidence
So, was it Cursor or was it the spec? Both, but not equally. Cursor executed clean, and I’d use it again tomorrow. The spec is what made clean execution possible, because it left the agent nothing to decide. What I think is cool here isn't the eight minutes. Plenty of people have one-shot a tip calculator.
It's the shape of the morning. I spent two minutes on the idea, let one agent write the spec, let another agent build it, hit a credit wall, swapped in a third reviewer that hadn't seen the build, and the whole thing is documented down to the minute with a commit log that backs it up. That's the workflow I've been describing for a year, run end to end in under thirty minutes on a Thursday. One caveat I'm keeping in view. A tip calculator is small enough that a good spec can cover every decision. The next test is whether the same prompt discipline holds on something with a real second layer, like state or a backend. Does it? I don't know yet. That's the next post.
Quick context if you are new here. I work in the California courts, running court operations for the county. I started building with AI in July 2025 and I have been learning in public ever since. I do not write the code. I direct, the agents generate, I validate and decide. I build the Clew Suite, a set of civic tech tools for making complex systems easier to inspect. That is the lens I am writing from. Built with AI assistance on October 15, 2026. Times are from the chat log and the GitHub commit record for that morning. Cursor moves fast, so check cursor.com/docs before you quote me on what the browser pane does. AI Assisted. Human Approved. Powered by NLP.