Prisma with PostgreSQL: the hard things about building a no code database
Building Cycle has been a challenging journey. We initially built the product, then rebuilt it a year later, and finally built it again the year after that. It took us a total of two and a half years to establish a solid foundation that we could be proud of. However, why was it so complicated to create a seemingly simple product? What were the requirements that made developing a tool for product teams so complex? Luckily, we were naive enough to jump in and believe that everything would go smoothly!
Every product team has its own unique typology, with its own process, concepts, and way of structuring product information. From the very beginning, it was a requirement to build a framework that could adapt to these different typologies. Some teams prefer to create bugs and features, while others prefer to create problems and solutions. Some teams even combine all of these elements and link them together with a well-thought-out hierarchical structure. This left us no choice but to build a no-code relational database. What could go wrong, right? 😅
Cycle's basic entities are simple. The "Doc" is the atomic unit. The "Doctype" simply refers to the type of Doc you want to create (e.g., a bug, a feature, etc.). You can also add hierarchy constraints between your Doctypes. "Properties" are custom links with Doctypes and allow you to decide which values can be assigned to a Doc. Lastly, there is the "View," which is the way to visualize your Docs. You can actually make a comparison with a relational database, where Doctypes are Tables, Docs are Rows, Properties are Fields, and Views are, well... Views.
