Live data from Hacker News

Enhancements to the Kagi Search Experience

blog.kagi.com

151–160 of 168 posts

Re: Enhancements to the Kagi Search Experience

#151
post #13

Unfortunately I stopped using Kagi just due to it not being worth the money for me personally. But look at the company using bearblog.dev, that's awesome. bearblog.dev remains one of my favorite services I've found through HackerNews.

Same here. Too expensive after the pricing change and their browser is irredeemably buggy. I gave them a chance. On to neeva.

Not sure how orion is related. You can still use kagi search (or neeva) with any browser ...

I've rage quite Orion a couple times. But I keep going back. Some of the features are great. I use multiple browsers anyway so I'm ok with using Orion for the bulk of my browsing, then using other browsers each for certain sites or for certain uses. I'd love to work for them but I don't see a viable business model.

My SO uses multiple browsers as well although I can't make head nor tail what their "strategy" is for choosing. I doubt that having to switch up browsers is acceptable for the public at large.

I imagine there's a /reason/ you were using kagi, and that reason is probably privacy related? Why then would you use neeva as an alternative? Started by ad execs. There is zero chance neeva has your privacy in mind, no matter what they say about it. They are focused on pushing consumer products. This requires user profiles.

Re: Enhancements to the Kagi Search Experience

#152

Earlier quoted context omitted.

> How would you change the wording to make this clearer in a way that does not strike you as dishonest? I don't necessarily agree it's dishonest, but I think it's a bit weird to have a pricing tier than effectively doesn't work for anyone who would pay for the service. As you said, almost all Kagi users are not in this 99% of users. Having a plan that caters to these users probably doesn't benefit many people in that…

> but I think it's a bit weird to have a pricing tier than effectively doesn't work for anyone who would pay for the service. When we had only the $10 plan, we were getting messages from users that that plan is too pricey for them when they don't search as much. Hence the $5 month and now about 5% of our users are on this plan. (and Kagi still has zero marketing spend). You have to start somewhere. This gives us an o…

I don't know your unit economics (but they sound fascinating), but generally free trials are considered a marketing expense and would be worked into the CAC (customer acquisition cost). Then you can trade-off CAC with lifetime value (LTV) and a target payback period – i.e. the break-even period.

Let's say a search costs 1c, the free plan therefore costs $1. With a 5% 30d conversion rate that's a $20 CAC. On $10/m for 700 searches, that's just under 7 months to pay back which is quite long, but drops to just over 3 months if users average ~400 searches, so I can see why you don't want to roll over.

That said, if you believe you have a big LTV/long retention, retained users past their payback period should be more than enough to pay salaries/R&D/etc, so maybe there is more flexibility.

> Selling product at cost or below is something VC funded startups can do, which we are not.

I know it often feels like this, but I think the answer is more complicated. It's often hard to know what cost actually is – when you're hiring, growing, and selling a service running on tech that is hard to price.

I'm interested in how you know your cost per search at such a level of precision. It suggests to me that either you've done _way more_ work measuring it and optimising your infrastructure than I expect for a company of Kagi's age, or that it's a fairly naive number (understandably so!) based on dividing infra cost by number of searches. If it's the latter, are there economies of scale that significantly change the number if you have, say, 10x or 100x the user base?

Re: Enhancements to the Kagi Search Experience

#154
Sorry to hijack this thread but does anyone know a project that indexes webpages as I visit them in my browser? I revisit a lot of sites often and would like a private search engine that can search the content I have previously visited.

I'm downloading and rendering the web page on my browser anyway, so it seems like a giant waste not to index it while the page is open.

Re: Enhancements to the Kagi Search Experience

#155

Earlier quoted context omitted.

> but I think it's a bit weird to have a pricing tier than effectively doesn't work for anyone who would pay for the service. When we had only the $10 plan, we were getting messages from users that that plan is too pricey for them when they don't search as much. Hence the $5 month and now about 5% of our users are on this plan. (and Kagi still has zero marketing spend). You have to start somewhere. This gives us an o…

I don't know your unit economics (but they sound fascinating), but generally free trials are considered a marketing expense and would be worked into the CAC (customer acquisition cost). Then you can trade-off CAC with lifetime value (LTV) and a target payback period – i.e. the break-even period. Let's say a search costs 1c, the free plan therefore costs $1. With a 5% 30d conversion rate that's a $20 CAC. On $10/m for…

The answer to the questions is long, nuanced and interactive. I'd be open to explaining it in a more interactive environment, for example our Discord server. kagi.com/discord - feel free to ping me there @VladP

Re: Enhancements to the Kagi Search Experience

#156

Earlier quoted context omitted.

Having a low entry is very important to get new users on board. But the included searches of 200 in the standard plan is extremely low. Even a normal user will hit this limit quickly (if not, they are not your target group - or why should they consider paying for a search engine anyway). This makes the standard plan absolutely unattractive even for non-tech-savvy professionals. But the professional plan also only off…

Thanks for constructive feedback. > But the included searches of 200 in the standard plan is extremely low. Even a normal user will hit this limit quickly They will not, a 'normal' user searches only 100 times a month. > (if not, they are not your target group - or why should they consider paying for a search engine anyway Because they want higher quality search experience, have their privacy respected and/or do not…

> Because they want higher quality search experience, have their privacy respected and/or do not like the entire order of things on the web where they are constantly being the product.

I really wish it would be that way. But from my personal experience non-tech affine people don’t care about privacy or ads that much (as long as it’s free). Just take my wife and father-in-law as an example: They have Google as their startpage in the browser. And instead of directly typing the URL into the browser bar, they will always do a search for it. I told them so many times, but they literally don’t care. And they are not completely wrong since it works for them. 99% of the time Google will return what they are looking for within the first result. No chance I can convince them to suddenly pay $5-10 for the same thing.

Re: Enhancements to the Kagi Search Experience

#157

Earlier quoted context omitted.

You can POST it, and some privacy oriented web tools do that instead of GET, but the reason, as explained elsewhere, is not to hide it from NSA (GET parameters and POST are equally easy/hard to intercept), but to protect against other persons who has access to ones unencrypted computer (spouse, kids, colleagues).

That'd protect against other people who have access to the computer but not the technical skill to install any kind of logger. Couldn't you also just open an incognito window?

I'm not suggesting it is a good idea, or necessary for Kagi or anyone else to do it.

I'm just explaining the reason why some does it and saying it doesn't help against intermediaries who can eavesdrop.

Im fact I think I was tempted to write my exact thoughts about it yesterday but dropped it.

Re: Enhancements to the Kagi Search Experience

#158
post #122
post #97

Many talk about the pricing, but for me the value of having a working (unlike DDG) search engine that doesn't secretly think it knows better than me (like Google) is worth everything I pay now. Internet is I guess, next after a working computer with a working dev environment, the thing that makes most difference for many of us developers. For me it has value in two different ways: 1. time saved by arriving at the cor…

Have you tried asking ChatGPT? That’s where all my technical questions start these days. In the past few days it’s helped me with a bunch of k8s stuff (“explain this coredns log message”, “give me the kubectl command to show all events sorted by most recent first”, etc…)

Yep. I have started to like it a lot.

Lately I have started using https://labs.kagi.com/fastgpt as well, which seems to be more up to date and less censored.

Re: Enhancements to the Kagi Search Experience

#159
I will throw this on the table (and quickly hide my hand behind my back):

If the price model (IMHO correctly) is connected to the actual costs of the search, why not make a "searches account"?

You pay 5$ per month as a "baseline" and each first of the month 200 searches are credited on your account.

Then, if you use less than 200 searches, at the end of the month you have a credit that goes over to next month.

If your credit goes to 0 within a month, you can buy "packets" of searches, 5$ for 200, 10$ for 500, or something like that, and recharge your account.

Re: Enhancements to the Kagi Search Experience

#160
post #77

Earlier quoted context omitted.

I hope you are measuring and attributing churn to its causes.

We are zero telemetry. Luckily our users are very vocal :)

I applaud your privacy stance, but you might want to implement minimal feedback mechanisms, because you are not going to hear from people who leave.

Early adopters tend to be more vocal. If your product becomes successful, you will have to satisfy less vocal, regular users.

Post reply on HN