Interesting article and rationale. I was particularly struck by this, which I've seen happen but haven't understood it in these terms until now:
> We’ve seen more than a few companies raise millions of dollars in funding, go out and hire an army of people in an attempt to grow faster. However, unlike most other software products, search tech is an inherently hard thing to get right. It requires a lot of tedious R&D iterations over long periods of time and it cannot be parallelized by having X number of people working on it in parallel.
> When a large team congregates around work that cannot be parallelized, we’ve observed that new work gets created to keep everyone busy - new nice-to-have features get worked on. This ends up adding complexity to the product. New team routines are invented because there’s bandwidth available. This ends up adding communication overhead and layers between users and builders and slows down the pace of innovation. This sadly becomes a vicious cycle that dilutes the core product.
(I'd go further than "diluted" - sometimes the essentials of the core product remain broken for years because all the energy goes to managing those side features, even though they don't work properly with a broken core.)
There are just the two of you working on typesense right? Surely having some more people working on the core product (up to five?) should help, no?
I'm also building an Algolia alternative, with three engineers including me working on the core engine, and sometimes I wish I had one or two more.
> We’ve seen more than a few companies raise millions of dollars in funding, go out and hire an army of people in an attempt to grow faster. However, unlike most other software products, search tech is an inherently hard thing to get right. It requires a lot of tedious R&D iterations over long periods of time and it cannot be parallelized by having X number of people working on it in parallel.
> When a large team congregates around work that cannot be parallelized, we’ve observed that new work gets created to keep everyone busy - new nice-to-have features get worked on. This ends up adding complexity to the product. New team routines are invented because there’s bandwidth available. This ends up adding communication overhead and layers between users and builders and slows down the pace of innovation. This sadly becomes a vicious cycle that dilutes the core product.
(I'd go further than "diluted" - sometimes the essentials of the core product remain broken for years because all the energy goes to managing those side features, even though they don't work properly with a broken core.)