Have you ever had the desire to journal but quit because it was too much effort? Amanda Deng and I always had this issue and attempted to find ways to do so. We tried bullet journaling, diaries (paper and digital), and iPhone apps. However, we could never get into a consistent habit. We began to wonder, why couldn’t we keep up with writing? Why weren’t existing solutions working?

That’s why we created Ponder: A daily journal from your new tab.

Ponder started as an MIT Web.lab project. We were just two bored CS seniors over the January term at home and decided that it would be fun to do a small project in two months with a presentable project. We were busy in the spring, so we only brainstormed ideas with a manageable scope and complexity. We had some pretty interesting and novel ideas, but in the end we wanted to make something that we would both use. That gives us at least two users! 

What started as a side project to combat quarantine boredom with a friend ended up becoming a full-fledged journaling extension with 300+ upvotes on Product Hunt (and top 10 on launch day), 500+ chrome users, and tons of cool features! (Try it today: https://getponder.app)

However, building the chrome extension was only half of the work; launching was just as stressful. We’ve learned a lot from developing Ponder and wanted to share some of the lessons we learned. 

Ponder is written in typescript with a React front-end, Node.JS backend, and MongoDB database for optional server syncing.

Set ambitious goals, prioritize and refocus

We were ambitious. Make a chrome extension in two months and get 100+ DAU. We brainstormed feature after feature. But at the end of the day, we prioritized which features to add and spent a lot of time figuring out how to add them effectively. We wanted Ponder to feel simple to use, but that made coding it a lot harder than expected. 

Every week, we’d set goals to complete by the end of the week. We didn’t finish every goal, but it allowed us to keep things on the horizon. Due to time, we decided not to implement many features. However, organizing ideas and features beforehand helped shape our project design and saved us time rewriting code. By creating roadmaps on Ponder features, we had a much quicker development, especially near the end! 

One feature that was constantly delayed was a way to view entries. While it seemed simple, the UX/UI turned out to be more frustrating to implement. We could’ve made the entries page much better and with more features, but instead, we spent that time perfecting Ponder’s main homepage and onboarding. I don’t regret that decision at all.

While we still have many more features to implement, they’ll luckily be easy to add in the future!

Get inspiration from other websites and apps.

From experience, I’ve made some questionable UIs. However, I’m proud to say I am really happy with our design. But good UX/UI doesn’t come from one person. Before designing ourselves, Amanda found other websites and apps that we’d use to inspire our design. Honestly, it was an excuse to take a break from thinking and browse Pinterest and all the big tech company websites. We were both big fans of Stripe’s UI and its use of color and design. We took the elements and colors we liked and slowly built out the product on Figma. Figma is free for students and makes it easy to collect and ideate different mockups. Since Amanda and I weren’t even in the same time zone, we found Figma essential to sharing designs. 

We both knew that we aren’t the best in design, so why not get inspiration from the best? It was faster to do that than spending hours trying different layouts. 

Mockup your UI before implementation.

As someone trying to finish projects quickly, I put all my code in a few components, which creates a few files with many lines of code and functionality. Before Ponder, this naturally happened as I modified the UI and slowly added features without considering how to modularize the code.

We mocked up the UI before implementing it with Ponder, making it easier to decide on the different components. The code was cleaner and much more versatile, which allowed us to make feature requests and resolve suggestions from beta testers quicker. I also appreciated not having to reorder components and renest different divs on our site.

UX (User eXperience) is king.

We had many discussions on the tradeoff of the simplicity of code vs. the simplicity of the UX. Both can rarely happen, and we chose to make Ponder as UX-friendly as possible. It added significant overheads to the extension because variables and data had to be available in different components in a non-hierarchical format. For example, allowing users to change a setting in two parts of the extension meant ensuring that if the user changed the setting, both parts of the extension updated to the correct value. Technical sidenote: I’d recommend using a global data provider hook to provide consistent variable values across all components.

Although it was harder to implement, it made the extension much more straightforward and intuitive to use.

Launch your beta as quickly as possible.

Once we got beta users, we realized many of our assumptions were incorrect. We constantly reprioritized and reworked our features after listening to our beta testers. We recruited a few initially by reaching out to friends and Facebook groups and sending the unlisted chrome extension link.

We found 30-minute interviews where we ask about all the different features in our app helpful. On top of functionality, we found asking them for UX/UI advice was also very helpful, whether that was the location of buttons to the wording of the words for clarity. In the end, we onboarded 50 beta users and interviewed 20+ users in a staggered format to ensure that we addressed all previous issues.

As much as we wanted to launch quickly, we had to take a step back and ask: were our beta testers happy with the current iteration? Initially, they were not, and I’m so glad we didn’t launch Ponder then.

Add Analytics Early.

We made a mistake not to include analytics in the earlier versions of the extension. We had no clue on what our users were using and what features they chose not to use. Adding more analytics could’ve helped us a lot more in determining what places to focus our attention on. We eventually added analytics to when users completed writing for the day, clicked certain buttons, and visited the settings or entries page. These analytics gave us a way to see what components and features to focus on.

Prepare for Producthunt.

Launching our product was just as hard as making the extension itself. The assets and description of the extension took much longer than anticipated. We should have started with promotion and asset creation earlier. 

Finally, we looked for someone to promote our extension and a date and time to publish. After reading suggestions from multiple sources, we decided to launch on a Monday in the early morning with Nick Abouzeid as our hunter.

We were stressed and excited on launch day and didn’t do any work all morning as we began to post on our social media and slowly watched Ponder’s upvotes go up!

Don’t forget about Safari.

As much as I wanted to make this application chrome only, Amanda quickly reminded me that Safari has a nontrivial market share. Approximately 20% of desktop internet users are on Safari. Because of this, we spent the time adapting the Chrome extension to work on Safari and launched it on Safari a few weeks after!

Final Thoughts

All in all, we think this was a fun project and are both satisfied with the outcome. Hundreds of people (including us!) still use Ponder and write a little bit each day! We probably spent at least 100 hours each on this project, but it was so worth it. We’ve learned so much from creating something from scratch!

Try it out and start journaling a little bit more each day! https://getponder.app

Questions? Don’t hesitate to send an email to Amanda ([email protected]) or me ([email protected]). We also love listening to idea pitches and giving feedback on them!