Propina 八分鐘上線：關鍵在 Cursor，還是提示詞規格？

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.

earlgreyhot1701D / propina

Dual-currency tip calculator for USD and MXN with a manual exchange rate, split-the-bill math, and live updates. Single HTML file, no frameworks, no build step, no API. Styled with Clew Labs brand tokens. Built with Cursor for the Build a Mini App challenge. AI Assisted. Human Approved.

Propina

Propina is a single-page tip calculator: enter a bill, choose a tip percent, and split the total among people, with a USD/MXN toggle that shows every result in both currencies. The MXN-per-USD exchange rate is a manual field (default 18.00). It is not fetched from a live API, so you set the rate yourself. Open index.html in a browser, or visit the GitHub Pages site for this repository.

Live: https://earlgreyhot1701d.github.io/propina/

Built with Cursor for the Build a Mini App challenge (Hacktoberfest / MLH Global Hack Week 2026). One prompt, one shot, eight minutes from first prompt to live site.

Clew Labs. AI Assisted. Human Approved.

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.

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.

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:

Build a tip calculator as a single index.html file with inline CSS and JavaScript. No frameworks, no build step, no external scripts except Google Fonts.

Currency: a toggle for USD and MXN. Default USD. An editable exchange rate field (default 18.00 MXN per 1 USD, label it as a manual rate, no live API). Show every result in both currencies: bill currency first, converted currency underneath in smaller text.

Inputs: bill amount, tip percent (buttons for 10, 15, 20, plus a custom field), number of people to split with.
Outputs: tip amount, total, and per-person total, each in both currencies. Update live on every input change. Show "0.00" when inputs are empty or invalid, never NaN or a blank screen.
Use textContent, not innerHTML. Validate inputs (no negatives, people must be at least 1, rate must be greater than 0). Format money with two decimals and a thousands separator.

Style it with these tokens exactly:
--field #0A1F2E (page background)
--paper #F1E8D2 (card background)
--turquoise #1FB5B7 (buttons, active toggle, focus ring)
--sienna #E85A1F (custom tip active state and per-person highlight)
--ink #17262E (text on cards)
--paper-warm #E8E0CC (text on dark background)
--muted #647178 (captions, converted amounts)
Fonts from Google Fonts: Cinzel 700 for the title (uppercase), Source Serif 4 400 for body, JetBrains Mono 600 for labels, buttons, and numbers (uppercase labels, letter-spacing 0.12em). Add a subtle 48px grid overlay on the page background using rgba(31,181,183,0.035). Single centered card, max width 480px, mobile-friendly.

Title: "Propina". Footer line in mono: "Clew Labs. AI Assisted. Human Approved."

Add a README.md with one paragraph on what it does, that the exchange rate is manual, and how to open it.

Then: run git init, commit everything, create a public GitHub repo named propina with the gh CLI, push to main, and enable GitHub Pages from the main branch root. Give me the repo link and the Pages link when done.

Do not add features beyond this list.

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.

if (!Number.isFinite(amount)) {
  amount = 0;
}

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:

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

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.