Mee: Knowledge Organization Web App


T.L;D.R.: Mee is a knowledge organization platform. It allows users to put information into cards placed on boards, enforcing order and curatorship. The kind of input accepted is markdown text, web links, images, and videos. My role on this project is managing the product and architecting its software. I get to identify business rules, write them down as specifications and expose that in SCRUM meetings. This ensures Mee's development team can implement features and fix bugs while knowing how their day-to-day activities relate to the big picture.

Architecture in a glimpse: Mee's system consists of a react front-end, serverless backend, DynamoDB database, and integrations with third-party payment systems, SSO and others.


How it began

Circa July 2018, I was approached by a friend I made while working with fine print at OTSP, Mee's founder Rafael Nepô. He pitched me a project about creating a knowledge organization platform, and his ideas blew my mind 🤯. In less than a month we had a contract, and I was on his team.

That was and continues to be a massive opportunity because both I and Nepô are people-first long-term growth-focused human beings, which matters when dealing with knowledge. But, the long-term starts now, and we had a blank page: I had to help define from business and visual identity to product UX and infrastructure. A process that continues to happen with the help of wonderfully skilled people.

Looking back, the most crucial decision we made was to begin collaboratively documenting our business specifications. I kickstarted the first draft, forcing the whole team to come together and solve problem by problem. With each new question raised, we could write the necessary details to plan the product's UX and development. That gave us a path to follow, and even when we ran late, the effort we put upfront in writing specifications helped us keep together and continue to focus forward.

Identifying the scope

From the first time we sat down, there were ideas for ten-plus years of development. That’s why we decided to go with an individual knowledge organization application.

And that raised a plethora of questions, from what operations are the minimal set for users to do business with to what should be the data structure to hold their content and how to render it. What followed were weeks of writing specs until business entities were mapped and a solution could be visualized. We knew our key asset was our curatorship methodology.

Curatorship. Visualized

A board of trails that works like a stack of carousels o content. A simple solution. Yet reaching it was no walk in the park. Many problems had to be solved, from device-specific performance issues to programmatic navigation when pasting links.

But I would argue that one of those that required the most engineering is the navigation service: It listens for clicks, key presses, and swipes using Event Listeners and react-use-gesture. And when one of those inputs is detected, this service uses a custom algorithm to tell the card to be activated. Then this information is passed to react-spring as a DOM Ref for a smooth animation between the current card and the activated one. At the same time, the card’s id is given to another service that will fetch its content from the server along with its neighbors' content. Long live async rendering.

The current state of the project

As of August 2022 we are looking for an investor aligned with our vision, so we can continue to move our product forward and launch it for a broader public.