Why Hindigo will never show you a list

The starting idea fits in one sentence: never show someone everything they have to do — only the next single step, and only one. Easy to state. Much harder to hold onto over time than it sounds, and that difficulty is exactly what makes it the single most important rule at Hindigo.

A rule that gets betrayed in small doses

It’s almost never a head-on decision like “let’s add a list.” It’s sneakier than that: a preview of what’s coming next, a progress bar, a small “3 left” counter. Each of these sounds reasonable on its own — useful, even. And each one, added, would have quietly undone the starting principle.

Picture an entirely ordinary product meeting. Someone suggests adding a small “2 of 5” indicator at the top of the screen, so people know where they stand in their day. The intent is good: a sense of progress, a bit of motivation. Nobody in the room thinks “let’s add a list.” And yet that number does exactly what a list does: it announces that a set of tasks exists, with an end nobody has reached yet. It’s this kind of drift — never dramatic — that wears down a design constraint far more reliably than any head-on decision ever could.

The problem isn’t that these ideas are bad in themselves. Almost everywhere else, in almost any other kind of software, more information and more visibility are a default good. The issue is that the people Hindigo is built for do worse, not better, when they see the whole picture. Task-initiation blocks don’t get solved with more information — they get solved with less.

What cognitive load has to do with it

This isn’t just a design hunch — it rests on a fairly well-documented cognitive mechanism. Working memory, the part of the mind that actively holds what you’re thinking about right now, only handles a small number of items well at once. Faced with ten tasks displayed together, the brain doesn’t work through them one at a time in order — it first has to compare them against each other to decide which one deserves to go first. That comparison is itself a cognitive task, and an expensive one.

For someone with energy to spare, that cost goes unnoticed — prioritizing happens almost automatically. For someone already struggling to start, that same cost gets added straight onto the block instead of lightening it. The list, meant to help you get organized, becomes one more obstacle between intention and the first move. It’s a reversal that often surprises people outside the context of ADHD or a heavy mental load: more information doesn’t always make a decision easier — sometimes it makes the decision itself harder to reach.

There’s also a quieter effect, close to what psychology calls the Zeigarnik effect: an unfinished task stays actively present in the mind, even when you’re not looking at it. A visible task list is never neutral, then — every unchecked line takes up a sliver of attention, continuously, even while you’re trying to focus on something else. Multiply that by ten or fifteen tasks, and that background presence becomes a kind of permanent mental static, independent of any willingness to act.

The real test isn’t “is this useful?”

Nearly any feature can be justified as useful. That’s a bad filter. The test that actually works is narrower and more uncomfortable to apply: does this feature let someone see more than one thing at once? If yes, it’s suspect by default, not just in extreme cases.

Does this quietly recreate, even a little, the overview we’re trying to remove?

“Useful” isn’t the bar — almost anything clears that one. A searchable archive of past tasks sounds useful. A weekly summary of what got done sounds useful. A quiet “view all” button tucked into a secondary menu sounds almost harmless. Every one of these has been proposed internally at some point; every one was turned down for the same reason, never for lacking usefulness, but because it recreated, even at the edge of the screen, the possibility of seeing more than one thing at once.

What this looks like in practice

In actual use, this rule plays out as a very short loop: capture an intention, get one tiny step to complete, mark it done, then — only then — get the next one. Never an overview in between. Never a “see what’s next” button that would short-circuit the sequence. The person looking at their screen has no way of knowing whether there’s one step left or fifteen — and that’s exactly what makes every step equally approachable, with no hierarchy of effort to weigh before starting.

That choice has a real cost. In Hindigo, you can’t glance at everything left in your day. For anyone used to conventional planning tools, that can feel like something’s missing at first. It isn’t an oversight — it’s the feature itself. The constraint isn’t something the app hasn’t gotten around to yet; it’s something it refuses to do, on principle.

Why a regular to-do list isn’t enough here

A well-built to-do list solves two real problems: not forgetting anything, and knowing where you stand. Those are memory and organization problems, and for a lot of people, a clear list solves them just fine. But the block Hindigo is built for isn’t a memory problem or an organization problem — it’s an initiation problem. The person already knows exactly what they need to do; what’s missing is the bridge between knowing and doing.

A list, even a perfectly kept one, doesn’t build that bridge. It can even push it further away: the more complete and tidy the list, the more visible the gap becomes between “everything planned” and “what’s actually done” — and it’s precisely that visible gap that feeds the block instead of resolving it. Removing the list doesn’t remove the information; it removes the constant comparison between the size of the task and the energy available to start it.

Write the bans down, not just the intent

What actually helps isn’t remembering the original philosophy — that erodes under a busy roadmap, like any good intention does. What helps is writing the bans down in plain text: never a list, never a streak, never an overdue counter, never red. A candidate feature gets tested against that explicit list before it’s considered, not after it’s already half-built and tempting to keep.

It’s a different discipline than the one usually associated with building product. It’s not “what can we add?” but “what do we refuse to add, even when it sounds justified?” The constraint that matters most in a product isn’t the one written in the spec — it’s the one you have to keep refusing to betray, feature after feature, meeting after meeting, including when the idea on the table sounds particularly reasonable.

The Hindigo app holds this rule without exception: never more than one visible step, never an imposed overview. The power of the smallest step only works if nothing drowns it back into a bigger list — that’s exactly what this rule protects.