[Jochim]

I appreciate the response and I'd like to reiterate that I might just not be the right user with the right expectations. Still, I hope it's useful to hear why someone might be on the fence about the product.

> (9 is probably a bug)

To clarify 9, the request is sent when clicking the cross on the Lens > Edit page rather on than visiting it. This also occurs when returning from maps. In both cases a new search is only billed when the cache has expired. Interestingly, from a totally naive user's perspective, maps don't appear to use up a search.

> If you know of other ways to do this, we are all ears.

I don't have an issue with charging for individual searches. On the whole I think it's a reasonable idea. I do think that some aspects of the UX encourage billing superfluous searches and that, on a purely financial level, Kagi is dis-incentivised from improving this.

Taking steps 5 and 6 as an example: there's no reason for these to be separate billable events. When viewing search results the user interface simply doesn't allow the user to select the sort order in the same operation they select the field. I sincerely doubt that this is intentional but it's easy to see the cynical take.

I think there's also a decent case for longer caching of results, giving users the option to refresh results if it's important they aren't stale. This avoids the current situation where a user might spend some time visiting the firsts webpage in the result set, return wishing to continue perusing subsequent results but end up triggering a billable event. The same applies should someone want to swap between web and images.

A quirk I noticed when trying to trigger shopping results was that searching for "best hair dryer" will display the shopping widget whereas searching "best hairdryer" does not, despite "showing results for best hair dryer" appearing as part of the search.

Maybe I'm misunderstanding the feature but searching for variations on "cordless drill", "best cordless drill", "best cordless combi drill", "best cordless percussion drill" never returned any shopping results, should I have expected it to?

To expand on my prior point as to why moving to a total number of trial searches might be harmful to conversions. In evaluating the billing rules and shopping results, I'm now on search 46/100. I haven't yet got into a flow with the product. That might change over the next 50 searches but I still haven't explored: redirects, lenses, personalised results, fine tuning search settings, or just the broader search quality.

[freediver]

> I do think that some aspects of the UX encourage billing superfluous searches and that, on a purely financial level, Kagi is dis-incentivised from improving this.

Kagi is selling searches at cost, and we make money on subscriptions. Making a suboptimal UX id definitely not what we are doing, as people pay us for UX to be optimal.

You point out some valid use-cases there and the reason we haven't addressed them so far is probably because they are rare and users didn't care enough to post and upvote them on kagifeedback.org for it to make a difference.

The one you noted has been suggested actually https://kagifeedback.org/d/844-dont-use-extra-searches-for-c...

and is planned on our roadmap, just not prioritized (just one upvote) and we had bigger fish to fry.

Hanlon's razor in general applies well when thinking about Kagi, expect it is not (always) stupidity but lack of resources.

[Jochim]

> Hanlon's razor in general applies well when thinking about Kagi, expect it is not (always) stupidity but lack of resources.

Please don't feel that I was making any hard judgements about Kagi or yourself based on the points I mentioned. My only intention has been to learn a bit more about the product and provide some insight into what someone evaluating the product for the first time might feel. I appreciate that the points may come across as hostile/challenging but I'd be happiest if they were rebutted easily.

Your present response does raise some concerns however.

> Kagi is selling searches at cost

This is a different claim from your blog post on 08/03/23 where the cost of each search was 1.25 cents. If this isn't the case, you're losing money on any annual unlimited subscribers that make more than 1,416 searches each month.

> and we make money on subscriptions

If this is the case, why not differentiate the subscriptions based on their value-add features and operate an upper bound of $25/mo on the amount charged for searches for all tiers?

If you're making money off of the subscription, why don't the search quotas roll over?

Together, these three points give the impression that the aim is for subscription search quotas to be under-utilised rather than to provide the searches at cost.

> You point out some valid use-cases there and the reason we haven't addressed them so far is probably because they are rare and users didn't care enough to post and upvote them on kagifeedback.org for it to make a difference.

That's a fair point regarding general feedback. I can't speak as your average user but as someone that wasn't already invested in the product they were areas that introduced friction in the decision of whether I'd like to pay for the product or not. A user evaluating the product is unlikely to post why they haven't converted to kagifeedback.org, even if they're aware of the site. It's worth bearing in mind that issues for potential users may not be a problem for existing users, apportioning time to the desires of both groups is a difficult balance.

> and is planned on our roadmap, just not prioritized (just one upvote) and we had bigger fish to fry.

My personal perspective is that it's absolutely unacceptable for a company to double-charge due to their own UI decisions. Spurious billing in general is something I would expect to be treated as top priority on an ongoing basis. Treating it's occurrence as a feature request raises serious concerns, especially regarding how similar/more impactful situations might be handled.

I'm disappointed, there's a lot to like about the product itself.

[freediver]

Great questions!

> This is a different claim from your blog post on 08/03/23 where the cost of each search was 1.25 cents.

Yes, cost of search has significantly increased since. Microsoft raised prices 6x and it is 2.5 cents to do a search with the Bing API alone. We are trying to absorb much of that through creative ways so that users do not see it.

> If this is the case, why not differentiate the subscriptions based on their value-add features and operate an upper bound of $25/mo on the amount charged for searches for all tiers?

Because the cost of all other features pales in comparison to the cost of search. In general if a feature does not costs us anything we do not charge the user for it (example: bangs are free).

> If you're making money off of the subscription, why don't the search quotas roll over?

Two main reasons:

- It means more billing systems to build and we are eager to work on search features like this update

- Something still has to pay for all our additional costs like free trial account searches and salaries

> It's worth bearing in mind that issues for potential users may not be a problem for existing users, apportioning time to the desires of both groups is a difficult balance.

Agreed and it is a matter of product roadmap prioritization. While the issue was previously raised, it had only one upvote. Now that we got more alarming feedback it was prioritized internally and 5 and 9 from your list should be addressed asap (others do not really apply as we do run a full search for those).

> My personal perspective is that it's absolutely unacceptable for a company to double-charge due to their own UI decisions.

I agree with this perspective and as I hopefully explained that was not the intent, but a bug.

[ant6n]

Mmh, so your excuse for using dark patterns that are designed to overcharge users is that not enough of your users have noticed and complained? Are your users supposed to be UX experts?

[freediver]

Our users notice and (rightfully) complain about everything that is not right - because they pay for the service.

My "excuse" for some of these things not being fixed is that they have low perceived impact in practice and/or lack of resources to address all issues at once (hence roadmap).