Alex: Status Update 2025-07-29

Last week I've implemented discovery for comments (and actually any other snapshot-based resource in theory). For this week I'll be working on the following things:

Migrating UI Components from Tamagui to Tailwind

(Photo by Miko Guziuk on Unsplash) When we adopted Tamagui, our goal was ambitious but clear: build a unified UI component system that we could reuse across all platforms — Electron (desktop), Web (Remix), and eventually React Native for mobile. The dream of writing once and reusing everywhere was enticing, and early on, it felt like we were on the right track. But reality hit us hard. The Challenges We Faced Admitting Our Part in It Setting a Plan in Motion Choosing Our New Stack Failed Attempts and What We Learned Where We Are Now Thanks for reading! This migration has been a tough but necessary move to keep our momentum as a startup. I’ll continue to share updates as we progress — and hopefully provide more insights for anyone considering a similar shift. Update: 19/06/2025 Update: 22/07/2025

Design Updates: Activity Panel, Contacts

Activity Panel Contacts

Document mention email notifications

Demo Brief

Custom Navigation

We have been building a custom navigation UI so you can modify the nav bar of your site! Still working on some minor fixes, but this should be ready for the next release.

Document change email notifications

Demo

Subscribing to email notifications without an account

Refactor By subscribing to a site a user will get notified of latest activity on that site. Readers: Commentor: Owner/Author

Activity Feed

We want to bring back Feeds. Problem Solution API Support

Revocation of Permissions

This is a WIP document. It's related to the user story of  . Problem Solution Rabbit Holes

Show Document discussions in the document content

users want a way to show a list of discussions in the document content

Add steps to the Wordpress importer for long repositories

TBD 

Email Notifications for site owners

Problem Solution

Nice OGImage tool we can try (steal)

I found this on X today: https://ogkit.dev/home and I think this is a cool idea we can steal:

What is the Side Panel?

Is the Side Panel another Window View?

Evaluation of `What's New!` and `Discussions`

Story: Stories Personas Customer Journey Principles Ideas HMWs Burdi Why communities are hard to bootstrap?

Discussions: Threads vs. Chronological Order

We've been discussing a lot the need for having Activity panel and Discussion panel, whether having both makes sense. My main argument for why it is necessary is that comments in the Discussion panel are grouped by threads, which makes it hard to stay on top of things on a regular basis — new replies can occur in any thread, so you basically have to re-read all the conversation to see what's new. On the Feed panel though things are linearized and presented in a chronological order, which makes it much easier to see what's new. It's true that the current implementation of the Feed lacks a lot of UX niceties, and especially more context for comments. For example when you see a reply in the Feed you never know what it's replying to, and it's not easy to go to the context either, because there's no button for that. Main point is that to stay on top of things regularly it's much easier with a single chronological view. Nevertheless, we've been discussing merging Activity and Discussions again into a single panel. Some systems like Linear and GitHub do that, and it seems to work for them. This screenshot from Linear shows how an activity event of creating an issue is mixed with comments. Comments are still grouped by threads in Linear, although it's not shown on this image, but both Linear and GitHub show the activity events in a much more discrete way than comments, which is nice. Linear screenshot showing how comments are mixed with other activity events So, when comments are grouped by threads, the chronological order of events is broken. I couldn't easily produce this situation in Linear, but the following sketch demonstrates it. You can see how a reply happened 1 minute ago appears before an older priority change event that happened 1 day ago. Sketch showcasing how replies grouped by thread break the chronological order So, this situation makes it very hard to keep track of things when you do it on a regular basis. I guess we don't suffer from that in Linear that much, because they have an Inbox. They also have introduced the new Pulse section, which let's you see what's new in a single linearized list. But in Seed we don't have Inbox (yet), and the current implementation of Feed is very helpful already to stay on top of things. Now, if we thing about merging activity and discussions like Linear and GitHub, we still debate how to group discussions there. One idea that I wanted to showcase (and I was coerced to write this document for it 😆) is the way Fossil does it: it lets you group forum discussions by threads, or chronologically — you can choose. By default forum messages in Fossil are grouped by threads: Fossil threads But there's a button to view them in chronological order in which case all the comments are linearized and sorted by time: Fossil chronological view So, maybe we should do something similar? We could merge activity and discussions into one view, add some filtering options so people could hide events they are not interested in, and they could choose if they want to see discussions chronologically or grouped by threads. You can play around with forums in Fossil here: https://fossil-scm.org/forum/forum. Actually, I do encourage you to play around. They have a few nice ideas. Fossil forum main view And when you click on a thread, it automatically brings you to the most recent comment, regardless of where in the hierarchy of comments it is (it may not be at the bottom of the page if it's a reply). As it's shown in the image bellow, the most recent comment is number 13, and it goes before number 10 in the list. And of course you could go up and choose to display the discussion chronologically.

Ben Horowitz’s Good Product Manager, Bad Product Manager

Source: Patton, Jeff; Economy, Peter. User Story Mapping: Discover the Whole Story, Build the Right Product . O'Reilly Media. Kindle Edition. Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers. Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders. Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps. Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something. Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings. Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test. Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are. Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate. Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer. Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality. Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough. Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company. Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.” Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once. Good teams obsess over their reference customers. Bad teams obsess over competitors. Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when they finally release something.

Deploy a Seed site on a Server with Coolify.

I bought a new server where I installed an instance of Coolify. I have a couple other things I wanted to try with, but I wanted also to migrate my site to it. I tried multiple options to make our site architecture to work inside Coolify but with no luck. I guess there are a couple of collisions between the tools we use and the ones that coolify has. It would be great to have it so I can do a tutorial about it.