When I started creating Featurely several years ago, I did not plan for it to be this big suite of several tools. It was meant to be a simple application where I could collect feedback in the form of feature requests and bug reports directly from users in my other applications. The usage was not huge, and most of the incoming reports were from myself. But it worked as I wanted and did what I needed it to do.
After a while of using Featurely, I realized that I needed a tool for tracking errors that my users experienced, and also errors that were not caught and therefore never seen by me. The solution was to add an error tracker dashboard and an API endpoint to Featurely so that I could send errors straight into Featurely and get notified in an instant. This worked for a long time, and as I continued adding features to the application, I slowly realized that it had become something different than the original plan.
After adding error logging, I started tinkering with up-time monitoring and environments. The up-time monitor is just a simple cron job on Vercel that pings an added website; there is nothing fancy about it, but it does the job. I get notified when something goes wrong with either the main systems or any of its dependencies. Environments are my take on creating a divider between what I want to track and what I want to let slip past. The reason for this was that while an application lived on my localhost and I did some work on it, something usually went wrong in the process. This meant that an error was added to the Featurely Dashboard, even when it was a small coding error on my end on localhost—a false positive, so to speak. To avoid this, I created environments where I could manually add the URL and then turn on and off error-tracking. The system worked well, and since the filter is in the API route, I did not have to change anything in the application itself.
The only issue I had with environments was that I had to add all the URLs manually; that meant adding localhost, Vercel links, production, test environments, etc. The solution I added was to automatically detect if an environment already existed, and if not, allow the system to create this environment by itself. With this method, the environments just magically showed up after a little while of playing the waiting game. The environment system was later supplemented with support for analytics, the built-in debugger, and support for environment-specific API keys, as well as a blacklist for stopping auto-creation of unwanted environments like .vercel.app, etc.
I later added support and features for a public dashboard, changelog, roadmaps, and tasks. These were systems that fitted into the idea of adding a public dashboard where users could monitor the application's development, add features and bugs, and see planned features on the roadmap. It also allowed the users to track what features and updates had been added using the changelog. It was after adding support for these features that I got the idea that maybe someone else also was looking for a system like this, and that Featurely could be useful for someone else besides me. It did not materialize into something until later, but the plans were made, and I started working on some of the features like the SDK packages.
While planning the SDKs, I launched my own company working as a bike mechanic. I had created a webpage for it, and as everyone else is about their projects, I was wondering if the page got any views, how long they stayed at the site, and so on. I could add systems like Google Analytics into the page, but I already had Featurely that could do most of what I needed, so I opted for a solution where I could keep everything in one workspace. Analytics was added into Featurely, and it quickly evolved into what it is today. I am still working on it, and it is not perfect, but it works as an entry-level analytics and insight tool for keeping track of what my users did and how they did it.
At the same time, I updated the error-tracker to not just keep track of simple error logs, but also include stack-traces and breadcrumbs. This made monitoring payment errors much easier while testing different payment options for my bike service shop.
Another side-effect of the bike shop application was that I added feature flags to Featurely. Using this system, I could easily decide what features on the bike shop page were live, how many of my users saw the different buttons, and so on. This was a great help in deciding what worked and what did not work in the process. As an example, I tried out different payment partners and figured out which partner offered the lowest-friction approach for my users. I also added my first 'SDK', the feature reporter package. This offered an easy way to add a customizable widget to my bike shop page where users could report bugs to Featurely directly from the bike shop page. This meant that I could get feedback without my users even leaving the page.
I also started on the translations feature in Featurely. It was originally planned to be a feature of the bike shop page, although I later figured out that it didn't need any translations. But the system was built, and I have since used it in other applications.
The translations feature loads the translation keys from Featurely and stores them in local storage for the user. This means that after the initial load, it is available in an instant on the next visit or refresh. The system will at the same time send the cached state to the API, and if it returns a 304, it drops without any more data transfer. If something has been changed, it will download and refresh the cache.
It is also without a doubt a pain to remember all the keys added in a project, and often some keys can be overlooked. Therefore, I have added an auto-key addition feature in the translations features. This feature will add any missing keys to Featurely and show a notification on the keys that are missing any values. This way, you can publish the app and if you missed something, fix it directly from Featurely. It also has support for pluralization and namespaces.
Next in line was the Maintenance mode. As a part of the bike service shop, I noticed that in a small percentage of changes, I could use a maintenance mode, meaning that users visiting the page would be met with an "Under maintenance" message. Mostly this was when I was running payment tests in the production environment and had debuggers, etc., live on the page for logging.
The site-manager package does this for me and allows me to turn on and off maintenance mode directly from Featurely. It also features a built-in debugger with logging, network traffic, and more in direct relation with the Featurely packages. This one was built to allow for better debugging and troubleshooting of the now several Featurely SDK packages that I could install.
While working with both Featurely and the bike service shop in my free time besides day-to-day work, I quickly realized that dependencies that I had installed had a fast update rate. This meant that I quickly fell behind on their versions and ran outdated code. To mitigate this issue, I created a package and security monitor in Featurely. These two features work in tandem, where the package monitor scans the installed package (You can scan packages from cmd or by adding an action to git) and shows outdated packages, gives me cmd commands for updates, shows breaking changes (as dumb as major version checks so not overly complicated), and allows me to see the package versions directly in a dashboard. This meant making the process of keeping track of versions, what I have installed, and updates much easier.
As an evolution of this monitor, I added the security dashboard as well. This dashboard allows you to scan your page to check security headers, SSL / TLS for all sites in the uptime monitor. This will get an update in the future to enable a blacklist for pages in the uptime monitor that you don't need to scan. The security scan will also check dependencies for security issues checking the OSV vulnerability database utilizing the package dependency scan feature.
Why version 1.0.0 now?
I see that Featurely is evolving quicker than I thought it would, and for me and you to be able to keep track of updates, I needed to add a versioning system to it. The best place to start for Featurely is at v.1.0.0, as it is currently a working product. This will allow me to add versions to changelogs, news, and blog posts for better tracking. This will also in the future allow me to release new versions to only a selected group or a percentage of the users instead of releasing new things to the entire user base. Not to keep new features from you, but to allow me to get reports if there are any bugs before it is released to everyone.
In the last several weeks, I have added several new features:
In-app chat: I created the chat functions to allow users to collaborate in their own teams, but also as a quick way for all users to be able to chat with me as the developer. This means that if you run into any problems or have any questions, you can easily and quickly reach out to me anywhere on the dashboard.
First-time spotlight tour: This was a huge improvement to the onboarding of Featurely. Now you will get a guided spotlight tour the first time you log in, showing you the basic functions. After the tour is completed, you will then get one tour on each new feature you visit, explaining that feature in more detail. This will allow you as a new user to quickly get up to speed on how to use Featurely for your project without having to look for documentation files or search the dashboard.
CLI: I added a CLI installer to help new users add the Featurely packages into their own project. This CLI will guide you with login, API key generation, package installation, and setup in under five minutes. I think that this is a great addition to the Featurely package. It will also connect to Vercel and try to add the API keys needed there if it detects Vercel in your project.
Webhook support: I added support for Webhooks in the most essential places like error logging, maintenance, feature requests, and bug reporting. This means that you can add, for example, a Discord hook into Featurely to allow notifications and messages directly to Discord. This is a major improvement to the notification system that allows you to notify whole teams or your whole user base just with one simple hook.
AI usage in the Featurely project.
These days, I feel like this is an important area to be transparent about and to address from the beginning.
When I started creating Featurely, there was no AI involved in the process. AI had not become what it is today, and the tool was small enough for me to manage by myself.
Now AI has become a part of the process; it's not like I use AI to create new features, but I have mostly used AI (Gemini and Claude) for code reviews and security reviews, as well as documenting code with inline comments and proofreading / creating API / SDK documentation.
I have also used AI for theme generation, as we currently support 50+ themes in Featurely, and to help me design the landing page after I created the initial idea of what I wanted myself. I am not a design guru, and this is one of the tasks I find the hardest.
The AI costs have been on my private Google account and Claude Max subscription. I have a work Claude account as well, but I try to keep them separated. I view Claude as a helping hand, especially in checking code with a code review and a security review. The AI tends to find issues that I had not thought about before or bad practices in my own code. It is also pretty good at writing documentation, even though it hallucinates quite a bit and everything needs proofreading.
Why the price tag and what is ahead?
The project has evolved immensely in the past few years, and I see that the compute on Neon is taking a hit with all the new features added, like the analytics. To mitigate this issue and allow for continuous development in both the technical stack and the application itself, it is necessary to generate income back into the project. I think the Indie plan is a great place for developers to start in the tiers and that it is not overpriced in any way, especially when you consider all of the features that are included in the application. For the more API-hungry user needing more API calls and therefore demanding more compute on Neon, I have added the startup tier to cover those costs.
The future of Featurely is one full of unknowns. I know that I will keep using the application myself and that I will keep it alive. I am too invested in the project to stop developing it, maintaining it, or taking it down, especially since I use most of the features in my other projects and that I know and have steadfast proof that the system actually does what it should and promises. It doesn't do error tracking better than systems like Sentry or translations better than Paraglide JS, but Featurely does those things well enough in one single application, with one single subscription. This is the strength of Featurely, but also its greatest weakness, as developers seeing our landing page and viewing our features don't believe that we actually can do these things. Comments like "I don't understand how they can do all this" or "I don't think they are honest with those features" are comments I have heard several times. I think that the future is full of unknowns because I think it could become a great addition to many developers around the globe, but it also can be one of those systems that are never seen or used by anyone other than the developer himself.
One of the new things I am currently working on is the documentation. It feels, at the moment, a little scattered around and a little limited. I am looking into adding packages to help me develop docs.featurely.no, but I am not there just yet. I am looking for a May 3rd release for the new documentation, as I am starting now and probably need a couple of weeks until it is ready for release.
In the long run (within 2026), I am looking to implement several new features, with the ones I look at as the most interesting being integrations with Vercel and Neon. I am looking to explore if users in Featurely can add their Vercel project and manage some things directly from Featurely; two examples could be to see deployment status and redeploy. For Neon, I am looking into the possibility to manage your database or authentications. Is it possible with features like user management or storage blob management from Featurely? This is not something that I have researched yet, but I want to look into it before 2026 reaches an end. Hopefully, there is untapped potential here as well.
I hope that if you are reading this, you are willing to test out our demo. You can find it in the menu above; this demo doesn't require any sign-up or sign-in. Just press the button to enter the demo page with full functionality. The demo system resets once every 12 hours, so don't worry about playing around with it a little bit—you can't destroy too much.
If you have any feature requests or any bug reports, don't hesitate to contact me in the chat, use the reporter found as a widget, or on our public dashboard here: https://www.featurely.no/projects/iGBUmKRzcovPHJAP1Z6Y
If you want to review Featurely, you can do so at Feedback First: https://feedbackfirst.dev/app/products/featurely
I would also love it if you could take the time to support us at Product Hunt: https://www.producthunt.com/products/featurely-3?launch=featurely-3
Thank you for reading this far!
Marius - Developer of Featurely