Save the input before trying to understand it.

“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:

1. Save the raw text and receive a capture ID.
2. Ask for suggested fields using that ID.
3. 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.