Building Spicy Brain without building another productivity trap

Software intended to help people organise their lives has an uncomfortable habit of creating more work.

You begin with one thing you do not want to forget. Soon you are maintaining categories, priorities, projects, contexts and a carefully tuned notification system. The tool has become another system whose rules must be remembered.

Spicy Brain started with a simpler question: what would a planning tool look like if reducing cognitive load was the main product constraint?

The problem is not a missing feature

There are already thousands of task and reminder applications. Building another one only makes sense if it changes the relationship between the person and the work.

For Spicy Brain, that means three things:

• Important actions need to be obvious.
• The product must explain the consequences of a choice before somebody commits to it.
• A person should be able to return after a bad week without first repairing their productivity system.

Start with the user-visible model

Reminder recurrence can become technically impressive very quickly. It has schedules, start and finish boundaries, timezones, linked records, notification channels and different meanings of “done”.

The interface should not expose that machinery all at once. A person is usually trying to express something closer to:

Remind me about this every month, stop after December, and send it somewhere I will actually notice.

That sentence is the product model. The database and scheduling code still need precision, but they should support the sentence instead of replacing it.

This approach affects the engineering. Validation lives at clear boundaries. Recurrence-specific values are only sent when the selected recurrence needs them. A finish date cannot quietly precede the start. Notification channels are selected from what the account can actually use.

The rules are strict because the interface is trying to feel forgiving.

Accessibility shapes the architecture

Accessibility is not a layer I want to apply after the feature works. It changes what “works” means.

A predictable focus order can affect component structure. Clear error recovery affects request validation. Reduced motion affects navigation and feedback. Supporting large text affects how much information can safely be placed in a single row. Plain language exposes whether the underlying product model is coherent.

This is useful pressure. Accessibility regularly reveals accidental complexity before it spreads further into the codebase.

One product, several surfaces

The web application uses Laravel, Inertia and Vue. The mobile application uses Expo and React Native. They do not share interface code, and I do not want them to pretend that a browser and a phone are the same device.

They do share a product model and an API contract. The backend remains the source of truth. The mobile client keeps authentication material securely, caches server state, and owns only genuinely local concerns such as appearance and temporary form input.

That separation is less glamorous than promising “write once, run everywhere”, but it is easier to reason about and gives each platform room to behave properly.

The work around the feature matters

Building Spicy Brain means working across more than screens:

• authorization policies and request validation;
• queued reminder delivery;
• email, browser push, native push, Discord and Telegram channels;
• API resources shared by web and mobile;
• device lifecycle and notification actions;
• accessible component states;
• deployment, monitoring and recovery.

The interesting part is not the length of that list. It is keeping the connections understandable when a decision crosses several of those boundaries.

What I am trying to prove

Spicy Brain is still in active development. I am not presenting it as a finished answer to productivity or neurodivergence.

It is evidence of how I like to work: start with the human problem, make the rules explicit, keep ownership clear, and treat the awkward operational details as part of the product.

The goal is not software with the most options. It is software that asks less of the person using it.