Yes, I was so close to signing up for a pro account to get some inmail credits to be able to write someone directly, but then I decided to try writing here first lest I be stuck in a pit of dark patterns trying to cancel my subscription. I would however have been my next step.
I finally heard back! Thank you! I think this thread might have helped!
And I totally agree with your thoughts on the criticality and inadequacy of AI replies in such a context! Lack of answers was holding a months worth of income hostage with no real recourse for us other than trying to be loud online. Kind of sad.
Looking at alternative merchant of records now to buy us some optionality.
Taking a peek at the repo and the local first data layer issue (https://github.com/bartblast/hologram/issues/940) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption?
How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compile to and use the automerge js libs in the browser, and deal with automerge through a NIF server side? Ok, not knowing your implementation and plans, I have to confess I am talking a bit out of my arse here...
Exactly, or rather, the social habit part I agree a 100% with. I don't want to train myself out of being a polite human being, just to save some keystrokes.
I certainly say please and thank you. Whether or not it makes a difference to the LLM, it makes a difference to me. I want to retain some humanity and politeness in my own behavior, even if I spend an inordinate amount of time communicating with, instructing, and debating a non-sentient piece of code.
I'm all for word of mouth and things radiating out, but doesn't that need some viral factor of sorts that makes the product one that's shareable? We have customers raving about our product actually, and saying they would be incredibly sad should it go away, but are struggling to leverage that into further sales...
Affiliate marketing _does_ work to an extent, and is a kind of rideable wave I suppose?
Thank you for your thorough reply! I think we should give it another go and be more restrictive in targeting!
Speaking of paid ads: we tried google, bing, LinkedIn in the past. Do you have a preferred place that you recommend that you have seen better performance at than other places?
Ah, the research angle is good! And my take-away from what you write is mostly the need to be visible, in whatever form, be it in the users communities, or otherwise?
We have excellent feedback from the users who do find us, so there is product market fit for the subset of customers that have a need for our product strong enough to actively search for it, but maybe that's an issue in and of itself: the fraction might be too small, and furthermore, for the (hopefully) larger segment of the user base that don't have a need strong enough to actively go looking, we need to be sufficiently visible for them to chance upon us...? which I guess drives home the message even more that visibility is key...
Long story short: Meilisearch is a very good search application for sure, but our needs drifted apart.
Longer version:
Our usecase isn't entirely aligned with how Meilisearch is meant to be used, I think. For one, we have a very high number of indices (at the time of using Meilisearch we had multiple per site that uses our service) and we wanted to have these replicated to edge nodes we have placed around the globe to keep latency down. In the end I was ending up spending an inordinate amount of time wrangling Meilisearch to get indices up and running across our different edge nodes. And, I am not sure if it was a regression in the last Meilisearch version we used, or user error, but at some point some index creations would just never get done, and would hold up our entire indexing pipeline. So long story short: the amount of effort needed to orchestrate and keep all the individual Meilisearch nodes up to date and in sync just turned out to be too much hassle.
The system I built afterwards works vastly better because it's actually bespoke and tailored to our use case. I can create the search indices on our crawler nodes entirely in isolation, run all sorts of preprocessing and optimizations once, and then just ship the final search indices to all the nodes that then serve them, and as a result I need wastly less computational resources on those edge nodes too, since no actual indexing work ever needs to be done on them.
It also means (double edges sword of course, because Meilisearch already gives you so much functionality out of the box) that I had to re-implement a whole lot of stuff around relevance tuning, snippet generation, ranking, etc, but as a result I have also been able to build interesting functionality than we didn't get out of the box before. And lastly, since the search index is now served as part of our main search node application things also get really fast, as I have no latency whatsoever to speak of going from app to Meilisearch.
We are working on our two site-search search engines Monocle Search [0] and SearchCue [1]. The former is squarely aimed at people using Squarespace, whereas our newer offering SearchCue is aimed at anyone with a site that wants to add search.
We used Meilisearch as the search backend in the beginning but have since replaced it with a quite sophisticated search stack built around Tantivy [2]. We now support crawling and indexing of pages, most common office documents and PDFs, run OCR and feature extraction of images you might have, offer typeahead search with the aim of giving you providing answers as fast as you can type, as well as more classic agentic/conversational ai search.
There have been quite a number of interesting optimization challenges to solve in case anyone is interested. We have search nodes distributed around the globe to provide the lowest possible latency regardless of where the end-user sits.
We are also working on some other smaller side projects, but they aren't quite ready to launch yet.
Or tell pi to add support for the coding plan directly. That gave me GLM-5.1 support in no time along with support for showing the remaining quota, etc, too.
It also compresses the context at around 100k tokens.
I am really curious about LiteSync. Any chance you could share a bit on your experiences with it (recognising it’s somewhat off-topic…). Do you run with multiple primaries? What sort of use cases do you reach to it for? Conflict resolution seems a bit simplistic at first glance (from the perspective of someone very into CRDTs), have you experienced any issues as a result of that?
I am also based out of Germany, and experience the lag too. I find it very annoying actually, to the point where I am contemplating switching. The lag isn't always there though...
Yeah, that is a great idea! I tried building something like that, but didn't quite get it right. Maybe I should give it a second go.
I have also thought about adding a feature whereby you can ask the equivalent of "I would like to be able to pay myself X per month" and then be told how much you would need to bill per month. In a way it's the inverse of what the tool does today.
Thank you for sharing! That is even more strict than what my tool calculates, as in 75% set aside for the future. The exact numbers likely also depend on where you reside, and how much of a social security net exists to catch you when things don't go as planned.