A little over a year ago, we made a decision that wasn’t easy: instead of continuing to add layers to the app you’ve been using for years, we were going to build a completely new one from scratch. Taking advantage of a short summer break, I wanted to tell you why, where we’re headed, and what technology is behind that decision.
Our motivation came mainly from listening to you. We conducted a survey to get a better understanding of what you truly value about FacileThings, and the overall response was quite clear: adherence to the GTD method and the feeling that this was a tool specifically designed to implement it effectively, without having to build your own system from scratch on top of a generic app. But you also told us, just as clearly, where the friction points were: an awkward mobile app, a somewhat outdated and cluttered web interface, and processes that required too many clicks to do something simple.
We came to the conclusion that we should keep the GTD structure intact, but redesign a significant portion of the interface.
At the same time, a series of specific circumstances arose, which also pushed us to make significant changes. The provider that supported our mobile app ceased operations, leaving us with no room to continue evolving. The technological infrastructure we had built up over the years had become outdated, and it was becoming increasingly difficult to maintain, adapt, and scale it. Moreover, infrastructure costs had risen to the point where continuing to patch the old system no longer made sense, neither technically nor financially.
Rebuilding the application from scratch, with an architecture designed both to significantly improve the user experience as well as to facilitate innovation, seemed like the most reasonable solution. Shifting to a local-first architecture is the most significant technical decision we’ve made in FacileThings’ 15-year history.
What exactly is “local-first”?
Most apps in the cloud work by requesting permission and information from a server—which can be located anywhere in the world—for every action the user takes. You save a task, the operation is sent to the server, you wait for the response, and you see the result. Every data exchange generates a brief delay, which results in loading indicators everywhere: animated icons spinning until the response arrives, loading skeletons simulating data until the actual data arrives, and so on.
In a local-first app, a complete copy of your data is stored locally on your own device, so that all operations (creating an action, completing a project, or clarifying an item in the inbox) take place on that local copy. The result is virtually instantaneous interaction, indistinguishable from a native app, and the ability to keep working even if your internet connection is lost, something that simply wasn’t possible in the classic version of FacileThings.
The component that enables the “local-first” approach is the synchronization engine, a piece of software that runs in the background and keeps your copy of the data on your device in sync with the copy stored on the server, even when you don’t have an internet connection. The synchronization engine is responsible for sending changes to the server and retrieving updates that have occurred on other devices, ensuring that both copies remain identical.
Although the local-first architecture has existed conceptually for some time, it has only become practical in recent years thanks to the evolution of browser storage APIs and the emergence of new tools that simplify data synchronization. By allowing data to remain on the client device and synchronize with a server or other nodes only when necessary, local-first applications can deliver a fast, reliable, and privacy-friendly user experience.
The technology behind it
On the front end, we’ve opted for React, React Router, and Vite. The component that enables the “local-first” behavior is Replicache, a software that manages the local copy of data and handles synchronization with the server optimistically, meaning it applies your changes immediately locally, and reconciles them with the server later. The backend remains a Ruby on Rails server that stores all the business logic and accumulated knowledge about GTD, although communication now takes place through an API optimized for sharing data with the new synchronization engine.
This synchronization engine has been, by far, the component that has required the greatest amount of engineering work on our part. At first, it worked well, but as we began incorporating beta testers with real-world data, some with many thousands of items accumulated over years of use, we started encountering use cases where performance degraded to an unacceptable degree. We’ve redesigned and optimized entire sections of that engine more than once to ensure it remains fast no matter how much historical data you carry with you.
One single code, many entry points
This architecture has an additional advantage that is essential to our vision and long-term sustainability. By separating the application’s logic from the device on which it runs, the same code that runs in your browser today will serve as the foundation on which we will later build desktop and mobile applications, without having to rewrite the product from scratch again. The idea is to build a single system and multiple ways to access it, all synchronized with each other in real time.
That same architecture also opens the door to something that still seemed far off just a year ago: the possibility of AI agents working directly within your GTD system. It’s no coincidence that, alongside the development of this new app, we’ve started building an MCP server that allows models like Claude or ChatGPT to capture, clarify, and, in the future, help you with your weekly review, by speaking the same API language that powers the app.
What’s Next
The new app is currently in beta with invitation access, but it will be fully open next month. It covers the entire GTD workflow (capture, clarify, organize, review, and act), but some important pieces are still missing: the weekly review, routines, and, later on, the packaged versions as mobile and desktop apps that I mentioned earlier.
We’re releasing a new update every week, and we’ll keep doing so, fine-tuning each feature based on your feedback, until this app truly becomes the best way to implement GTD that you can have.
No comments