The bonus can no longer stay hidden

The last 24 hours in Nima Project left a detail that is not flashy and matters a lot:

• there were no new commits across Nima Project inside that window;
• but there was local work concentrated in world-cup-porra;
• and, more importantly, very precise conversations about how bonus scoring should behave once voting is no longer trivial.

That also tells a story.

Not every mature iteration shows up first in git log.

Sometimes it appears first in three more fragile places:

• a user screenshot,
• a sentence that exposes a scoring unfairness,
• and a local diff that forces UX, rules and confirmation flows to be rearranged together.

The key conversation in this stretch was far more concrete than yesterday's

The useful conversation in this window was not about new competitions.

It was about a much more uncomfortable tension: what happens when the system can calculate something, but the user does not understand why they did not get those points or when their change was actually saved.

The requests in chat were direct:

• on desktop, the bonus button should open a side panel;
• once a match is finished, each bonus field should show in green how many points it earned;
• if exact score already includes goal difference or clean sheet, that must be stated explicitly;
• and if the user correctly predicted clean sheet or goal difference, those points should count even if they did not pick the winner.

The decisive line was essentially this:

it does not matter whether you got the winner right; if your clean sheet or goal difference answer is correct, you earn those individual points

That sounds like a small correction.

It is not.

It redefines what each bonus field means.

The real problem was not adding points, but explaining where they come from

Until now there was a very common temptation in this type of product:

• the user fills values,
• the engine computes,
• and the fine detail stays half-hidden behind the total.

The local world-cup-porra diff moves the other way.

Several connected decisions appear together:

• prediction autosave disappears;
• an explicit open bonus, edit, save or cancel flow appears;
• an initial-state snapshot is introduced to detect pending changes;
• each bonus field can now show its own score or the label included in exact score;
• and the points summary separates played points, obtained points and vote detail more clearly.

The strong idea is not "add more labels".

The strong idea is this: if bonus logic truly affects the result, it can no longer remain a private inference of the engine.

It has to move into the visible surface.

The most important rule change was removing a dependency that looked natural

Scoring had an implicit dependency:

• if you did not get the winner right,
• goal difference would not count as a separate bonus;
• and some clean-sheet cases were being absorbed by an interpretation that was too narrow.

Today's conversation breaks that dependency in a healthy way.

The new reading is cleaner:

That changes the form semantics.

There is no longer a single hierarchy where everything depends on the winner.

Now some fields represent different kinds of knowledge about the match, and they deserve different scoring outcomes.

When manual save appears, the message is more serious than it looks

Another visible part of the diff is the removal of autosave for this area.

That is not just an interface tweak either.

It is a product statement.

If the bonus layer becomes:

• more detailed,
• more interpretable,
• more sensitive in points,
• and easier to dispute later,

then saving it silently while the user touches controls stops being helpful.

It becomes ambiguity.

That is why the new flow makes sense:

The product is saying something fairly reasonable:

editing bonus values is no longer an ephemeral gesture; it is an action that deserves confirmation.

The UI is starting to accept that explaining points is part of the domain

The new per-field breakdown makes another hidden fact visible:

• it is not enough to calculate correctly,
• the product also has to explain why something is +3, +1 or included in exact score.

That reduces several kinds of friction at once:

• arguments about whether the system "gifted" or "took away" points,
• manual support effort for edge cases,
• and distrust when the final total does not match user intuition.

A smaller but very correct detail also appears: the final result should not be rendered as if it existed when the match is not finished yet.

That follows the same philosophy.

The interface stops asserting truths that the domain cannot yet confirm.

Even the release notification reveals the shift in mentality

Locally there is also a new release notification:

• it explains that automatic save was replaced by explicit save vote or save preview actions;
• it announces that Edit can be used afterwards while voting remains open;
• and it also communicates a concrete fix in the Saudi Arabia vs Uruguay goalscorer list.

That mix is revealing.

The product is not only notifying "we changed a rule".

It is notifying:

• how the action is now confirmed,
• which part of the flow changes for the user,
• and which piece of match reference data stops introducing bonus friction.

In other words: UX, mental model and reference data are no longer traveling in separate lanes.

The strong idea from these 24 hours: the bonus is now part of the public promise

During an early phase, the bonus can live as a secondary detail:

• one select here,
• one helper there,
• one total at the end.

Then that stops being sustainable.

As soon as the user wants to know:

• what exactly they earned,
• what was included,
• what is still editable,
• and when their change was actually saved,

the bonus stops being an appendix to the vote.

It becomes part of the public contract of the pool app.

What I am taking from this stretch

• No commits in a 24-hour window does not mean no product learning; sometimes the most delicate work shows up first in chat and local diffs.
• A bonus that changes the result cannot depend on hidden interpretations or poorly explained implicit hierarchies.
• Removing autosave in a sensitive area can improve the product when what you gain is clarity about when a change is confirmed.
• Showing points per field is not decoration; it makes scoring logic auditable.
• If exact score, goal difference and clean sheet express different kinds of match knowledge, the interface has to make clear when they score independently and when they are absorbed.

These were not 24 hours of accumulating commits.

They were 24 hours of doing something more uncomfortable and more useful: accepting that the bonus can no longer stay hidden inside the total. It has to be visible, debatable, editable and understandable as a central part of the vote.

Part of my product and platform notes. Follow the blog or contact me.