Reflections on Five Months of App Building

I spent the last 5 months building a social habit tracking app with two other friends. We currently have a working MVP, and are looking to continue to learn & build for the next few months as well. The following are my takeaways from these past few months.

Fear

I was too afraid to be wrong throughout this entire process. The concept of fear ties into the following sections of assumptions, interviews, and design.

Assumptions

I was not systematic at all regarding the assumptions we needed to validate as we began the journey. Who are the target users? Do people want to participate in social habit tracking? Do they want to initiate creating groups? Will people invite their friends to a new app? Will people download an app? What are the most important habits to cover? WILL THEY PAY?

What is truly crucial to build? Note: The way our app ended up is pretty barebones and solid for an MVP to start getting usage data from tbh. BUT I think we ended up here after a lot of random (and inefficient) debate, and critical feature cutting before the deadline. Pretty lucky.

Great example: Designed an entire monetization screen, but ended up just verbally telling people I would cut them off from the service and only keep them on if they venmo’ed me $3. Very little time and effort, very effective in gathering results. This is how I should have aimed to prove or disprove every assumption, but I didn’t — and didn’t even have assumptions listed out in the first place.

I was very afraid of being wrong and instead tried to execute (design & eng) our way to a solution, which in 99.99% of cases will almost certainly not be the right one. What about measuring? What about learning? And continuing to ideate? Well, I guess that can be done after five months of work lmao.

Should have mapped out our assumptions and found the most most most bootstrap-y way to validate them before any substantial design/engineering work progressed.

Interviews

This ties into Assumptions, but I was too afraid of being wrong throughout this whole research process. It was tough for me to even be aggressive about super generic user interviews (usability interviews went decently and were semi-helpful). What if someone came around and told me that habits are fucking pointless and they would never use a social habit tracker?

That’s fucking great news! And we can all move on and pivot or figure out a better way to do shit. Luckily I think we have a small amount of proof that shows that we are “right”, but we could have really proven things early on and made decisions with better grounding.

Our snapchat habit group was a great proof of concept, should have been WAY more intentional about that and emphasized/forced everyone to get into a group with their friends and act a team captain/cheerleader/starter to prove that this could at least exist with a very strong “leader”.

Design

Design decisions were done SO haphazardly. Just stupid debate where loudest/most falsely opinionated/sort of logical decision was gone with. Why did we decide to use scorecards? Why did we add a journey length for habits?

How do we come to better design decisions in the future?

I think possibly more iterations — obviously design is easier to modify and create multiple new iterations from scratch as opposed to full-on engineering implementation. However, regardless if we had one design or 5 designs to choose from, the design decisions we made would always feel intentional but in reality, were not. There was no underlying design theme or really solid foundation we based design decisions on. Just a loose overarching theme of “competitiveness”, “cooperation”, “flexing”, “slacking”, etc. No validation or prioritization on those characteristics either, just a hunch. That is probably one of the reasons why it was so hard to reach a conclusion — especially in the beginning with our app layout. And also I am not that great of a designer lmao.

Design decisions were not grounded… in anything concrete. Not sure what the right answer is to ground our decisions, but probably has something to do with how we want to make users feel (and which user demo & actions we’re targeting).

Engineering

My communication to engineering felt haphazard a lot of the time (on my end). I would have updates, and we would have agreed on a general roadmap, but it felt like I was just giving you shit to do, with no priority, and hope you would feel just as good as I did and know how to build.

Most of the time did not provide enough context around why we should build, how we should build, or the prioritization on what we should build first. Luckily, Young Guo & Ryan Yue have big brains and organized most everything I threw at them and somehow built everything.

General Communication

I’m still SO fucking wordy. Agendas might help a bit but I need to take time to synthesize my thoughts intentionally until I can be an effective communicator naturally. Meetings lasted way too long and I wasn’t clear enough verbally. Documented communication seemed to be decent for the most part, a few miscommunications or not enough communication, but usually resulted in a mostly clear course.

Although, in reference to the other blurbs, was never sure if the “clear course” was also the right course.

An update to the story.