Behind the scenes: How we create new Flexmail features that actually work

Last week I received a message from Sarah, one of our customers:

"That new segmentation feature is fantastic! Finally I can do exactly what I want, without wondering where I need to click."

Such a message makes my day. Because that's exactly why we do what we do.

But how do we actually ensure that new features don't just work, but truly help? Let me take you behind the scenes of our development process. Spoiler alert: it doesn't start with writing code.

Why we don't just build "cool features"

Honestly? We could easily launch a new shiny feature every month. But we don't. Because we believe that every new button, every new screen, every new field must have a reason: making your email marketing better.

That's why every new project starts the same way: with listening.

It starts with your frustrations (and we take them seriously)

Every feature we develop starts with a simple question:where do you run into problems?

Our support team keeps track of everything:

• Which questions come in most frequently?
• Where do new users stumble?
• Which workflows don't run quite smoothly?
• What wishes do our users have?

We categorize, count, and prioritize. Then we ask ourselves the most important question:"If we solve this, will it really help our customers get better at email marketing?"

Only if the answer is yes do we continue.

Learning from the competition (and from their mistakes)

Once we know what we want to solve, we dive into the world of email tools. Not to copy, but to learn.

I test everything. MailChimp, Campaign Monitor, Klaviyo... you name it.

What I'm looking for:

• Where do I get stuck as a user?
• What feels intuitive?
• What brilliant solutions can I discover?
• What absolutely must not happen?

The goal? Combine the best ideas with our own insights and your needs.

Pablo Picasso said: "Good artists copy, great artists steal." We only steal the best ideas and make them better.

From idea to first sketch: wireframes that work

With all insights on the table, the real work begins: how will this look later?

Together with Raf, our UI designer, we put the first sketches on paper. No pretty colors or fancy animations, just simple wireframes that show how you navigate through the new feature.

We draw out every step:

• Where do you click first?
• What do you see then?
• What choices do you have?
• Where do you go next?

This sounds boring, but it's crucial. Because in this phase we discover the pain points before they end up in the real app.

The technical reality check (and why it's so important)

With wireframes in hand, we go to our development team. This is where the magic happens. Or where we discover that our beautiful plans are technically a nightmare.

Our programmers don't just look at what's possible, but also at what's smart. Can we reuse existing code? How do we ensure everything keeps loading quickly? And of course: how do we keep your data safe?

These conversations often lead to better ideas. Sometimes a developer says: "That's possible, but if we do it this way, it becomes much easier for the user." That input is worth its weight in gold.

Prototypes: testing before it's real

Before we write even one line of real code, we build a prototype. A fake version that looks like Flexmail, but is actually just a simulation.

With this we can test everything without risk. Does the logic work? Does it feel natural? Can we handle all scenarios?

And more importantly: can we explain it to you later?

The ultimate test: real people, real tasks

When we're satisfied with the prototype, we do something that not all software companies do: we ask customers to test it.

We invite people who would use the feature often. We give them tasks, and then... we just watch. No help, no hints. Can they do what they want to do?

With that segmentation feature I mentioned earlier, we discovered during such a test that users thought certain fields weren't clickable. The solution was simple: better visual feedback. But without that test, we would never have known.

Another example: we had a button labeled "Empty database" when deleting contacts. Customers were terrified. They thought their entire database would disappear! Now it says "Place contacts on blacklist." Much clearer.

From prototype to reality

After all tests and feedback, we start building for real. But here too we keep working in a structured way.

We translate everything into concrete stories that our developers understand. For example: "Sarah wants to be able to create segments as a marketer, so she can approach her customers more targeted with relevant content."

For each story we make a list of what exactly needs to happen:

• Sarah must be able to create a segment
• She must be able to give a segment a name
• She must be able to add conditions
• She must be able to remove those conditions again
• And so on...

We group all those small tasks under one big topic, like "segmentation." This way we keep overview.

We work in blocks of two weeks. In such a period we try to complete as many of those tasks as possible. This keeps everyone sharp and ensures we make regular progress.

Because ultimately it's about you being able to benefit from the new feature as quickly as possible.

Quality comes before speed

When the feature is built, we really start testing. Werner, our Quality Assurance Engineer, tests every button, every screen, every possible scenario. We compare everything with the prototype. Does it work as intended? Are there bugs? Does it still feel natural?

Only when we're 100% sure it works as you expect it, do we roll it out.

The launch is just the beginning

As soon as a feature goes live, we engage our entire team:

Communication: Michelle, our product owner, writes release notes that Evelien from marketing distributes. So everyone knows what's new and how it works.

Monitoring: We track precisely via Mixpanel:

• How many people use the new feature?
• How often is it used?
• Where do users stop in the process?

Feedback: Our support team keeps track of everything and creates tickets for every question or suggestion. So we can respond quickly to problems and spot opportunities for improvement.

We use all this information for the next version, the next feature, the next problem we solve.

Why we do all this

All this work has one goal: ensuring that when you use a new Flexmail feature, it simply works. No frustration, no guesswork, no time wasting.

We believe that good software is invisible. You don't think about it, you just use it.

And that allows you to focus on what's really important: creating great email campaigns that achieve your goals.

Because that's what it's ultimately about. Not about how many features we have, but about how well they help you be successful.