The downgrade path is the one-way door

This repository has no source in it

The About section says it plainly: this is the official repository for reporting bugs or asking for new features. That is the whole scope. The file list backs it up. There is no src directory, no C# file, no build project, and no licence file, only a docs directory, a documentation converter directory, an Azure Pipelines configuration, an IDE settings directory, one image, a plugins manifest and the README. So the usual first question about an open source project does not apply here. You cannot read the code, you cannot build it, you cannot host your own, and you cannot tell from the repository which system APIs it touches. What you get instead is a vendor relationship with unusually well-signposted support channels: a Windows Store listing, a support email address, a Discord server, a wiki, a blog, a YouTube channel, a Twitter account, and an issue tracker with a template. The licence field is unrecorded, which is consistent with a repository that contains no code to license. For an evaluation, that means you are assessing a product, not a project.

Nightly is daily, and Stable is behind a reinstall

The downloads section is the most operationally important part of this README, and one sentence in it should decide your adoption. Nightly versions, previously called Alpha, are updated daily and, in the README's own words, most likely to contain bugs. You move to them through Settings, then System, then Updates, then Release feed, then Nightly. The catch comes next: downgrading back to stable through the release feed is not currently supported, and to return to stable you reinstall a stable build. That is a one-way door, and it is a strange design for a launcher, because a launcher is exactly the program you will not want to be missing when your machine will not boot or your desktop is misbehaving. The practical response is unglamorous. Download the stable installer and keep it, or use the portable package on a USB stick, so that the way back exists before you need it. The stable build itself is only offered from the project's own website, and the Windows Store listing is a separate route, so even the stable channel has more than one door to check.

Three package shapes and two architectures

For nightly builds the README publishes a table of three package types against two architectures, and the choice tells you what kind of machine you are dealing with. The Windows installer is an executable, offered for x64 and for ARM64. The APPX is the packaged application format, also for both architectures, which is the shape you want for managed deployment or a Store-sourced install. The portable build is a zip archive, again for x64 and ARM64, and it needs nothing installed, which makes it the sensible choice on a locked-down machine, on a borrowed machine, or as the copy you keep for the way back from nightly. A portable archive for the exact architecture you are on is the direct download, and the URL pattern is visible:

https://download.fluentsearch.net/fluent-search-daily/x64/fluent-search-portable.zip

Note the parallel with the stable channel, where the README describes no package table at all and simply sends you to the website to pick a preferred installer. So the matrix that lets you choose a shape precisely exists only for the channel that is described as most likely to be broken. The compatibility table is short and final: Windows 7 and Windows 8.1 are not supported, Windows 10 and Windows 11 are.

The plugin guide says 3.x and the tags say 1.5.0.x

There is a plugin system, and the documentation for it is a wiki page titled for 3.x. The release tags visible on the repository are 1.5.0.0, 1.5.0.1 and 1.5.0.2, each described as Nightly and dated 2026-08-17, 2026-08-31 and 2026-09-24. Those two numbering schemes do not obviously line up, and the README does not explain the relationship. If you want to write a plugin, that gap is the first thing to resolve, because a plugin written against the 3.x guide may or may not load in the build you have installed. The repository does contain a plugins manifest, which is the mechanism a plugin distribution would use, and that is a hint that plugins are a supported extension point rather than a future intention. What nobody can tell from the repository is the plugin API's stability, the versioning policy, or whether a plugin built for one nightly will keep loading on the next one, given that nightlies are rebuilt daily and the downgrade path is closed. Treat plugin development as depending on a vendor-maintained contract and verify it against an installed build before you invest.

Avalonia on a Windows-only product

The stated stack is .NET 8 and Avalonia UI, in C#, and the compatibility table is Windows 10 and 11 only. That combination is worth pausing on, because Avalonia is a cross-platform interface framework and the product is not. The portability is therefore in the interface layer rather than in the application, which is a sensible engineering choice if the underlying functionality is Windows-specific: window management, shell integration, the list of running applications, and browser tab enumeration are all operating system surfaces that would each need a platform implementation. A cross-platform UI means the interface code is written once and the platform work is isolated, which is a good structure even when only one platform ships. It also means the choice of Avalonia is not evidence that a Mac or Linux version exists, and the README gives no sign of one. The feature description is short and worth reading literally: you can search for running apps, browser tabs, in-app content, files and more, where in-app content suggests searching inside an application's own interface rather than only the files it has open, and the word more is doing the work of a roadmap.

Filing something useful takes two sentences and a screenshot

The README spends more space on how to report problems than on the problems themselves, and the requirements are specific enough to save a round trip. When reporting an issue, state your Fluent Search version and your Windows version, format the report using the issue template, include as much information as possible, and provide screenshots if applicable. When requesting a feature, include a scenario in which the feature would be useful to you, and mockup images are welcome. Both of those are ordinary good practice, and both are worth following because of what they imply about the project. Version numbers are asked for because the answer is probably nightly-specific, which is consistent with daily updates. A scenario is asked for because a feature request without a use case is unactionable, which is a filter, not a formality. And the existence of a Windows Store listing, a support email, a Discord, a blog and a video channel means there are five other ways to reach the same team, so the tracker is the one to use when you want something tracked rather than answered.

Why the open parts are the ones we see

The repository's contents form a coherent pattern once you accept that it is an operations surface rather than a source surface. Azure Pipelines and a documentation converter directory mean the documentation site and the wiki are built automatically, which is why the README can afford to say documentation lives elsewhere and stay short. The plugins manifest exists so third-party plugins can be discovered, which is the one part of the product that has to be open for an ecosystem to form. The IDE settings directory is a leftover, the kind of file that ends up committed and never removed. And the release tags exist for the nightlies, which is why the three most recent tags all carry the word Nightly and cluster within a five-week window, while the stable channel is distributed from a website the repository does not control. None of that is criticism. Plenty of good products ship this way. It does mean the right way to evaluate Fluent Search is to install it, use it for a week, and read the blog, because the repository will not tell you what it does.

Editorial conclusion

Adopt Fluent Search if you want a fast launcher across apps, tabs, files and in-app content on Windows 10 or 11, and if you are comfortable taking a binary from a vendor whose source you cannot read. Do not adopt it in an environment where auditability matters, because the repository contains no source, and do not switch a production machine to the nightly feed expecting a way back. Verify four things first: that your Windows version is 10 or 11, since the compatibility table marks 7 and 8.1 as not supported, which release feed you are on and that a stable installer is saved locally before you move to nightly, which plugin API version your build implements, given the wiki guide is written for 3.x while the visible release tags are 1.5.0.x nightlies, and which package shape you want, since installer, APPX and portable are offered separately for x64 and ARM64. The three most recent releases are nightly builds from 2026-09-24, 2026-08-31 and 2026-08-17, and the last push was 2026-09-24.

Frequently asked questions

Official sources

1. adirh3/Fluent-Search on GitHub
2. Issues
3. Project website
4. README
5. Releases