There's a post going around from an indie dev who spent more than ten years logging his days in a Google spreadsheet. Started after he quit his job, worried that time would just slip past unaccounted for. One row per day: what he worked on, how many hours, which gnarly bug he finally cracked so he wouldn't fall into the same hole six months later. Over time the sheet picked up life stuff too, the day his kid learned to walk, a paper flower she made him. Then the thing got too big to search, and he stopped doing any analysis because wrangling charts was a pain.
His fix was Upglow: write one plain sentence, let the model do the sorting and the stats. "Spent 3.5 hours on Upglow today, mostly fixing the timeline UI" goes in, and the AI classifies it, pulls out the number, and tallies it over time. He's honest that right now it has exactly one user, himself. That's fine. The interesting part isn't the product. It's the shape of the problem.
The chat box is the disposable half
Everyone looks at a tool like this and copies the input: a text box that eats a sentence. That's the easy, replaceable part. The piece that actually earns its keep is the extraction layer, the thing that turns "squat 80kg, 5 sets of 5" into {activity: strength, weight_kg: 80, sets: 5, reps: 5} and "spent 3.5h fixing the timeline UI" into {category: dev, duration_h: 3.5, note: timeline UI}. Once free-form text becomes classified, number-tagged rows, you can query it, chart it, correct it. Without that step you've just got a notes app with extra latency.
The reason the spreadsheet broke down is the same reason a rigid database would have broken down: life doesn't fit one schema. One line is a payment-system task, the next is a workout, the next is your daughter handing you a paper flower. The dev didn't want to design columns or fill forms. The model's job is to absorb that irregularity and still hand you something structured. So that's what I'd build and keep: the extraction layer, with everything around it kept replaceable and inspectable.
Three pieces, mapped to what the platform actually does
Here's how the rebuild breaks down on VicroCode, staying strictly inside what the platform supports.
The capture surface is a single HTML page: one text field, a submit button, and a scrollable list of recent entries. No framework needed, no second brain, no dashboard sprawl. You can run HTML online and host it so it's reachable from your phone when you want to jot something between tasks. Keep it dumb on purpose. The page posts a sentence and renders what comes back.
The brain is a Python endpoint. It takes the raw sentence, calls a model through the platform's Model Center for classification, and parses out the structured fields: category, duration, weights, amounts, whatever numbers it can find. You can run Python online and expose it as a hosted API endpoint so the HTML page has something to call. This is where you'd write the prompt that asks the model to return strict JSON, plus a layer of plain Python that validates the shape and does the boring-but-reliable work: regex for obvious durations like "3.5h" or "5 sets of 5", so you're not leaning on the model for things a pattern match nails every time.
The ledger is SQLite. One table, flexible enough to hold a note plus a bag of extracted fields. Every entry keeps its original sentence next to the parsed values, which matters for the next part. When you need to fix a mis-tag by hand, you open the SQLite editor and change the row directly. No migration, no admin panel to build first.
Where free-form extraction stays unreliable, and why you keep the raw text
I want to be straight about this, because the honest version of this build is more useful than the demo version. Language models are lossy. There's a separate thread in the wild right now from someone learning AI-driven stock analysis who asked a model the same kind of factual question ten times and got it wrong every time; the replies underneath basically say the quiet part out loud, that a model is highly compressed knowledge and precise lookups need to be fetched, not recalled. Same caution applies here. Extraction from messy sentences is going to drift.
Concretely, what breaks: units get guessed wrong (was "80" kilos or pounds?
, categories flip-flop when a sentence spans two topics ("fixed the payment bug after my run"), durations get hallucinated when none were stated, and ambiguous shorthand gets over-interpreted. None of this is fatal if you design for it. That's why the raw sentence lives in the row forever and why hand-correction is a first-class action, not an afterthought. The model proposes, you dispose. Treat the extracted fields as a draft that a human can overrule in two clicks.
A few things that reduce the pain without pretending the problem is solved: have the endpoint return a confidence or a flag when it had to guess a unit or invent a category, and surface that in the HTML list so you know which rows to glance at. Do the deterministic parsing in Python first and only fall back to the model for the genuinely fuzzy stuff. Keep categories to a short fixed list in the prompt so the model classifies into known buckets instead of inventing new ones every day. And accept that some lines, the paper-flower kind, shouldn't be forced into numeric fields at all; let them be notes.
What you'd honestly have at the end
A page you can hit from anywhere, an endpoint that turns sentences into rows, and a database you can read, query, and correct by hand. That's a real, reproducible build on the confirmed pieces: hosted HTML, a hosted Python endpoint using models already on the platform, and an editable SQLite store.
What I'd flag before you get excited: anything past that is outside the lines I'd draw here. Automatic charts and trend views are something you'd have to render yourself inside the HTML page from the SQLite data, not a feature to assume. There's no claim that model extraction hits any particular accuracy; that's unverified and will depend entirely on your prompt, your categories, and how messy your own writing is. And the Upglow story itself reports one user and no outcomes beyond "it solved my problem," so treat its traction as unverified too.
The takeaway that survives all of that: when the input is irregular human language and the output needs to be queryable, build the extraction layer as the asset, keep the original text, and make correction cheap. The chat box is the part you can throw away. The classified, number-tagged ledger is the part you'll still be querying in five years.