On this page
Hello everyone and welcome to the February & March 2026 Filen status update.
After the combined December and January post, February and March have also been focused on continued groundwork across several areas. A lot of that work has been less flashy from the outside, but still important: hiring, infrastructure-related tasks, ongoing Rust migrations, smaller fixes, and a few follow-up adjustments based on recent user feedback. So, as usual, let us get started.
Hiring and team expansion
As mentioned in the last few updates, hiring is still one of our biggest priorities right now. We are actively reviewing a very large number of applications through our own internal application system, external job platforms, and now also recruiting partners. That process takes time, and while we have spoken to many candidates already, we are still looking for the right long-term fit for the roles we want to fill. Some applicants have made it beyond the initial interview stage and into coding interviews, but overall this is still very much an ongoing process.
Our main focus remains on experienced full stack developers, especially senior profiles, but the structure of these roles is worth explaining a bit more clearly. The work is more frontend-heavy in day-to-day practice, but it still requires full stack thinking because our apps rely on complex client-side logic and close integration with our SDK and shared application core. In practical terms, we are looking for strong product engineers who can work confidently across client frontend and client-side application logic.
The long-term goal is also bigger than simply filling open seats. We want to build up more dedicated ownership across our products over time. That means finding the right people for the web app, desktop app, and mobile app, with the expectation that some of these hires can grow into future team lead roles as the company and product structure continue to grow.
We know this kind of hiring is not something that resolves itself overnight, but we are continuing the search at full speed. So if you are reading this and you have strong experience with modern frontend-heavy product development, while also being comfortable working with more complex application logic under the hood, we would still very much like to hear from you.

Free account creation changes and the first feedback
Earlier last month, we introduced a change to free account creation and covered the reasoning behind it in a standalone post. This update is intended to address abuse of our service without changing the normal signup flow for most users. New accounts can still be created as usual, but the free 10 GB allocation is no longer granted automatically in every case. Instead, eligibility is now determined during signup based on a one-time automated check of the connection being used. Existing accounts are not affected, and there is no change to encryption, privacy, or general account access.

We have been closely watching the reaction across support and social channels since activating the change, and overall the feedback has been largely positive. Many users understood exactly the point we were trying to make: privacy is a right, but it should not be treated as a free pass for harmful behavior that creates operational, reputational, and accessibility problems for everyone else. That part of the response has been encouraging.
At the same time, one piece of feedback stood out very clearly. Some users who signed up through anonymized connections were frustrated that it was not obvious enough in advance whether they would actually receive the free 10 GB or not. In some cases, users had also not yet seen the original announcement and only noticed the new rule after they were already past the signup flow. We think that frustration is understandable, and that is exactly why we implemented an additional improvement.
There is now a clear eligibility indicator before account creation is completed. It tells users in advance whether the account they are about to create qualifies for the free 10 GB allocation, includes a short explanation, and links directly to more detailed information and a FAQ. The goal here is straightforward: if we make a change like this, then the process should also be as transparent as possible at the exact point where users are affected by it. We will continue to monitor feedback closely and adjust things further if needed.
Referrals and how the (new) system works
Another topic that came up more often after the recent free account changes is our referral system and why some users do not always receive referral storage even if a referral link was used.
For anyone who is not familiar with how referrals work at Filen, here is a quick bit of context.
Filen users can create referral links in their profile and use them to invite other people to the service. Each user can receive credit for up to three successful referrals, and every successful referral adds 10 GB of free storage permanently. On the other side, the invited user can also receive an additional 10 GB when creating an account through a valid referral link. In the best case, this means a user can start with the normal free 10 GB, receive another 10 GB through a referral signup, and then earn up to 30 GB more by inviting three other eligible users. That adds up to a maximum of 50 GB of free storage.
Because of that, referrals have naturally also been a target for abuse for a long time, which is why this system has always had automated protection mechanisms in place. With the recent changes to free account creation, we also took the opportunity to improve the referral logic accordingly.
For a referral to be linked correctly in the first place, cookies need to be enabled in the browser. This uses a functional cookie, so it should still work even if someone opted out of other cookies on the website.
After that, the referral is evaluated automatically and without human review. The system checks the following:
- Whether the registration IP is classified as residential through Ipregistry. If it is not, the referral is not counted.
- Whether the referrer's IP is also classified as residential through Ipregistry. If it is not, the referral is not counted either.
- Whether the referrer's IP matches the IP of the new signup. If both are the same, the referral is not counted.
- Whether that signup IP has already been used for the same referrer before. If it has, the referral is not counted.
- Whether the referrer has already reached the three referral limit. If that limit has already been reached, the referral is not counted.
This system uses the same one time automated network classification logic that we already described for free account creation, which also means that accounts that do not qualify for the normal free 10 GB at signup are not eligible for referral bonuses either. The entire process is encrypted, narrow in scope, fully automated, handled without manual inspection, and not tied to any broader profiling beyond the checks required for abuse prevention. It is also designed to remain GDPR compliant.
When we first implemented the system, there was also a bug that caused some valid referrals not to go through, but we have since fixed the issue and will continue to monitor feedback and make adjustments where needed.
Development progress, Rust migrations, and smaller work in the background
On the development side, March brought us an important milestone. The Rust SDK is now 99% complete, and as announced, our lead Rust developer has now begun the sync engine rewrite while the remaining client migrations continue in parallel. At the moment, the mobile app remains one of the main migration targets. Tests are going great, and we expect the first internal beta version soon.
Most of this work remains primarily foundational. It is not always the most visible part of development from the outside, but it is exactly the kind of groundwork that improves consistency across platforms and makes later steps on the roadmap much easier to execute. The goal of the sync engine rewrite is to make synchronization more reliable, consistent, and predictable in everyday use, with better handling of real world edge cases, more robust conflict resolution, and clearer rules for how and when changes are applied across devices. The new mobile app update, built entirely on the new Rust SDK, will deliver a significantly faster and smoother day-to-day experience. It also addresses many edge-case issues that we identified and resolved over the past few months.
Although the current TypeScript SDK-based app has not received an update for some time, we have carefully tracked all the issues you reported and worked to resolve them in this upcoming release.
As usual, not everything over the past two months was perfectly linear roadmap work. Some additional infrastructure-related tasks came up, and there were also smaller fixes that needed attention along the way. That is just a normal part of operating a live product while also trying to move larger internal projects forward in parallel. Overall, the picture remains positive: the Rust foundation is now in place, migration work is progressing, and the broader technical direction remains unchanged.
One smaller project worth mentioning here is Filen Relay, which one of our developers has been working on as a side project and which is still in active development. Filen Relay is designed to provide a convenient way to serve the Filen Drive over protocols like WebDAV, HTTP, FTP, and SFTP, with a web interface to start and manage multiple servers, control basic permissions, and inspect logs. It is still very much a work in progress and not something we would recommend using in production at this stage. For now, it should be seen as an experimental project that is mainly suitable for testing and early development purposes.
If you'd like to take a look at it, here’s the link to our GitHub:
Given its current stage of development, please don’t use it with any data you can’t afford to lose. You've been warned.
Customer satisfaction survey
Another thing we want to mention briefly is that we are planning to run a broader customer satisfaction survey again in the near future, which we will publish separately once it is ready. While we already read a lot of feedback through support, social media, and other community channels on a daily basis, we feel it is time to step back and gather a more general and structured overview again. Direct feedback like that is valuable because it helps us better understand where things are going well, where expectations may be shifting, and which areas need more attention from our side.
More broadly, we are also always interested in ideas on how to improve communication and the general exchange of information between us and the community. That includes not just feedback on the product itself, but also thoughts on how updates, announcements, and discussions could be made clearer, more useful, or easier to follow. As soon as everything is prepared, we will share more details in a separate post.
Closing words
We hope you enjoyed this update.
The last two months have been defined more by continued groundwork than by headline-grabbing releases, but those quieter phases are often the ones that matter most later. Hiring is still moving forward, the recent free account changes have now received their first real-world feedback loop, the new sync engine rewrite is on its way, and the Rust migration work continues in the background.
As always, thank you for your support, your patience, and your trust. We will keep building carefully, keep communicating clearly and frequently, and keep making decisions that support Filen in the long run.
Until the next update,
Team Filen

