A weekend notes sorter with a $3 AI budget

Friday evening: choose a project small enough to finish

My plan for this weekend is a notes sorter: paste a messy paragraph, then receive a short summary and a list of possible tasks. It is useful for lecture notes, personal project ideas, and reminders that have grown into paragraphs. The first version needs one text box, one submit button, and one editable result.

I would set aside $3 for model requests. That is a personal spending ceiling, not an estimate of what the project must cost. The aim is to finish something useful without turning a quiet weekend into an open-ended experiment.

Keep one model and one request per submission

Use Gemini 2.5 Flash throughout the project. Keeping one model removes a tempting distraction: comparing responses before the app even works. You can evaluate whether this model handles your examples without building a model selector or learning several interfaces.

Create a MyRelay account to keep the project's requests under one key and track their token usage and cost. Its OpenAI-compatible interface lets you use a familiar SDK. Keep the key on your server, never in browser code, and begin with one small request to confirm that the connection works.

Record that request's cost before proceeding. Do not assume that a small budget automatically stops requests; verify which account controls are available and keep your own running total.

Saturday morning: write examples before building the screen

Prepare six short notes with known expected results. Include a clear task, several unrelated thoughts, an explicit deadline, an uncertain intention, an empty submission, and a paragraph with no action items. Use invented details rather than private messages or real classmates' information.

Write down what a reasonable answer should contain for each example. A sentence about possibly joining a club should not become a firm commitment. A note without a deadline should not acquire one. These expectations give you a useful test set without paying for dozens of exploratory requests.

Give the model a narrow job

Draft a single instruction asking for a brief summary and candidate tasks supported by the note. Tell the model not to invent deadlines, names, or commitments. Ask it to preserve uncertainty and return no tasks when none are present.

Treat the submitted note as content, not as instructions for the app. Include an example containing a request to ignore the sorting rules. This does not guarantee protection, but it helps expose a basic failure early. Keep the app limited to suggesting text; it should not send messages, create calendar entries, or perform tasks.

Saturday afternoon: connect the smallest working interface

Build the screen around the interaction you already defined. Disable the submit button while a request is running, show a plain error if it fails, and leave the original note intact. Make the result editable so the user can correct an interpretation without another paid request.

Set a modest input length limit and a short output allowance. Reject empty submissions locally. Avoid automatic retries during development, because repeated failures can spend money without teaching you anything new. A deliberate retry button is easier to understand and monitor.

Sunday morning: test in batches and inspect spending

Run the six examples once, then inspect both the results and MyRelay's per-request token and cost records. Compare actual spending with your remaining budget before starting another batch. Development tests count toward the same ceiling as demonstrations.

Change one instruction at a time and rerun only the examples affected by that change. Fix duplicate submissions and unnecessary requests before polishing the wording. If the budget is nearly exhausted, use saved responses to finish the interface instead of making more calls.

Sunday afternoon: finish with limits you can explain

Stop when the app handles the small test set reasonably, preserves uncertainty, and leaves every decision to the user. Add a short explanation that suggestions can be wrong and should be reviewed. Avoid storing submitted notes in the first version unless storage is essential.

Write down the total model spend, the number of test requests, and one improvement for next weekend. A finished notes sorter and a clear cost record are a better result than an unfinished collection of features.