Wrize

Recording a day doesn't give it value. Evaluating it does. Wrize lets you decide what a good day means — and rewrite it as you grow, without losing sight of where you began.

Comment

Inspiration

For a long time I kept my journal in a spreadsheet, and graded each day in the same sheet. One column, one verdict: did I do something worthwhile today? A run made it a good day. Studying instead also made it a good day. Either one was enough.

In terms of keeping the habit, it worked. But once a year of green cells had piled up, I realized I couldn't answer a simple question: had I grown? A good day in January and a good day in December looked exactly the same on the sheet. The record told me I had kept going. It told me nothing about how far I had come.

The problem wasn't the habit. It was the shape of the evaluation. Running and studying both got poured into the same single verdict. They are different pursuits, but on the sheet there was no way to tell them apart.

The same was true of 3km. Three kilometers as a beginner and three kilometers a year later are the same distance carrying different meanings. For a beginner it was a real achievement. By the time I had some experience, it had become the bare minimum.

Did I do it, or didn't I. That binary was enough for a while. But as you grow, you want more levels between the extremes. Early on there's nothing to place in between; as you keep going, the parts you want to evaluate get finer. Two options stop being enough. I needed a separate scale for each area of my life, and I needed those scales to move as I did.

I called this idea a score card. Every item gets its own axis, and the standard itself can be raised as you grow — while your past entries stay comparable. That structure can't be built in a spreadsheet. If I wanted it, I had to build an app. Wrize exists to make this concept work.

Some time after I started building, I saw the Picasso exhibition in Tokyo. Picasso made a bull out of a bicycle saddle and handlebars. You break something familiar down into its parts and reassemble them into something else. And once you've seen it that way, you can't go back to seeing it the way you did before.

What struck me was that the thing I was trying to build had just been given a name. Take the single mass of a day and break it into running, studying, resting — then give each piece its own measure and put it back together. What I was trying to do with score cards was reinterpretation through evaluation. And once you have that lens, you can't go back to the days you lived without it.

Recording a day doesn't give it value. Evaluating it does. That idea is what Wrize is built on.

What it does

Wrize is a journal with evaluation built into it.

When you write an entry, you also rate the day using score cards you define yourself. Every score card is built on levels — up to ten of them, so you can make your measurement finer as you grow.

For anything measurable, like distance or time, you can assign a numeric range to each level. Enter how far you ran, and the level is decided for you.

When you improve, you rewrite that assignment — move your top score from 3km to 10km. Past entries stay exactly where they were: the day you ran 3km is still recorded as a top score, while a 3km run today comes in at the bottom. Levels are stored as ratios, so the graph never breaks.

That gives you two readings at once. Whether you met your standard today, and how far that standard itself has moved.

An evaluation isn't only something to look at. Each day's rating turns into points, and you define the conversion yourself as a reward table. One kind sets a minimum and a maximum and runs linearly in between; the other assigns a fixed amount to each level.

What's on screen isn't a daily tally. It's what you're on track to receive for the month. Today's rating moves that number up or down — a weak day pulls it back, a strong one the next day recovers it. A day isn't a standalone point; it shows up as part of the month it belongs to.

What you spend those points on lives as a ticket you prepare ahead of time. You decide what it is — lunch anywhere you want, a book, coffee at the café — and how many points it takes. Once you have enough, you drag along the perforation to tear it: the points come off and the ticket flips to used.

The points aren't currency. You can't hand them to anyone or cash them out; they only move inside your own account. They matter anyway, because what makes a small treat hard to enjoy isn't affording it — it's believing you're allowed to. The evaluation is what answers that.

Tear one and your balance drops, and the next ticket is out of reach again. The only way back is to keep rating your days. The evaluation drives the action, and the action becomes the next evaluation — which is where a journal stops being something you just write.

How I built it

Wrize is a Flutter app on iOS, with Firebase behind it and RevenueCat for subscriptions. But the one decision everything else rests on is how a rating gets stored.

If a score card holds "4 out of 5" as an absolute value, changing that card to ten levels makes every past entry meaningless. So ratings are normalized at write time: (rating - 1) / (levels - 1). What gets stored is a position between 0 and 1.

On display, that ratio is mapped back onto whatever the card's scale is now. A 4-out-of-5 is a ratio of 0.75 — move the card to ten levels and it reads 7.8; drop it to three and it reads 2.5.

Where this really pays off is aggregation. A five-level card and a ten-level card can't be added together as they are. Held as ratios, they can — running, studying, resting, each measured on its own scale, and the day arrives at a single overall score.

Challenges I ran into

Keeping the estimate honest

Showing a monthly figure instead of a daily tally was a deliberate choice, but it puts weight on that number. It's an estimate — the month isn't over — and if what finally gets confirmed doesn't match what people watched all month, the feature stops being trustworthy.

Implement the estimate and the confirmation separately and they will diverge. Points are integers, so dividing across days leaves remainders. I pulled the cumulative-difference calculation into one shared function that both paths call: add each day's theoretical value to a running total, pay out only the whole part, carry the rest forward. The remainder rolls into the next day and settles at the end.

The two table types also confirm under different conditions. The linear table computes per day, so it can be confirmed provisionally mid-month. The fixed-amount table maps a monthly average onto a level, so during the current month it can't resolve until every day is in. The same action branches underneath.

And the table type can be switched mid-month, which must never leave you with less than you've already received. The estimate is clamped to the confirmed total as a floor — change your settings and nothing already paid disappears.

People write after midnight

I found this one using my own app. Writing yesterday's entry after the date had rolled over made the estimate drop.

The denominator was the problem: today, still unwritten, was counted in the day total and diluting the average. The fix checks whether today has an entry, and if not, subtracts one from the denominator and adds one to the remaining days. Those two have to move together or the total stops adding up.

Not a bug you hit unless you're building a journal.

Bidirectional pagination on the timeline

You can jump to any month from the header, and from wherever you land you need to reach both older and newer entries. Infinite scroll that only runs downward doesn't cover it.

Two cursors, with fetches split by direction. Firestore cursors only advance in query order, so reaching newer entries meant flipping to ascending, fetching, and reversing the result.

Prepending to a list moves everything you were looking at. My first attempt corrected the offset with index arithmetic, which never worked — the correction ran before the list finished rebuilding. What landed was identifying the anchor by date instead.

Accomplishments that I'm proud of

Finishing it. This was my first app, and I got it to release without walking away from it partway.

The other one is that what I built came out of my own life. I wasn't imagining someone else's problem and filling the gap — it started from what I found missing in my own spreadsheet. What's worth measuring, how much of a day counts as valuable: thinking about those while building made it clearer to me what I actually judge my own days by.

What I shipped was an app. What I kept might be the way I look at my own days.

What I learned

Flutter and Clean Architecture, both of them through Wrize — I hadn't used either before starting.

I separated the layers from the beginning because I wasn't building something to finish. Release is the start of it: features get added, things get fixed, people keep using it. None of that holds if I can't read my own code by then. I knew it would cost me speed early on, and took that trade.

What's next for Wrize

Search. The more entries pile up, the more you need a way back to a specific one.

Android. It's a Flutter codebase, so most of it already runs — the blocker is that I don't own an Android device yet and haven't verified anything on real hardware.

And letting you choose which month to compare against. Right now it's always the previous one. Being able to line today up against six months or a year ago would make the whole arc visible — the standards you raised, and what they were before. Wrize is built on looking at a long stretch of days, and this is the part where the feature hasn't caught up with that yet.

Built With

Share this project:

Updates

Submission history