šŸ—ž Fleeting Notes Newsletter: Inside the Development Journey

This is the start of my newsletter and will be the last newsletter you receive unless you subscribe. In this newsletter, I'll be sharing note worthy articles relevant to Fleeting Notes as well as an inside look at the direction I'm planning to take the app in the future.

  • I've recently open sourcedopen source softwareSoftware for which the original source code is made freely available and may beĀ redistributedĀ and modified. source: https://www.oxfordlearnersdictionaries.com/definition/american_english/open-source Fleeting Notes source: https://github.com/fleetingnotes/fleeting-notes-flutter Fleeting Notes and made the code available to everyone. See my journey that brought me to this decision below.
  • A sneak peak on the fresh UI and the steps needed to release a full 1.0 release of Fleeting Notes.
  • Stagnating at $300 / month from Fleeting Notes and my plan to break this stagnation

My Journey with Open Sourcing a Note-taking appEmbracing the Future: My Journey with Open Sourcing a Note-taking appopen-sourcing-github.png Today, I want to share with you my journey and decision to open source my note-taking app, Fleeting Notes. Open sourcing an app is a big step and it can be difficult to let go of control and trust that others will use and improve upon your work in a positive way. But as I've come to realize, trust is a two-way street. If I want others to trust my work, I need to be willing to trust them in return. And that's exactly why I've decided to open source Fleeting Notes. In th


Today, I want to share with you my journey and decision to open source my note-taking app, Fleeting Notes. Open sourcing an app is a big step and it can be difficult to let go of control and trust that others will use and improve upon your work in a positive way. But as I've come to realize, trust is a two-way street. If I want others to trust my work, I need to be willing to trust them in return. And that's exactly why I've decided to open source Fleeting Notes.

In this blog post, I'll be discussing the benefits and risks of open sourcing an app, my personal experience with how I came to this decision and how what potential changes this will have on the future of Fleeting Notes. I hope my story can inspire and educate others who may be considering open sourcing their own app.


The most significant benefit for me, above all else, is the opportunity to build trust with the community. I believe that people are more likely to use products that they trust, and in which they trust the product, the developer, and the vision of the company. As the developer of a note-taking app, I understand the personal nature of the information that people store within it, and the level of trust that is needed for users to feel comfortable using it. That is why, I am determined to build this trust from the ground up, and I believe that open sourcing my app is a crucial step in achieving this goal.

Other Benefits:

  1. Community engagement: Open sourcing my app allows others to contribute to its development, which can lead to improvements and new features that I may not have thought of. This engagement can also help me to build a community of users and contributors who are invested in the success of my app.
  2. Increased visibility and credibility: Open sourcing my app can increase my visibility within the developer community, which can help to attract more users and potential collaborators.
  3. Increased security: With the help of the community, I can find and fix security vulnerabilities more quickly, making my app more secure.
  4. More Github Benefits: Github provides additional benefits to open-sourced projects (Easier issue reporting, discussions, roadmaps, binary distribution, etc.)


The greatest risk I take with open-sourcing my app is that someone could potentially use my code for their own gain. However, I believe that it would take a significant amount of time, energy and dedication to build a product that surpasses mine. And even if someone did, I would embrace the opportunity to collaborate with them, instead of opposing them.

Other Risks:

  1. Maintenance: Open sourcing my application may increase the maintenance costs as I will have to take care of the codebase, bugs, and updates.
  2. Bad Code Syndrome: Other people will see my terribly written code and decide not to use my app.

How I came with to the decision of open-sourcing

For a long time, I felt a sense of mistrust while developing my app. I tried to mitigate this by implementing a transparent pricing model, writing a comprehensive privacy statementPrivacy PolicyLast Modified: Sept 6, 2022 Thank you for choosing to be part of our community at Fleeting Notes ("Company," "we," "us," or "our"). We are committed to protecting your personal information and your right to privacy. If you have any questions or concerns about this privacy notice or our practices with regard to your personal information, please contact us at [email protected]. This privacy notice describes how we might use your information if you: * Visit our website at https://fleetingnote, and implementing end-to-end encryptionend-to-end encryptionEnd-to-end encryption (E2EE) is a method of secure communication that prevents third parties from accessing data while it's transferred from one end system or device to another. Source: https://www.techtarget.com/searchsecurity/definition/end-to-end-encryption-E2EE#:~:text=End%2Dto%2Dend%20encryption%20(E2EE)%20is%20a%20method,intended%20recipient%20can%20decrypt%20it.. Despite these efforts, I still felt an underlying sense of uncertainty when interacting with potential customers.

Recently, I came across a content marketing video by Alex Hormozi that resonated with me. In it, he speaks about the importance of delivering great content. One of his key points is the idea of "Give away the secrets. Sell the implementationGive away the secrets. Sell the implementationA quote from Alex Hormozi. Give away your secrets because only 1% of people are willing to implement it themselves. Then sell to the people who would rather pay for the implementation. Because most people need help. https://www.youtube.com/watch?v=91D5hjMEADg&t=2608s"

While watching the video, I drew parallels between this idea and my note-taking app. By giving away a free app and selling the implementation of the syncing service, users have the option to implement their own syncing services, but a good portion of them would rather pay for a service that provides value.

I want to take this concept to the next level by open sourcing the codebase of my app for free and see what comes of it. I firmly believe in the idea of "what goes around comes around," and open sourcing my app is a way to give back to the community and foster trust and transparency in my work.

The Impact on Fleeting Notes

To be honest, I am not entirely certain of the impact that open sourcing my app, Fleeting Notes, will have. However, I am confident that it will have a positive impact on the community. In addition to the benefits previously mentioned, such as increased visibility and community engagement on Github, I anticipate that it will foster a stronger community and attract new users who are more inclined to try open-sourced projects. Ultimately, I believe that open-sourced apps are the future, and I am excited to be a part of it.

Also for those readers that made it to this point. Here's my github repository.

A sneak peak on the fresh UI

After conducting a poll in my Discord community, I realized that the most sought-after feature was a more user-friendly interface. So, I put my pride aside and set out to create a new UI for the application. The challenge was that I am not a UI designer by trade.


To overcome this obstacle, I decided to emulate a mail app from the Material Design website as a starting point. While this provided a solid foundation, there were still some missing elements that I couldn't transfer from the mail app to my own design. For those areas, I looked to other apps like Google Keep and Raindrop for inspiration. It was definitely a learning experience, but I am now nearing the finish line and I am eager to hear your thoughts on the new design. Below is a sample of what I have so far. Please keep in mind that this is not the final product and I welcome any feedback you may have. Simply hit the reply button and let me know your thoughts!


Stagnating at $300 / month

As the creator of Fleeting Notes, I've been closely monitoring the growth of my application since its inception. Unfortunately, I've noticed that my explosive growth has plateaued and even dipped a bit. Currently, my monthly recurring revenuemonthly-recurring-revenueMonthly Recurring Revenue (MRR) isĀ the predictable total revenue generated by your business from all the active subscriptions in a particular month. https://www.zoho.com/subscriptions/guides/what-is-monthly-recurring-revenue.html (MRR) sits at around $288. You might be wondering what caused this decline and where it all began.


In October, I performed a migrationHow I Migrated 1000+ Users from Firebase to SupabaseWhen beginning my journey as a Flutter developer, I thought Firebase would be the best backend solution for Flutter. Given that both are made by Google, I thought this would be the backend that would be the most stable and flexible. I was wrong. The lack of full native Dart support, slow build times, sketchy workarounds, and no desktop support led me searching for another solution. After many hours of research, I was faced with the choice between two frameworks: Appwrite and Supabase. Both were that unfortunately introduced a few bugs into the app. These bugs caused me to lose a few users and negatively impacted my conversion rateconversion rateTypically when a user or recipient of a message performs a desired action. For example, it could be the rate of people who go from signing up for Fleeting Notes to subscribing to a plan. 100 people sign up --> 10 people subscribe = 10% conversion rate. For the following two months, I focused on fixing these bugs and improving the stability of Fleeting Notes by adding a more comprehensive test suite. But since the end of December, I've been feeling more confident in the stability of my application. Even in my charts, it's clear to see that my MRR has been reflecting that.

Now, I'm at a point where I'm confident in the stability of the application, and I'm shifting my focus to improving the user experience and adding key new features. In the coming months, I'm planning to release a 1.0 version of Fleeting Notes, and before that, I want to complete two main things: improve the UI and create a developer-friendly plugin framework.

The reason I want to focus on these two features in particular is that the UI definitely needs a major improvement, as stated before. The plugin framework, on the other hand, will make it easy to extend Fleeting Notes for specific use cases. For example, a command to:

  • Copy a note to any other cloud service (e.g. Notion, Twitter, Facebook, etc.)
  • Merge notes with the same source
  • Send the contents of a note to ChatGPT

These are just a few plugin ideas off the top of my head, but I believe it will open up a lot more opportunities in terms of customizability without cluttering the UI for users who don't enable the plugins.

That's a wrap-up for this week's newsletter. If you have any thoughts you'd like to share, please don't hesitate to hit the reply button and reach out to me.