Overview

This roadmap describes the ideas that we’re thinking about for future development work. They include the types of changes you might expect in the future. We break the ideas up into:

Now (what we’re working on at the moment). These are thing that we think will have an immediate impact on the business and make your life better, or something that is needed to ensure continued success for the platform.
Next (what we think we’ll be working on next). We believe there is a need, we have a reasonable understanding of what it will take to complete, but we don’t know when it will get completed (we may not have even done full discovery yet, so we may not know if/how feasible the idea is).
Later (things that we may/may not work on, but that seem like they might be good ideas). We don’t know what it will take to complete nor when it will be completed, but we plan to get back to it at some point and see if we should keep it on the list (and work on it), or if we should slash it.

We provide rough timelines for now/next/later, but the timelines are just that - very rough estimates. If you have any interest in maybe helping us achieve anything on this roadmap, please see below to learn how you can help.

The Roadmap

Now	Next	Later
Website Redesign	OAuth	Sieve Enhancements, Other
Code Documentation	Billing System Redesign
	Service Resiliency

The Initiatives

Website Redesign

Complexity: Low/Medium

Many users have complained in the past about the style of the web interfaces. They’d like to see a cleaner and more modern design, to help newer and less technical users especially. Users would also like to make more advanced changes easier to make. Users have also asked for better documentation on the various different features within Purelymail (e.g., documentation around the auto charge feature, how do routing rules work, etc.).

Many users have also requested changes to how DNS works for the service. We want to make this simpler, so that everyone understands how it works and why it works the way it does.

We have been working on a website redesign for a few months that addresses many of these concerns. We want to retain the simplicity / lack of “bling” from the existing site, but we want to make it look a little nicer and make it easier to navigate. Many of the tickets we receive are from new users asking how to do basic things, and we receive some tickets from experienced users that are confused with more advanced features. We’re making it easier for new users to get started, and we’re making it easier for advanced users to configure their email the way they want. We expect the first draft of the redesign to get rolled out in 2025, but we’ll continue to improve the design and documentation over time (i.e., this will be an ongoing/constant effort). The changes we’re making will reduce the amount of time we need to spend on tickets, which will allow us to focus more on feature development and service improvements.

Documentation

Complexity: Medium/High

Scott built a tremendously resilient system that ensures your mail gets delivered regularly and largely without issue. Since Scott wrote the entire app from scratch and spent so much time with it, he was able to navigate issues and make changes quite easily. This meant that the codebase grew quite significantly, and there is not always adequate documentation for a newcomer. When we are adding new functionality or dealing with the occasional bug, we try to spend time documenting the existing code for posterity. This means we spend more time reading and understanding the code than Scott would have, but it hopefully means we can get more developers involved in the future and allow them to hit the ground running faster. This is an ongoing effort and can slow progress down now, but we hope the extra time we’re spending now will pay dividends in the future.

We’d also like to improve the test coverage of the existing codebase. Scott wrote tests for key parts of the site, but we’d like to improve test coverage to improve the codebase’s resiliency. None of this work is customer facing, but it is important to ensure service continuity, so it is a priority for us.

OAuth

Complexity: Medium/High

We’ve heard from many users that they want the ability to authenticate with OAuth. Some mail tools (like Yahoo!’s phone app) won’t even let you connect to our service unless you can do so using OAuth. Implementing OAuth would also allow us to introduce new services more easily in the future without having to incorporate them into the monolith. We’ve started to research how we could implement this, but have a lot more work to do to validate feasibility. There are a lot of areas touched by authentication, and this is obviously a highly-sensitive part of the codebase since it involves security.

Implementing OAuth also requires a deep understanding of how this standard works, as well as how other services/users will use it once implemented.

Billing System Redesign

Complexity: Low/Medium

The existing billing system is great for simplicity. You can either have simple pricing at $10/year, or advanced pricing that calculates usage-based pricing based on a few key drivers. Despite the simplicity, we need to make a change. Many of you have sent us notes indicating that you recognize the $10/year pricing model is unsustainable, and you are probably correct. We are not able to hire additional developers to help work on everything in this roadmap only charging $10/year - there is simply not enough revenue to justify the additional expense. We plan on increasing prices, but as mentioned earlier in the year, we want to do this very thoughtfully (i.e., give existing customers preferential treatment for their loyalty). This is where the complexity comes in - Scott never differentiated customers based on anything other than simple or advanced pricing. We need more granularity to make the changes we want to make without disenfranchising existing users.

When we make this change, we also want to fix some of the smaller issues that have cropped up with billing. For example, many (many) users have reported issues trying to use iDEAL to pay us. We have a fix identified, but since this involves payment activity, we cannot make the change lightly and without adequate testing. When we redesign the billing system, we’ll likely try to address issues like this (and perhaps even look into accepting crypto as a payment method).

Service Resiliency

Complexity: High

Several times this year, we’ve run into issues with AWS (some were visible while others were behind the scenes). We’ve also received requests from users to store their data in different data centers (e.g., Canada, Europe, etc.), provide ways to make backups easier, etc. This is an area that we think should be a high focus in 2026/2027, but it is very likely a very complex undertaking. We’ll start the discovery work in early 2026 and then report back what we find after we’ve had an adequate time to perform research.

Implementing a change of this magnitude may include significant rewrites of the codebase. If it does, we will need to balance the cost of the project with the potential value it will add.

Sieve Enhancements

Complexity: Believed to be high

Users would like more sieve extensions, with further support for modifying and checking flags, advanced routing, regex and more. We believe this would be a valuable addition to the service, but the implementation costs may be high.

The Timeline (ROUGH GUIDELINES ONLY!)

We are not going to commit to a specific timeline for anything on the roadmap. We think that is a recipe for disaster. So, don’t take anything below as a commitment - it is simply a rough estimate of what we’re thinking right now. Things may move faster or slower than what we anticipate.

Work	2025	Jan-Jun 2026	Jul-Dec 2026
Discovery		Service Resiliency
Design	Billing	Billing, OAuth	Service Resiliency
Delivery	Website Redesign	Billing	OAuth

As noted above, code documentation will be an ongoing effort (so we have not included it in each “Delivery” line above for brevity).

Other Customer Requests

We’ve documented other things that we’ve heard from people as well including:

Item No	Name	Description
1	Profile Pictures	Users would like the ability to attach a profile picture to their account. This can be in the form of a Gravatar, or BIMI (Brand Indicators for Message Identification)
2	Export mail to archives	Users would like the ability to export all of their emails to an archivable format.
3	Routing page rules filtering	Users would like to be able to use filtering within the Routing rules
4	Secondary non standard SMTP port	Due to certain VPS services blocking SMTP for typical services, users have requested that there are additional non standard ports which can be used, to allow for SMTP to be used on these services.
5	PGP Encryption	Users would like both better documentation and automated ways to utilise PGP encryption within our service.
6	WebDAV upgrades	Users would like both an increased file size limit as well as better permission control over the WebDAV
7	Mail Porting tool for Gmail	Users would like to easily be able to port emails across from Gmail to Purelymail, and back again.
8	Webhooks for inbound email	Users would like to have a webhook called and used when a new mail is received to the account. This can also include Pushover support.
9	Phishing button to allow users to train their spam filtering	Users currently lack the ability to train their individual spam filter on the volumes of spam that gets sent regularly to our servers. This feature would ensure that they are able to both report this spam to us to take action against the sending mail server, but also to ensure that they receive less spam in the future.
10	API Endpoint updates	Users would like further API endpoints, like for Sender Address Restrictions, creation of routing rules (these require an output), and outbound mail filtering
11	User control over 2FA	Users would like the ability to set up their own 2FA, and configure their password and reset methods within their own page.
12	Attachment size	Users would like to be able to have attachments larger than 50MB.
13	Custom Domain Certs	Users would like to be able to have their domain for IMAP and SMTP settings.
14	Password visibility within the Users page.	Admins would like the ability to view the passwords of users after being set.
15	Further SIEVE extensions	Users would like more sieve extensions, with further support for modifying and checking flags, advanced routing, regex and more.
16	Sending / Accepting calendar invites	Users want the ability to send calendar invites from within their email, accept them and use their email address to send through the normal notifications.
17	Outbound filtering	Users would like the ability to restrict the emails and domains that users within their account can send to.
18	Split delivery	Users would like control for split delivery in the domain. With split delivery set up with the domain, alternate mail servers will be attempted.
19	Shared Email Inboxes	Users would like for there to be support for shared mailboxes, similar to Outlook. Users can be assigned access and can send and receive email from this.
20	Email threading	Users would like the IMAP to be multi-threaded, to improve performance.
21	External mail storage	Users would like to change where they store their emails. Be it an S3 storage instance, homelab, ect. Control over their email storage would be ideal.
22	Allow for multiple administrators over an account	Users would like to have multiple administrators over an account, including some with permissions to certain actions or domains.
23	DNS Hosting	Certain users have asked that we become the DNS host for them, since this would be an easier setup for less advanced users.
24	API Keys permission control	Users would like a fine grained control ability over API keys (also allowing for multiple keys), to provide these to services which require only certain permissions. This helps to improve security.
25	App passwords with limited scope	To ensure that services are properly secured, users would like to be able to have app passwords where they can choose the scope for how it is used (IMAP, SMTP, POP3, DAV (all items within DAV), ect.)
26	Logout all option	It would be helpful to have a button to “logout everywhere” for breached accounts, etc.
27	Create a “sent mail” log for admins	E.g., enable admins to have a log with the to/from email addresses for all emails sent through the account.

We want help!

In order to achieve anything on this roadmap, we’re going to need help. We hired our first person in 2025 (Alice), and she’s done a great job responding to customer tickets and learning the business. Our plan going into 2026 is to hire another (part-time) person who can take over some of these duties for Alice so that she can start to focus on development work. Once we build out the billing changes, we’d like to bring on another developer to help with site reliability engineering and/or coding. If you have any interest in working with us, please fill out this short form and let us know!

Purelymail 2026 Roadmap