probst

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.

Heh, nice app! I'll check it out!

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?

Do you have concrete examples?

Awesome, thank you!

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...

Thanks!

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.

[0] https://monocle-search.com

[1] https://searchcue.com

[2] https://github.com/quickwit-oss/tantivy

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.

In case anyone is interested: https://github.com/sebastian/pi-extensions/tree/main/.pi/ext...

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 :)

The problem has now been fixed. Fields can be emptied properly, and the TER (decimal values) are editable too!

Thanks again!

You are absolutely right! Thanks for letting me know! I’ll look into it when I get home!

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.

An incredible level of polish and ease of use.

I am not sure what your background is, or whether you are, or have worked as, a freelancer. What I am writing might therefore be old news to you, in which case it would still be interesting to hear how you are thinking about the numbers I'll present.

A lot of people write comments such as yours. 11000USD/mth is a very decent salary if you are an employee. What most regular employees completely discount when doing back of the envelope calculations about the salary of other people are the amount of additional contributions that are made by your employer that regular employees might never see, but that are paid for you all the same.

Here is the math for me as a freelancer in Germany, with a similar salary as the one you are claiming is outrageous.

I bill roughly the equivalent per month from Berlin in Germany. I am not sure where the Babel developers are based, so their circumstances might differ, but all the same, here goes:

Of the 9000EUR (11000USD in EUR) I have to pay: - 19% VAT = 1750 - 950/mth in health insurance - Put aside 1000/mth for retirement (which is less than I previously had from my employer) - Set aside money for vacation (as a regular employee in Germany I would have 30 days paid vacation, as a freelancer I had to set aside roughly 600/mth to compensate for this) - Set aside money in case I get sick (as a regular employee I still get my salary when I am sick, as a freelancer I get paid from day 45). I set aside roughly 450/mth for this. - Then there are miscellaneous freelancer related expenses and having to buy hardware (which your employer would cover too). Let's make that 300/mth. - Then there's income taxes on the rest. This differs from jurisdiction to jurisdiction, but let's make it an even 30% (which is below what I pay).

This leaves me with 3950 before taxes, or 2765 after taxes... That doesn't sound so amazing anymore, does it?

Even if the Babel guys aren't working as freelancer but pay themselves through a company, the math works out roughly the same (at least from what I have seen in my own business over the last 9 years). The only difference is that the company needs the equivalent monthly budget instead of the individuals.

I have exactly the same need (and problem too)! I'll monitor this thread and see if anyone else has any solutions to this.

I really would like not to have node running on my server in order to get SSR! Which effectively means I'll either have to serve entirely static pages and then hydrate them based on some model client side (which isn't server side rendering by any definition of the term), or I have to recreate the entirety of the HTML rendering functionality for my server side in my language of choice. I guess there might not be a way around the second option?

Hehe, shame this got down voted so much. It's actually a pretty hilarious Erlang joke. They made a video way back showcasing Erlang in the setting it was primarily used: telecom systems. In this video they keep calling and greeting each other. The video can be found here: https://www.youtube.com/watch?v=uKfKtXYLG78

Except you have to be careful so the monthly amounts don't end up so small that the credit card processing fees eat up the majority of your donation! The processing done via Stripe (which is used by Donorbox) has a fixed minimum fee of 30 cents per transaction.

Edit: unless they have some special lower cost stripe rate of course, in which case you can ignore my comment altogether ;)

Recurring and steady incoming is certainly useful for any company, but I would advise against doing tiny monthly donations over a larger yearly one! Processing fees are going to take away a significant chunk of your total donation relatively speaking if your individual donations are small.

Let's do some math: In signal's case, since they use Donorbox, there is a 2.9% + 30¢ fee for credit card transactions going via Stripe (in addition to another percentage that goes to donor box). If you were to donate $24 once per year, Signal would end up with just over $23 after processing fees had been deducted. If you donated $2 per month, they would end up with $19.7 per year, an additional $3 being spent on fees!

Edit: unless they have some special lower cost stripe rate of course, in which case you can ignore my comment altogether ;)

There is actually a very good reason to drop these email addresses, and the reason is that a high-rate of non-deliverable emails hurt your sender score. It's a total pain to get emails delivered to the major email providers in the first place, and you immediately land in spam (or with emails not delivered at all) if they don't trust the sending email server or your score is anything but stellar!

The irony is that you can now often recognize sites being designed with Tailwind the exact same way. They tend to use a certain font, they tend to slightly overuse the card metaphor with a rather specific corner radius and box shadow...

When looking at this site I immediately though: aha, this guy has been using TailwindCSS to design the website... (until I realized that in fact yes, it was designed with Tailwind and the author is also the author of tailwind itself.)

So I guess it's the same as bootstrap at the end of the day. Both provide you with options to customize them. Most people don't.

That being said: Working with tailwind is amazing!

Just a heads up: I tried leaving some feedback using the "Give Feedback!" link at the bottom of your site. Submitting the feedback resulted in a 500-error.

You _can_ negotiate with tech transfer offices, but it might not lead to much.

We have been fighting with ours for ~8 years now. The terms keep getting worse. I think all told, and if I were to repeat it, I would certainly scrap the IP I made in those early days and start fresh when starting the company. Like they mention in the article, chances are you'll pivot a number of times anyway, making the IP largely irrelevant, but you'll still have given up significant equity for it, and likely have a difficult shareholder onboard for life.

(edit: at least this is my anecdotal evidence, and what I gather from some other people having interacted with my particular tech transfer office...)

Which is why GDPR, although theoretically a good idea, is pretty much useless in practice.

This is very much not true. GDPR isn't restricted to regulating tracking on websites. It also restricts and regulates what companies can do with the customer data they are in possession of. Through my day job I constantly interact with large enterprises (Fortune XXXX) that have vast amounts of personal data through their regular operations (banks, telcos, car manufacturers, airlines, insurance companies and the likes). Nearly without exception they go to great lengths to ensure the data is managed correctly, not used for purposes the customer hasn't explicitly consented to etc. This is as a direct result of the GDPR.

We use a small slack bot I developed called the watercooler [1]. It pairs us up two and two for short non-work related chats. Helps break the monotony and isolation of the home office

1: https://watercooler.site

I went from Haskell to F# too. For more or less the same reasons you outline. Better and more consistent tooling. Significantly easier debugging. Not all the benefits of the Haskell type system sure, but enough of them to make classes of errors vanish and programming a joy. A welcoming and friendly community looking to solve problems and build things is also boon (the open source community around Fable is one example).