Save the input before trying to understand it.

Gergo Matyas — Mon, 21 Sep 2026 08:05:27 +0000

“Anna will send the contract tomorrow.”

That’s the kind of sentence I want to drop into Todoista between meetings. The app can suggest a person, an owner and a date. I get to review those suggestions before creating the item.

There’s a quieter design decision underneath that flow: the original sentence is saved before the app tries to interpret it.

The sequence is deliberately simple:

Save the raw text and receive a capture ID.
Ask for suggested fields using that ID.
Let me check the suggestions and save the commitment.

The review step in the actual Todoista app. The original sentence stays visible alongside the suggestions. Demo data.

The current parser is small: it matches people and recognizes a limited set of dates. Saving the input doesn’t depend on those guesses being right.

If processing fails after the server has confirmed the save, the interface tells me the capture was saved and can be retried. The text stays in the form. I can try again or use “Save as My task without suggestions” to keep moving.

That distinction matters. If the initial save fails, the app can only say the text is still in the form. It shouldn’t promise that the server has it.

There’s one more useful detail: each capture carries a request ID. Repeating the same save with the same text returns the existing capture. Changing the text while reusing that ID produces a conflict. A retry shouldn’t quietly become a second commitment.

This is one of the small implementation choices in my StoriesOnBoard-powered Todoista experiment. Suggestions are helpful, and keeping the original input gives me something concrete to review, correct or retry.

A quick-capture box earns its place when I can trust what happened to the sentence I just typed.

Building Todoista: who’s keeping track of the things you’re waiting for?

Gergo Matyas — Mon, 14 Sep 2026 07:58:16 +0000

You send a request. Someone says they’ll get back to you on Thursday. You tick off “send request” in your todo app and move on.

Thursday comes and goes.

The task you completed is neatly recorded. The answer you’re still waiting for? Somewhere in your inbox. Or Slack. Or your head.

This is the problem I want to explore with Todoista.

Most todo apps are built around a straightforward question: what do you need to do? That’s useful. But a manager’s day also involves work that’s currently with someone else. A delegated task. A proposal awaiting approval. A question that needs an answer before anything else can move forward.

You still care about the outcome, even when the next action belongs to another person.

And keeping all of that in your head gets tiring.

The idea behind Todoista is simple: give managers a place to track their own tasks alongside the things they’re waiting for. Who has the next action? When is it expected? When would it make sense to follow up?

Those last two dates can be different. If someone promises a proposal for Friday, I might want to check in on Wednesday. That little distinction matters.

I also want this to work without asking everyone around me to adopt another tool. Sometimes I just need to remember that Anna owes me an answer. Anna shouldn’t need a new account for that.

Todoista in dark mode, with your own tasks and the commitments you’re waiting for in one daily view. Demo data.

This is an experiment, so I’m keeping it small.

The goal is to explore my own business idea, build something useful, and see whether it deserves more time. I want to keep the setup simple and the running costs low—ideally free wherever that’s practical. Every extra service and subscription needs a reason to be there.

My time counts as a cost, too.

That’s where AI comes in. I want to see how much it can help me move from an idea to a working app at a pace that makes this kind of experiment worthwhile. My starting stack is Claude, StoriesOnBoard AI, and StoriesOnBoard MCP.

Claude, Anthropic’s AI assistant, will help me think through the idea, question assumptions, and work through implementation. Sometimes that might mean discussing a confusing user flow. Sometimes it’ll mean writing code and figuring out why it doesn’t work.

StoriesOnBoard gives the product thinking a home. Its story maps organize a product around what people are trying to accomplish, the steps they take, and the functionality they need. I’ll use its AI features to help develop the initial idea into user journeys and a manageable first release.

The StoriesOnBoard MCP connection lets compatible AI assistants access and work with those story maps. In practical terms, it gives the assistant a way to consult the product plan while helping build the app. I’m particularly interested in how well that context carries through into implementation.

There’s plenty to figure out.

How much planning helps? What context does Claude actually need? Where does AI save time, and where does checking its work eat those savings? Can I keep the whole thing affordable as it grows?

I’ll share the process here: shaping the idea with StoriesOnBoard AI, using MCP to bring that context into development, working with Claude, and making the small decisions that turn a demo into something useful. Expect examples, changes of mind, and a few things that don’t work on the first try.

You can take a look at Todoista already.

Stay tuned. Let’s see how far this idea gets.

DEV Community: Todoista.pro

Save the input before trying to understand it.

Building Todoista: who’s keeping track of the things you’re waiting for?