I have been thinking about building a particular product for a couple of years now but just haven’t made, or perhaps kept, the commitment to keep working on it. Rather than keeping to myself, I thought it would be wise to share with the world what I’ll be working on with the aim of being held accountable to someone. As I work through this challenge for the next six months I’ll be sharing what I am doing along the way.
I first heard of the Web App Challenge a good number of years ago when Nathan Barry started it for the product that became ConvertKit. I don’t recall if he took the web app challenge idea from someone else or if it was just his own. I like the idea of public commitment because, in some ways, there is a little bit more accountability there. It inspires me when I share what I am working on, and I also like reading blog posts from other creators who are building products. It’s great to see how they work, what they work on, and at the end of it if a working product is built.
Part of the inspiration also comes from the book, Show Your Work*, by Austin Kleon, I highly recommend it. A very brief overview is that you share what you work on regardless of being a beginner or not, and in the process, you attract an audience of people who have an interest in the information you share. This challenge also includes me writing about it to find others who might be interested in it.
An Introduction to Notic Meet
For most of my adult life, I have been involved with meetings, and for a large amount of that time, I was responsible for taking minutes and sometimes recording action points. I have tried various ways, starting in 1999 using pen and paper, then on to a PDA such as the Casio Cassiopeia and HP iPaq, trying to scribble notes with a stylus. Shortly after, I used a laptop and Microsoft Word, and as the years went on I tried various things such as having agenda items on a Trello board to sharing a Google Doc.
By far, the easiest and quickest way of keeping up with what was being discussed was a simple plain text document. Rather than trying to fiddle around with a Trello card and, in the process of finding it, missing some of the discussion, I found it easier to just keep writing and then, after the meeting, review what I had written and extract the action points and items that need to be added to the next agenda.
The tricky part I found was keeping track of action points and agenda items across meetings. A challenge I faced was that notes taken in last week’s meeting are not looked at, so when the same agenda item is discussed over multiple meetings it is very easy to lose context, with it being quite common that an agenda item just drops off the radar which makes the whole initial discussion a waste of time. What was the point of discussing something for 20 minutes with the intention of actioning it and then never discussing or seeing it go somewhere? It’s an easy thing to do. We all have the best of intentions to do things, but life gets in the way, as well as other responsibilities get in the way.
I’m all for deciding not to do something, but the main pain point is forgetting that we discussed something. Dropping an item on purpose is far better than dropping an item because of being disorganised.
A couple of years ago, I started planning an app called Task. This was to be a simple text editor with the ability to track tasks from what was written. Over time the product name became Notic, but in discussing the designs of it with a friend it became apparent that two products existed. One was a meeting planner, and the other was a PKM or personal knowledge management product. Given that we discussed meetings more than PKM, we decided to put all of our attention into Notic Meet, which would be the first product to be built. At a later date, I plan to still build Notic PKM and launch it. This is one I am also excited about. I think you’ll like the ideas that I have for PKM.
Note, Plan, Do
Three ideas came out for Notic Meet, which I refer to as Note, Plan, and Do.
This section is where you are presented with an empty box and a cursor to just start writing everything that is needed to be recorded from the meeting. This includes discussion points, action points, and anything in between that is useful to be recorded. This section will need more explanation in a future post because it will be a little Bir more than just an empty box with a cursor, but will still be kept to a minimum set of shortcuts to help quickly move between items being discussed.
The second section is Plan. This is where you check and extract action points and potentially fix any errors. This is where you “plan” what needs to be done, who will do it, and when. Some of this crosses over into the Note section so you can organise as you write, but more info will be presented at a later date.
The Do section will be an overview of what needs to be done. These will be things that need to be done across all meetings. If an action hasn’t been done then it will be on this list, regardless of how long it has been there. If you decide it no longer needs to be done then you can check it off or adjust it in the Plan section.
Anything outstanding will be in here. Whether “Speak to Phil to book the Christmas meal” or “Make a list of people who can plan the summer BBQ”, these will all end up in Do.
Threaded Agenda Items
A challenge of taking notes of meetings is that all notes for a meeting are put in a document. If I want to know what happened in our stand-up meeting on August 3rd, I scroll through a list of files and find the meeting notes for that particular meeting.
A challenge I have encountered often is what happens when agenda items get discussed across multiple meetings. The discussion points are spread across multiple files.
With Notic Meet, the plan is to put these in a thread. When you load up notes from a meeting and see a discussion point, you can tap on it to see any associated history where the item was discussed and assign it to a future meeting if it needs more discussion.
I’m giving myself about six months to build the product. Currently, I have some sketches showing functionality, some of which will be shared soon. I also have a design for storing the data and how the structure will look.
The Technology Stack
I mentioned earlier that the first build will likely be for iPad only, potentially with an iPhone version being prepared. There will be some nuances in design with the iPad having so much more screen estate, but essentially, the components will transfer over with minor adjustments. It will be written in SwiftUI unless I hit too many problems with that. I am still new to SwiftUI and do not know if it’s mature enough to do all I need, but time will tell.
At some point, the product will become multi-user and multi-platform to have a web version and an Android version. I don’t yet know if CloudKit will be sufficient for this to be a multi-user product in the Apple ecosystem. If it is, I’ll use that, but if not, then I am looking at Laravel to be used for the backend. I worked with that a couple of years ago and found it worked well to simplify a few things.
If I need to launch with Laravel, I think I’ll use Laravel Vapor to deploy it. I’ve read good things about its ability to scale well.
Ideally, I’ll keep the first version within the Apple ecosystem because there will be no costs associated, but I’m willing to switch to whatever is needed to get this working.
I will be receiving help from a friend with this. He has been helping with the design of the app as well as usability and ideas that will be put in to version 1 of the app. Having someone to bounce ideas off of has been a huge help. I fully believe that building a product is best when more people get to chip in their ideas and provide assistance.
The plan is to write every few days about the progress I am making, although for now I am committing to writing once a week at a minimum so that progress doesn’t stall.