It’s been a bit more than two months since I decided to create something around a problem I care about. I deeply hate meetings. Inefficient meetings are a plague. I am building a solution to help you improve your meetings. What final shape that will have, I am still not sure, it will definitely change along the way, but it is something I want to tackle…. #buildinpublic
Speed is key. I know, it is not as fast as developing and testing in a week as @shl process (I have a couple of ideas I’ll test his process with, but not this one). I had a few domains saved for side projects and that’s the one better fitted for the project…
My goals these past months have been a) validate if there if it is a problem want to have solved (can it get traction?) b) if I can deliver the technical parts, c) can I deliver value by solving the most annoying parts of meetings…
So far it is going great, but I am gonna review some of the mistakes I have made this time. I think it is also important to review your errors. They are not the only ones, but the more painful ones.
Diving fast into developing something you do not know…
Launching the Chrome Calendar Extension. I had zero experience with extensions. I have learned a lot about it during this time. Something that is kinda tricky when developing extensions is there is no easy way to declare environment variables.
Why is that important?
The first time I submitted the extension to the Chrome Store, I forgot to change the (hardcoded) API endpoints! It was approved, but was making the calls to… localhost ?♂️. Another important learning there.
Every submission to the Chrome Store goes through a cycle of up to 10 days to be re-approved. Sometimes it takes less time, sometimes more. Insight from all this?
- Run an exhaustive checklist, making sure that all that could be broken is not broken…
- Regressive tests are your friends. Not at this stage though, many things will change. But eventually will have a set of regressive tests to run before submitting. Testing chrome extension is a different beast. Will probably write about it at some point…
Mistake number 2, not checking my requirements when picking my stack
Without going into much detail, I found out, when I was already committed with a stack (having developed a substantial part of what I had planned), that some of the things I wanted to be able to do, were…
complicated. NextJs comes with a couple of great advantages, like having an API out of the box. Well, that was not easily deployed on my platform of choice. Also generating dynamic pages had some complexities.
In the end, I was able to overcome those hurdles, but I had at least a couple of stressful days.
Insight?
- Listing the critical needs of your project. Going through them, and checking they are available in your stack… can save you a lot of headaches.
I think the main lesson is it is okay to make mistakes. Shipping fast, finding insights sooner, make up for the mistakes.
