AtomEmailPro

At AtomEmailPro, we receive feature requests from customers with different email sending workflows. Some requests are relatively simple, while others require changes to the software's existing logic.

We understand why customers want these features. However, there is an important question behind every request:

Should every feature requested by an individual customer become part of the standard version of AtomEmailPro?

The answer is not always yes. Let's look at some real-world examples and explain how we approach feature development.

Q1: Why Do Customers Need Features That AtomEmailPro Doesn't Currently Have?

Different users have different email sending strategies. A feature that is unnecessary for one user may be essential to another user's workflow.

For example, we have received requests for features such as these.

Request 1: Fill in the recipient's email address in both the TO and BCC fields

Some users want to send an email with a recipient's address in the TO field while also including that address in BCC.

Why might someone need this?

They may be working with a specific email workflow, an existing process, or a system that expects the recipient's address to appear in both fields. Instead of manually adjusting the recipient fields for every message, they want AtomEmailPro to handle this automatically.

For users who regularly follow this workflow, having the software manage both fields could save time and reduce repetitive work.

However, this is a specialized sending requirement rather than a workflow that every customer necessarily needs.

Request 2: Import multiple email templates and rotate them automatically

Another user may want to import hundreds of email templates and have AtomEmailPro select them one by one when sending emails.

For example, a user could import 500 templates. The software would select a template for each message, move to the next template, and continue rotating through the available templates.

Why would this be useful?

Users who manage different email campaigns may want to organize their content in advance rather than repeatedly editing the email body. Automatic template rotation could reduce manual work and make it easier to manage large collections of message templates.

Depending on the desired behavior, the feature might also need options for sequential rotation, random selection, template reuse, and what happens when the software reaches the end of the template list.

These details matter because a request that sounds simple at first can involve several different implementation decisions.

Q2: If a Feature Is Useful, Why Doesn't AtomEmailPro Simply Add It?

This is a reasonable question. If a customer explains a genuine problem and proposes a useful solution, why not add it immediately?

The difficulty is that a software product must serve many different customers, not just the person making the latest request.

Consider what happens when different customers request different features:

• One customer wants multiple email templates with automatic rotation.

• Another wants a special combination of TO and BCC recipients.

• A third wants a different account management workflow.

• Another requests additional sending rules or a new automation option.

Each request may be perfectly reasonable from that customer's perspective. But if we add every requested feature, the software becomes increasingly complex.

There are several challenges behind this.

1. Development requires time and resources

A feature is not finished simply because its basic function works. Depending on its complexity, we may need to modify existing logic, design the interface, test different scenarios, handle errors, and ensure that it works with existing features.

Development time is limited. Working on one custom request also means delaying other development work, improvements, or bug fixes.

2. Different customers have different requirements

A feature designed for one user's workflow may not fit another user's needs.

Even customers requesting the same general feature may want different behaviors. For example, one customer may prefer sequential template rotation, while another wants random selection without repeating a template until the list has been exhausted.

We cannot assume that one implementation will satisfy everyone.

3. More features mean more maintenance

Every additional feature becomes part of the software that needs to be maintained.

New functionality may interact with existing settings, sending workflows, or other modules. We must consider compatibility, testing, potential bugs, and future maintenance.

The cost of a feature is therefore not limited to the initial development. It can also affect the long-term stability and complexity of the software.

4. The benefit to one customer may not justify the cost for everyone

Suppose a feature costs $300 to develop but is only needed by one customer. If we add it to the standard version, all customers may receive the feature, but the development cost still has to be covered.

If many customers genuinely need the same feature, adding it to the standard product may make sense. However, if the demand comes from only one or two users, custom development may be a more practical solution.

This is not about whether a customer's idea is good or bad. It is about balancing customer needs, development costs, and the long-term direction of the product.

Q3: Why Can't the Customer Just Pay for Custom Development?

Custom development is one way to address a specialized requirement.

A customer can explain the desired workflow, discuss the implementation details with our team, and pay for the development of that feature.

The advantage is straightforward: the customer gets a solution designed around their particular needs without requiring us to add the feature to the standard version for everyone.

However, we understand that not every customer wants to cover the entire development cost alone.

A customer might be willing to contribute $50 or $100 toward a feature but may not want to pay several hundred dollars for it. That is understandable, especially when the feature is an improvement rather than something essential to their business.

So, is there another option?

Q4: Could Several Customers Share the Cost of a Custom Feature?

Yes. This is the idea behind custom feature crowdfunding for AtomEmailPro.

Instead of asking one customer to pay the full development cost, we can explore whether several customers have the same requirement and are willing to contribute toward it.

Let's use the multiple-template rotation feature as an example.

Suppose the estimated development cost is $300.

These figures are only an illustration. The actual cost would depend on the feature's requirements and implementation complexity.

The process could work as follows:

1. Submit the request. A customer explains the feature they need and how they expect it to work.

2. Confirm the requirements. We discuss the details and determine whether the feature is technically feasible.

3. Estimate the development cost. We provide a quote and establish a funding target.

4. Find other interested customers. Customers with the same requirement can join the project and contribute toward the target.

5. Develop the feature. Once the agreed funding conditions are met, we proceed according to the confirmed scope and schedule.

This approach gives customers an alternative to paying the entire development cost themselves.

It also helps us identify which features have enough demand to justify the development effort.

Q5: If Several Customers Fund a Feature, Will Everyone Get Access to It?

This is an important point that needs to be agreed upon before funding begins.

For a custom-funded feature, we can define access rights in advance. For example, the feature could initially be available only to customers who contributed to its development.

This arrangement recognizes the financial contribution of those customers and avoids automatically making every privately funded feature available to all users.

If we later decide to incorporate the feature into the standard version, that decision would be handled separately.

Before collecting contributions, we should clearly confirm:

• The total funding target and each contributor's contribution.

• The exact feature requirements and agreed development scope.

• Who will be eligible to use the completed feature.

• The expected delivery arrangements and what happens if the funding target is not reached.

Clear terms help protect both the customers contributing money and the team responsible for development.

Q6: What If Nobody Else Wants the Same Feature?

In that case, there are two practical options.

The customer can choose to pay for individual custom development, or they can continue using the existing functionality if it meets their needs.

We cannot guarantee that every feature request will attract enough contributors. Crowdfunding works only when there is sufficient shared demand.

However, even if a request does not receive enough funding, it still provides useful feedback. If we receive the same request repeatedly, we can reconsider whether it deserves a place on our standard development roadmap.

Our Approach to Feature Requests

We value customer feedback. Many useful product improvements begin with someone explaining a problem they encounter in their daily workflow.

At the same time, AtomEmailPro cannot be developed by adding every requested feature without considering its cost, complexity, maintenance requirements, and relevance to other users.

Our goal is not to reject specialized ideas. It is to find a sustainable way to address them.

When a feature is broadly useful, we can consider adding it to the standard product. When it serves a specific workflow, custom development may be more appropriate. And when several customers share the same need, crowdfunding may provide a practical middle ground.

If you need a feature that AtomEmailPro does not currently support, tell us what you want to achieve. We can discuss the requirements, assess the development cost, and explore whether individual customization or a shared funding project would be the better option.  Telegram chat: @spinnerchief

A useful feature does not always need to be funded by one person. Sometimes, several customers with the same problem can work together to make it happen.