Recently I have outlined my framework for determining the ‘why’ of a project: what problem it solves and what are its main requirements and target, its return on investment, and, finally, if it is at all viable. Today we will look at how it works on a small pet project of mine listOK – a shopping/to-do list Telegram bot (project page).

1. What problem does the project solve?

Keeping track of items they need to buy/do in different contexts/places.

2. Whose problem does it solve? / Who are the target users?

First and foremost, it is a personal problem, i.e. the minimal viable audience is me. All other users are extra: I will make it public eventually, but only after it satisfies my own needs.

3. How do you know that the problem exists?

Every time I go to a supermarket, it is a hassle to gather a groceries list in one place. Moreover, the list must be updated (“this we bought last time”, “this we do not want any more”, etc.).

Second use case: keeping track of items to do or buy in rare contexts, for example, hardware store, IKEA. Items are added to these lists only sporadically and the lists are used rarely.

4. How do users solve this problem now or solved it in the past?

I tried different options: paper lists, special shopping lists apps, store brand apps (using an online order cart as a shopping list), task trackers, generic notes apps, built-in digital notes, etc. In the last couple of months, I use two Telegram chats: one with my wife and one with myself (‘Saved Messages’).

5. What is bad in current/previous solutions to the problem?


  • hard to find to use or update
  • easy to lose (no backup)
  • easy to forget at home
  • need to have different lists for different contexts
  • not interactive – cannot mark items as done or active

Shopping lists apps:

  • can be slow and tend to become slower with time
  • some require an internet connection to work
  • sometimes updates break my use cases
  • can be used solely on my phone: few apps are multi-platform
  • some stop being updated becoming obsolete or stop working altogether

Task trackers:

  • mixing tasks with shopping lists increases cognitive load, better to separate these contexts
  • tend to be slow on mobile
  • often require an internet connection or work poorly without it

Generic notes software (Notion, Evernote, Google notes, etc.):

  • often slow
  • have too many functions which are not required for shopping lists
  • limited interactivity
  • often require an internet connection or work poorly without it

Built-in digital notes:

  • not interactive
  • often cannot use them from different devices (for instance, add items from desktop), although less problematic if you live in one ecosystem (Apple, Google)


  • not interactive
  • items cannot be organized (reordering or different lists for different shops or contexts)

Note: here we start to see requirements for the new project: offline mode, interactive, several lists, can be used on other platforms (desktop, platform, etc.). More on that in a separate post.

6. What is good in previous/existing solutions?

Paper: works offline.

Specialized list apps: interactive (can mark an item as completed, sorting, subsections, etc.)

Task trackers:

  • interactive
  • often available across different platforms

Generic notes apps:

  • some work offline
  • accessible on different platforms

Built-in phone digital notes:

  • work offline
  • sometimes can be synced on different platforms


  • mostly work offline
  • messaging app is fast and is often already in the device’s memory
  • accessible across different platforms

7. What kind of improvement in users' life do we expect from the project?

  1. Decrease cognitive load for tracking items.

  2. Reduce the time required for tracking.

  3. Smaller risk of forgetting to buy something and, consequently, less frustration and fewer shopping trips.

8. How will you know that the project is successful?

  1. The app becomes the only ‘source of truth’ for shopping lists.

  2. The app is used for at least three months.

  3. There are no more questions “Where to write it down?”, “Where is the list?”, “Am I forgetting something?”.

9. Can the problem be solved without developing a new project (manually or with an existing project)?

Yes, by choosing an existing solution. Here, for a larger project, it would be important to analyze them. First, to gather ideas, pitfalls, etc., second, to gauge competition. Since it is a small pet project, a significant part of its return is in doing the project (more on this below).

10. What will be the return on investment?


  1. Up to 40 hours, including diving into new technologies and instruments, setting up infrastructure, basic CI/CD, backups, plus several hours for support, etc. Here I cheat a little bit: I have already chosen a stack for the project.

  2. No additional costs for hardware: I already have an instance running which can host this project.


Saving time:

  • assuming I record items to buy at least once a day (sometimes skip a day, other times several times a day) and it will save me 1 minute per day compared to other methods, 365 minutes ≈ 6 hours per year

  • at the store – let’s say 2 minutes per visit _ twice a week _ 51 weeks = 208 minutes ≈ 3.5 hours per year

  • spares me an occasional extra visit to the store due to some item(s) falling through the cracks of a worse tracking system – one 1-hour visit every two months = 6 yours per year

Total time savings per year: 15.5 hours. Admittedly, these are very crude estimates, although, for this project, they only need to be in the same ballpark.

Apart from direct time savings, the project will have additional perks:

  • Reduce cognitive load: frankly speaking, it is just irritating and takes up too much headspace.

  • Save money: having a reliable list reduces the need to browse the aisles in an am-I-forgetting-something mode, risking being caught in a marketing campaign, buying junk food, or something I do not really need.

  • Better shopping choices: the same logging as above – build a healthy plan at home and stick to it at the store.

I intentionally do not put numbers on these. Without deep research any estimation will be a stretch and for this kind of project, it is not required.

As a pet project it has extra benefits:

  • get additional development experience: each project brings its own challenges
  • learn new technologies (if applicable)
  • have a new project for portfolio
  • help other people with this project (if applicable)
  • write about the process and findings

Based solely on time savings the annual return on investment will be 15.5 / 40 = 38%. As investments go, this is not bad at all, however, it is more of an upper bound, plus the project will require maintenance and attention. To get a more conservative estimate, let’s assume that the returns will be twice or four times smaller: 19% and 9%. These figures are less attractive, but still manageable, taking into account other benefits of the project.

I will skip the last part – comparing the ROI of this project to others. It is a small project with a decent ROI and will not delay others.

Ok, the project has passed its ‘why’ test. Now we need to condense the information here into a list of requirements and choose the stack.