At Erlang Solutions, our support for the BEAM community is long-standing and built into everything we do. From contributing to open-source tools and sponsoring events to improving security and shaping ecosystem standards, we’re proud to play an active role in helping the BEAM ecosystem grow and thrive.

One way we’re putting that support into action is by offering free CI/CD-based security audits for open-source Erlang and Elixir projects. These audits help maintainers identify and fix vulnerabilities early, integrated directly into modern development workflows.

What the Free CI/CD Audits Offer

Our free CI/CD security audits for open source projects are powered by SAFE (Security Audit for Erlang/Elixir) , a dedicated solution built to detect vulnerabilities in Erlang and Elixir code that could leave systems exposed to cyber attacks.

The CI/CD version of SAFE integrates directly into your development pipeline (e.g. GitHub Actions, CircleCI, Jenkins), enabling you to scan for vulnerabilities automatically every time code is committed or updated. This helps projects:

• Detect issues early, before they reach production
  
• Maintain a more secure and resilient codebase
  
• Improve visibility of risks within day-to-day workflows
  

Results are delivered quickly– typically within a few minutes. For larger codebases, it may take up to 20–30 minutes. The feedback is designed to be clear, actionable, and minimally disruptive.

Open source maintainers can request a free license by emailing safe@erlang-solutions.com and including a link to their repository. Once approved, we provide a SAFE license for one month or up to a year, depending on the project’s needs, at no cost.

For more information, read our full terms and conditions .

Expert-Led Audits for Production BEAM Systems

SAFE is just one way we help teams build secure, resilient systems. We also offer hands-on audit services for production systems, including:

• Code reviews focused on clarity, maintainability, and best practices
  
• Architecture assessments to help ensure systems are scalable and fault-tolerant
  
• Performance audits to identify bottlenecks and optimise how systems behave under load

These services are delivered by our in-house experts and are a great fit for teams working on complex or business-critical systems. They also pair well with SAFE for a full picture of how systems are running and how they could be even better.

Of course, supporting the BEAM community goes beyond security and audits. Our involvement spans education, events, and long-term ecosystem development.

“We’re proud to support the BEAM ecosystem not just with code, but with the infrastructure and insights that help it grow stronger,” says Zoltan Literati, Business Unit Leader at Erlang Solutions Hungary.

“Our free audits offer real, practical value to maintainers working in open source. It’s one of the ways we’re giving back to the community.”

A Broader Commitment to the BEAM Community

The BEAM ecosystem continues to grow across languages like Erlang, Elixir and Gleam, driven by a global community of developers, maintainers, educators and advocates. Erlang Solutions is proud to contribute across multiple fronts, including:

• Sponsoring various conferences, including Code Sync
• Supporting the Erlang Ecosystem Foundation (EEF) , including participation in working groups focused on security, documentation, interoperability, and tooling
• Backing inclusion-focused initiatives such as Women in BEAM
• Sharing learning resources, contributing to open source libraries, and facilitating knowledge exchange through meetups, blogs and webinars
  

Our role is to support the ecosystem not only through expertise, but through action, and to help ensure that BEAM-based systems are not only scalable and reliable, but secure.

To learn more about our free CI/CD security audits or how we support the BEAM community, visit erlang-solutions.com .

The post Supporting the BEAM Community with Free CI/CD Security Audits appeared first on Erlang Solutions .

Release Highlights:

This release focus on integration in a wider federated network, with support for spam fighting features, better compliance with Matrix network and native support for PubSub Server Information to have your server count as part of the wider XMPP network (for example, you can register your server on XMPP Network Graph .

• Spam filter with block lists support
• Support for XEP-0485: PubSub Server Information
• Support for older Matrix rooms in ejabberd XMPP <-> Matrix Gateway

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

Other contents:

• Workaround for zip module in unpatched Erlang
• Erlang/OTP 28 supported
• Erlang/OTP 25 required
• New mod_antispam with RTBL support
• New mod_pubsub_serverinfo
• Improvements in Matrix gateway
• XEP-0431: Full Text Search in MAM
• New rest_proxy options
• New auth_password_types_hidden_in_scram1 option
• New host_alias option
• New predefined keywords
• Link to Converse in WebAdmin
• Updates in source code formatting
• New target test-group
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.07 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Workaround for zip module in unpatched Erlang

A vulnerability was published three weeks ago that affects the zip library included in Erlang/OTP: CVE-2025-4748: Absolute path in zip module .

The ejabberd installers and the ejabberd container image already use a patched version Erlang/OTP 27.3.4.1, but the ecs container image uses Erlang/OTP 26.2.

ejabberd 25.07 includes a specific protection that workarounds that vulnerability regardless of what Erlang/OTP version you are using.

Erlang/OTP 28 supported

Updating ejabberd to support Erlang/OTP 28 has required quite some work due to the replacement of ancient ASN.1 modules from Erlang/OTP public_key library.

Improvements were done on ejabberd, fast_xml , p1_acme , xmpp libraries, and also rebar / rebar3 binaries were recompiled.

However, there is still one last problem not yet solved which implies that ACME support is broken when using Erlang/OTP 28.0.1. The fix will probably be included in the next Erlang/OTP 28 release.

Erlang/OTP 25 required

The minimum Erlang/OTP version supported since now is 25.0.

However, we are aware there are still a few specific cases where older Erlang/OTP versions are being used. For that reason, the source code support for those versions is still available, and static source code analysis tools like xref and dialyzer are still run with Erlang/OTP 20 in runtime.yml .

If you really need to use ejabberd with Erlang/OTP 20 - 24, you can bypass the version check during compilation with this ./configure option: ./configure --with-min-erlang=9.0.5

New mod_antispam with RTBL support

mod_antispam is a new module that filters spam messages and subscription requests received from remote servers based on Real-Time Block Lists (RTBL) , text lists of known spammer JIDs and/or URLs mentioned in spam messages.

This module is based in mod_spam_filter which was originally published in ejabberd-contrib . If you were using that module, you can update your configuration and start using mod_antispam instead.

New mod_pubsub_serverinfo

mod_pubsub_serverinfo adds support for XEP-0485: PubSub Server Information to expose S2S information over the Pub/Sub service.

This module was originally published in ejabberd-contrib . If you were using that module, you can remove it, as now it&aposs included in ejabberd.

Improvements in Matrix gateway

While we are preparing another big update for the Matrix gateway. The most important change is that we added support to a larger number of room versions. It allows users to let them join a lot of rooms that were already created a while back and running an older version of the room protocol.

Here is the main list of changes to the matrix gateway:

• mod_matrix_gw : Support older Matrix rooms versions starting from version 4
• mod_matrix_gw : Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw : Fix key validation in mod_matrix_gw_s2s:check_signature
• mod_matrix_gw : When encoding JSON, handle term that is key-value list (#4379)

XEP-0431: Full Text Search in MAM

Support for XEP-0431: Full Text Search in MAM has been added. For now, it only works if mod_mam is using the MySQL storage backend.

New rest_proxy options

With those new options you can make modules using rest.erl module (like ejabberd_oauth_rest ) use HTTP proxy when performing HTTP requests.

The related new top level options are:

• rest_proxy : Address of a HTTP Connect proxy
• rest_proxy_port : Port of a HTTP Connect proxy
• rest_proxy_username : Username used to authenticate to HTTP Connect proxy (optional)
• rest_proxy_password : Password used to authenticate to HTTP Connect proxy (optional)

New auth_password_types_hidden_in_scram1 option

This option was added to help with adding new password types in auth_stored_password_types option to existing installations. Adding new password type made server advertise it to clients, but that caused problems for users that didn&apost have new password type stored, and which clients used SASL1 authentication, if client tried to authenticate with it, authentications would fail.

With this new option, server admin can choose which password types should not be presented to SASL1 clients (they still will be offered to SASL2 clients for users that have password compatible with this type), to later after users update password to have new type, being able to enable them.

This option takes list of password types from auth_stored_password_types that should be disabled

auth_password_types_hidden_in_scram1:
  - scram_sha512
  - scram_sha256

New hosts_alias option

The new hosts_alias toplevel option is used by the ejabberd_http listener to resolve domain names into vhosts served by ejabberd.

For example, ejabberd is serving the vhost redacted.lan , but you configured DNS so xmpp.redacted.lan resolves to that host. If you configure in ejabberd:

hosts:
  - redacted.lan

hosts_alias:
  xmpp.redacted.lan: redacted.lan

listen:
  -
    port: 443
    ip: "::"
    tls: true
    module: ejabberd_http
    request_handlers:
      "/bosh": mod_bosh
      "/ws": ejabberd_http_ws
      "/conversejs": mod_conversejs

modules:
  mod_bosh:
  mod_conversejs:
    bosh_service_url: "https://xmpp.redacted.lan/bosh"
    websocket_url: "wss://xmpp.redacted.lan/ws"

then ejabberd_http will accept https://xmpp.redacted.lan/conversejs and deliver it to vhost redacted.lan

In previous ejabberd releases, an option called default_host was documented for the ejabberd_http listener, but it didn&apost work at all correctly.

New predefined keywords

A few months ago, ejabberd 25.03 introduced new predefined keywords like HOST , HOME , VERSION and SEMVER .

And now two more predefined keywords are added:

• CONFIG_PATH : Path to the configuration directory, for example "/home/ejabberd/opt/ejabberd/conf"
• LOG_PATH : Path to the log directory, for example "/home/ejabberd/opt/ejabberd/logs"

Those keywords are specially useful when configuring mod_antispam : you can copy text files to the configuration directory where the module will read them, and also configure the module to write the dump file on the log directory.

Link to Converse in WebAdmin

mod_conversejs has a new tiny improvement: it adds a link in the WebAdmin menu to the local Converse instance.

Additionally, when HTTPS with encryption is enabled, that link logins directly with the account used in WebAdmin.

Updates in source code formatting

A year ago, ejabberd 24.06 introduced make format and make indent .

Now that script uses Perl to work correctly in Mac OS too.

And there&aposs a new section in the documentation, see Format that describes how to use that feature, and tips for Git hooks and Git alias.

New target test-group

ejabberd includes a Common Test suite with 1456 test cases, which typically takes around 10 minutes to run.

When developing new source code, you may want to run only tests from a specific group and a specific storage backend, as documented in the ejabberd testing documentation :

CT_BACKENDS=mnesia rebar3 ct --suite=test/ejabberd_SUITE --group=antispam_single

To facilitate this usage, a new target is available:

CT_BACKENDS=mnesia make test-antispam_single

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Stefan Strigler and Holger Weiß for mod_antispam and the original mod_spam_filter
• Stefan Strigler for mod_pubsub_serverinfo and test-group target
• Bruno MATEU for the missing comma in postgres schema
• GiannosOB updated the Greek translation
• Tamil Neram updated the Tamil translation
• Максим Горпиніч updated the Ukrainian translation

And also to all the people contributing in the ejabberd chatroom, issue tracker...

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition , in addition to all those improvements and bugfixes, also get the following changes.

Monitoring

The following new metrics has been added to mod_mon :

• message_receive_packet : number of message stanzas of any type received by the server on c2s connections
• message_send_packet : number of message stanzas of any type send by the server on c2s connections
• iq_receive_packet : number of IQ stanzas received by the server on c2s connections
• iq_send_packet : number of IQ stanzas send by the server on c2s connections
• iq_get_receive_packet : number of IQ stanzas of type get received by the server on c2s connections
• iq_set_receive_packet : number of IQ stanzas of type set received by the server on c2s connections
• iq_result_receive_packet : number of IQ stanzas of type result received by the server on c2s connections
• iq_error_receive_packet : number of IQ stanzas of type error received by the server on c2s connections
• iq_get_send_packet : number of IQ stanzas of type get send by the server on c2s connections
• iq_set_send_packet : number of IQ stanzas of type set send by the server on c2s connections
• iq_result_send_packet : number of IQ stanzas of type result send by the server on c2s connections
• iq_error_send_packet : number of IQ stanzas of type error send by the server on c2s connections

The metrics c2s_receive & c2s_send now count all stanzas on c2s connections.

The cpu_usage probe now gives more reliable values.

Prometheus support has been improved.

A new mod_mon_dump command has been added to dump probe values to help debug the monitoring setup.

Mobile push

It is now possible to use rest_proxy* options to use a HTTP proxy for mod_applepush & mod_gcm outgoing calls.

ChangeLog

This is a more complete list of changes in this ejabberd release:

Security fix

• ext_mod : Add temporary workaround for zip including absolute path

Compilation

• Raise the minimum Elixir tested version to 1.14.0 ( #4281 )
• Raise Erlang/OTP minimum requirement to 25.0 ( #4281 )
• configure.ac : Allow to specify minimal erlang version using --with-min-erlang
• Makefile.in : Add target test-<group>
• rebar3-format.sh : Replace csplit with perl
• Container: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4
• Installers: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4, libexpat 2.7.1, OpenSSL 3.5.1

Configuration and Tests

• Add rest_proxy* options to configure proxy used by rest module
• ejabberd_c2s : Add auth_password_types_hidden_in_scram1 option
• ejabberd_http : Remove unused default_host option and state element
• ejabberd_http : New option hosts_alias and function resolve_host_alias/1 ( #4400 )
• New predefined keywords: CONFIG_PATH and LOG_PATH
• Fix macro used in string options when defined in env var
• Use auxiliary function to get $HOME , use Mnesia directory when not set ( #4402 )
• ejabberd_config : Better lists:uniq substitute
• Tests: update readme and compose to work with current sw versions
• Update Elvis to 4.1.1, fix some warnings and enable their tests

Erlang/OTP 28 support

• Add workaround in p1_acme for Jose 1.11.10 not supporting OTP 28 ecPrivkeyVer1 ( #4393 )
• Bump fast_xml and xmpp for improved Erlang/OTP 28 support
• Bump xmpp and p1_acme patched with Erlang/OTP 28 support
• Fix make options in Erlang/OTP 28 ( #4352 )
• Fix crash in rebar3 cover with Erlang/OTP 28 ( #4353 )
• Rebar/Rebar3: Update binaries to work with Erlang/OTP 25-28 ( #4354 )
• CI and Runtime: Add Erlang/OTP 28 to the versions matrix

SQL

• Fix mnesia to sql exporter after changes to auth tables
• Update code for switching to new schema type to users table changes
• Add mssql specific implementation of delete_old_mam_messages
• Make delete_old_mam_messages_batch work with sqlite
• ejabberd_sm_sql : Use misc:encode_pid/1
• mysql.sql : Fix typo in commit 7862c6a when creating users table
• pg.sql : Fix missing comma in postgres schema ( #4409 )

Core and Modules

• ejabberd_s2s_in : Allow S2S connections to accept client certificates that have only server purpose ( #4392 )
• ext_mod : Recommend to write README.md instead txt (processone/ejabberd-contrib#363)
• ext_mod : Support library path installed from Debian (processone/ejabberd-contrib#363)
• ext_mod : When upgrading module, clean also the compiled directories
• gen_mod : Add support to prepare module stopping before actually stopping any module
• mod_antispam : Imported from ejabberd-contrib and improved ( #4373 )
• mod_auth_fast : Clear tokens on kick, change pass and unregister ( #4397 )( #4398 )( #4399 )
• mod_conversejs : Add link in WebAdmin to local Converse if configured
• mod_mam : Present mam full text search in xep-431 compatible way
• mod_mam_mnesia : Handle objects that don&apost need conversion in transform/0
• mod_matrix_gw : Don&apost send empty messages in Matrix rooms ( #4385 )
• mod_matrix_gw : Support older Matrix rooms versions starting from version 4
• mod_matrix_gw : When encoding JSON, handle term that is key-value list ( #4379 )
• mod_matrix_gw_s2s : Fix key validation in check_signature
• mod_mix and mod_muc_rtbl : Support list of IDs in pubsub-items-retract (processone/xmpp#100)
• mod_pubsub_serverinfo : Imported module from ejabberd-contrib ( #4408 )
• mod_register : Normalize username when determining if user want to change pass
• mod_register : Strip query data when returning errors
• WebAdmin: New hooks webadmin_menu_system to add items to system menu

Full Changelog

https://github.com/processone/ejabberd/compare/25.04...25.07

ejabberd 25.07 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub .

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity .

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags .

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs . The alternative ejabberd container image is available in ghcr.io/processone/ejabberd .

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues .

It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

• We’ve dropped support for Java 11. The minimum requirement is Java 17 now
• The embedded web server has received a major upgrade
• Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

We are looking for your help!

Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org .

Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org ) to see if there are any issues.

You can obtain the beta from our download page for beta releases or from the GitHub Releases page .

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat . We are always looking for volunteers interested in helping out with Openfire development!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale.

This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

The risks of rushing your tech stack decisions

Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

Common examples of early tech shortcuts

• Choosing tools based on ease rather than long-term fit
• Using third-party services without proper integration planning
  
• Avoiding proper system design to save time
  
• Stacking too many frameworks or libraries to plug gaps quickly
  
• Skipping documentation, testing, or version control in the name of speed
  

What could go wrong?

Here are some of the common risks that come with rushing tech stack choices:

The business cost of technical shortcuts

They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

The long-term cost of technical debt

We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

Let’s break down the long-term impact:

The hidden costs of technical debt

A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

When it gets out of control

Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

Here are a few real-world scenarios:

• Legacy overload : Systems running well past their intended lifespan, no longer supported or secure.
  
• Integration failure : Poorly connected tools and services that don’t talk to each other, slowing everything down.
  
• Scaling bottlenecks : Infrastructure so rigid that every new feature or user pushes it closer to breaking point.
  

Security crises : Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

What startups can do about it:

You can’t avoid technical debt entirely, but you can manage it by:

• Prioritising clean, maintainable code from day one
  
• Setting time aside for refactoring and testing
  
• Regularly reviewing architecture decisions
  
• Choosing tools that support long-term scalability, not just quick wins
  

Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

Why scalability matters from day one

Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

60% of startups face major scalability issues within their first three years (McKinsey) . These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

Here’s why it’s critical to get it right from the start:

1. Scaling later is harder and more expensive

Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

2. Maintainable code accelerates growth

Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

3. Users don’t tolerate failure

Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

4. Bad tech choices can limit your future

Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late . Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

Doing it Right from the start: In practice

Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

1. Prioritise Root Cause

Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

2. Adopt Agile

Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

3. Write Clean, Modular Code

Keep code simple and flexible. Use modular design to evolve without costly rewrites.

4. Test Early

Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

5. Review Regularly

Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

6. Choose the Right Tech

Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

7. Document Clearly

Keep documentation up to date to help teams understand decisions and onboard new members fast.

8. Don’t skip security checks

It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir) , helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises.

Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

Balancing speed and quality without overengineering

Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding .

Build now, avoid startup tech mistakes later

Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk .

The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions .

A Minimum Viable Product (MVP) is your first real signal to the market, your team, and your investors that you’re solving the right problem in the right way. While it’s often mentioned alongside terms like Proof-of-Concept (PoC), prototype, or pilot, an MVP plays a distinct role: validating real value with real users.

Avoiding common missteps early sets the stage for faster iteration, smarter growth, and long-term success. Startups are under pressure to move quickly, but speed without focus can lead to costly mistakes. Proving value fast is essential, especially with limited resources, but moving too quickly without the right foundation can stall progress just as easily as moving too slowly.

What an MVP should be

An MVP is the leanest version of your product that still delivers real value and helps you learn whether you’re solving the right problem.

It’s not about perfection, but validation. Will users care enough to try, pay, or share?

Importantly, a strong MVP also signals to investors that you can efficiently test ideas, understand your market, and move fast with limited resources.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Small by design, smart by strategy

Popularised by Eric Ries in The Lean Startup , the MVP is designed to reduce wasted time, money, and effort. By building only what’s needed to test your core assumptions, you can learn quickly and adjust early, before burning through too much time, money, or energy.

A good MVP doesn’t just mean “basic”

A strong MVP isn’t just a stripped-down prototype. It’s the foundation of your product. Lightweight, but also reliable, secure, and built for change. If it can’t be used, demoed, or trusted, it’s not doing its job.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Minimise risk, maximise learning

An MVP helps you move fast and stay focused. It’s not about trial and error. It’s about proving your idea works and showing investors that you’re building something ready to grow.

Common MVP mistakes (and how to avoid them)

Building an MVP is about speed and learning. But moving fast shouldn’t mean skipping the fundamentals. Many startups fall into familiar traps: doing too much too soon, choosing the wrong tools, or cutting corners that cause problems later.

By spotting these mistakes early, you can build smarter, avoid rework, and give your product a better chance of success.

Overbuilding Before Validation

Adding too many features at the start slows you down, increases costs, and weakens your core value. A bloated MVP is harder to test, more expensive to maintain, and often confusing for users.

Why it happens:

• Unclear priorities
• Perfectionism
• Fear of missing out

How to avoid it:

Focus on solving one clear problem well. Use low-code or no-code tools to test ideas quickly without overcommitting time or budget.

Choosing the wrong tech stack

Selecting technology based on trends instead of fit creates long-term issues. The wrong stack can lead to expensive rebuilds, poor stability, development slowdowns, and scaling challenges.

Why it matters:

Your tech choices affect how fast you can iterate, how well you scale, and how easy it is to adapt later.

How to avoid it:

Choose a simple, flexible stack that fits your domain. Use tools that support rapid development and long-term growth. Involve technical partners or advisors with experience to help avoid common mistakes.

Ignoring security and code quality

When speed trumps structure, the result is often messy, unreliable code.

A growing trend, vibe coding , uses AI (especially large language models) to quickly generate code from natural language. While this accelerates initial progress, it often skips testing, documentation, and consistency, leading to hidden risks and technical debt.

Though fast at first, vibe coding can leave fragile code that’s hard to debug, extend, or transfer, with teams diverging in approach and progress stalling over time.

Why does it happen?

• Misunderstanding MVP as “low quality” rather than “focused and efficient”
• Overreliance on AI-generated code without review or standards
• Lack of experienced engineering oversight

Risks include:

• System instability and hidden failures
• Security vulnerabilities and compliance breaches
• Technical debt and poor maintainability
• Loss of trust from investors and partners

How to avoid it:

Prioritise quality from day one:

• Review AI code for security, clarity, and maintainability
• Apply secure authentication and data encryption
• Set shared coding standards and style guides
• Require basic tests and documentation, even for MVPs
• Limit LLM use in critical paths unless thoroughly validated
• Track shortcuts and log them as technical debt to resolve later

A little rigour early on prevents major setbacks down the line.

What smart MVP development looks like

A smart MVP is fast, focused, and built for flexibility. It doesn’t aim to include everything, just enough to test your core idea with real users.

Here’s what that looks like in practice:

Built fast, not rushed

Speed should serve as validation. The best MVPs reach users quickly without creating confusion or technical debt.

Focus on:

• Delivering one clear value
• Releasing early to gather feedback
• Improving in tight, focused cycles

Easy to change, because feedback is coming

A smart MVP is flexible by design. Once feedback starts coming in, you need to be ready to adjust quickly without overhauling everything.

Make this easier with:

• Modular code
• Clear documentation
• A prioritised backlog for fast iteration

Safe and secure – even if it’s lean

Even a small MVP needs to be stable and secure. If users are testing it, they’re trusting it.

Trust depends on:

• Data security and privacy (including GDPR compliance)
• A clear, usable interface
• Consistent, reliable performance

A strong MVP is :

• Right-sized: Solves one problem well
• Stable: Works reliably in demos and tests
• Scalable: Built on a foundation that can grow
• Trustworthy: Respects and protects user data

Smart MVP development means building fast, but building right. When you combine speed with strategy, you don’t just ship faster, you learn faster, improve faster, and grow stronger.

Build fast. Build smart. Build for growth.

A strong MVP helps you validate your idea, attract early users or investors, and gather feedback, without overbuilding or overspending. The goal is not just to launch quickly, but to launch with clarity, purpose, and scalability in mind.

Many teams fall into the same traps: bloated feature sets, the wrong technology choices, or neglecting long-term costs. These missteps waste time, burn cash, and kill momentum. The most effective MVPs are built with focus, tested against the right assumptions, and grounded in a foundation that supports growth from day one.

At Erlang Solutions, we can help your startup launch MVPs that are resilient under pressure and built for the future. If you’re ready to build something that works, let’s talk .

The post Common MVP mistakes: How to build smart without overbuilding appeared first on Erlang Solutions .

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of April 2025.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom .

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, submissions are open until May 18th, 2025, 00:00 UTC! .

XSF Fiscal Hosting Projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective . For more information, see the announcement blog post . Current projects you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

XMPP Events

• Berlin XMPP Meetup [DE / EN]: monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• XMPP Sprint in Berlin : On Friday, 23rd, Saturday, 24th, and Sunday, 25th of May 2025.

XMPP Articles

• XMPP Foundation Urges Meta to Allow Interoperability Under EU Rules by Markus Kasanmascheff for winbuzzer.com
• Monocles , the project responsible for the XMPP Monocles chat Web and Android clients, has started a crowdfunding campaign . The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from 03.28.2025 to 06.30.2025.
• Prav has taken its second major step towards forming a cooperative society in India. Their blog post “Finalising our bye-laws” details the process, including ways you can help out. This is an important step in Prav’s mission to implement community-driven decision making for their XMPP apps and services and give legal teeth to that structure .

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-1 for Android. This version introduces an initial implementation of Spaces ( XEP-503 ), among other improvements, bugfixes and more!
• Conversations has released versions 2.18.0 , 2.18.1 and 2.18.2 for Android. Notable changes include the ability to pick a custom backup location, a prominent backup restore option for Quicksy , and improved support for more kinds of URIs. The latter includes tel phone numbers, mailto email addresses, and more interestingly the web+ap scheme for ActivityPub proposed by Fedi Links .
• Dino has released version 0.5 featuring OMEMO encryption by default, improved file transfers, image preview and other file details before downloading, and two completely reworked dialogs. See the release blog post for all the details.
  • At the same time, Dino has also received funding from NLnet to begin development on a slew of new features. This includes message moderation in group chats, local message deletion, modern connection handling with FAST and SASL2, more formatting options with Message Markup, and more! Visit the project page for all the details.
• Gajim has released versions 2.1.0 and 2.1.1 with a new ‘Activity feed’ page, layout improvements for its ‘Start Chat’ dialog and support for ‘Message Display Synchronisation’ ( XEP-0490 ) across group chats among other improvements and bugfixes. Head over to their News section for all the details.

Activity feed in Gajim 2.1

Account and status selection in Gajim 2.1

• Kaidan has received NLnet funding for various improvement across the board , most notably multi-user chat and support for legacy OMEMO. The second point is significant because while Kaidan is using a newer version of the OMEMO end-to-end encryption protocol, other popular clients including Conversations, Monal, and Dino are still using an older version. Since the two are not compatible, this meant Kaidan users were unable to use OMEMO encryption with users of most other clients. By implementing the older spec as well, Kaidan will help bridge that gap.

• Monocles Chat 2.0.6 has been released for Android. This version brings initial support for file captions, the option to pin an unencrypted message to the top of a conversation, providers list support, and the option to register on your own XMPP server, among many other new features and improvements.

Monocles Chat 2.0.6: Initial captions to files and pin message to the top

Monocles Chat 2.0.6: Register on your own XMPP server or pick one from the providers list

• Movim has released version 0.30 (code named “ Encke ”), the biggest Movim evolution in many years! This release brings multi-participant calls , reactions being displayed in the detailed message view, support for Unicode 15.1 with plenty of new emojis to use, and avatars that change when a contact adds to their Story .

Movim 0.30 (Encke): Multi Participant Calls. Bob Cat looking disgruntled by the presence of the ‘Hooman’ on the lower right of the screen!

Movim 0.30 (Encke): Meow OwO bedazzled by the looks of Multi Participant Calls on his mobile device!

• and following right on its heels, Movim also published its first bug-fix release: version 0.30.1 , adding animated pictures support in the image proxy and a new Avatar and Banner Configuration Panel, as well as implementing ( XEP-0392 ) Consistent Color Generation, among many other improvements and bugfixes. Make sure to check out the official announcements at the Movim Blog for all the details!

Movim 0.30.1: Avatar and banner configuration panel

• Prose has released versions 0.8.0 , 0.8.1 , 0.8.2 , 0.8.3 , 0.9.0 , 0.9.1 and 0.10.0 of its web frontend prose-web-app .

XMPP Servers

• MongooseIM has released version 6.3.3 of its Enterprise Instant Messaging Solution. This minor update includes various fixes and improvements. For more information, check out the documentation .
• ProcessOne has published ejabberd 25.04 . This release brings an important security fix, several bug fixes and a new API command.
• Prosody IM is pleased to announce version 13.0.1 , a new minor release from the latest stable branch. It fixes some important bugs that were discovered after the latest release. Read all the details on the release changelog . As always, detailed download and install instructions are available on the download page for your convenience.
• The Prosody app for YunoHost has been updated to provide a bunch of supported XEPs by default, configured for all YunoHost users in just one click. YunoHost is a set of tools to easily manage your own selfhosted services, and while it used to come bundled with the Prosody fork Metronome by default, it has recently bundled its XMPP functionality into a separate “app” so that people can swap in any other XMPP server of their choice.

XMPP Libraries & Tools

• go-xmpp versions 0.2.13 and 0.2.14 has been released.
• libomemo-c version 0.5.1 has been released.
• prose-core-client versions 0.1.103 , 0.1.104 and 0.1.105 have been released.
• python-nbxmpp versions 6.1.0 and 6.1.1 have been released.
• Slidge versions 0.2.9 (codenamed “Trixie <3”), 0.2.10 , 0.2.11 and 0.2.12 have been released.
• Tinder version 2.1.0 has been released.
• Whack version 3.0.0 has been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs . Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001 , which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process . Communication around Standards and Extensions happens in the Standards Mailing List ( online archive ).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor . Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• No XEPs proposed this month.

New

• No New XEPs this month.

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

• No XEPs deferred this month.

Updated

• Version 1.1.3 of XEP-0313 (Message Archive Management)
  • Fixed typo (XEP Editor (dg))
• Version 0.4.0 of XEP-0377 (Spam Reporting)
  • Add spam report processing opt-in.
  • Add Guus der Kinderen as co-author. (gdk)
• Version 1.0.1 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
  • Fixed typo (XEP Editor (dg))
• Version 0.3.0 of XEP-0455 (Service Outage Status)
  • Remove all in-band event signaling. (mp)

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

Also check out our RSS Feed !

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board .

Newsletter Contributors & Translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus
• Português (BR): xmpp.org
  • Translators: Paulo

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad . At the end of each month, the pad’s content is merged into the XSF GitHub repository . We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

• gathering news in the XMPP universe
• short summaries of news and events
• summary of the monthly communication on extensions (XEPs)
• review of the newsletter draft
• preparation of media images
• translations
• communication via media accounts

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first . If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license .

ElixirConf EU 2025 is only two weeks away! Soon, it will once again be time for the Elixir community from Europe and beyond to come together, connect, and learn from each other about Elixir and its ecosystem. There will be dozens of talks from speakers across the community, training opportunities, and more.

This year’s event is being held in Kraków, Poland from May 15-16, with optional training available on May 14. Both in-person and virtual tickets are available.

Here’s a preview of some of the speakers on the schedule, and what to expect from their talks:

Keynotes

José Valim: Type System and Elixir Updates

No ElixirConf would be complete without an appearance from Dashbit’s José Valim , the creator of Elixir.

Since announcing it at ElixirConf EU 2022 , José and the Elixir team have been hard at work on a type system for the language based on set-theoretic types. Implementation of this system is still underway , and José will offer an update on its progress, as well as other recent activities from the Elixir team and what to expect in the next release. Guillaume Duboc , a PhD student at Université Paris Cité who is working on the type system for his thesis, will provide a more in-depth look at it in a separate talk, “What’s New with Elixir Types”.

James Arthur: Introducing Phoenix.Sync

James Arthur is a TED Prize and Microsoft Prize-winning co-founder of Opendesk , Hazy , and Post Urban , with prior software development experience for Apple and IDEO .

He is currently the CEO of ElectricSQL , developers of the Elixir sync engine Electric , and will be bringing that knowledge to his keynote introducing Phoenix.Sync , a new library that adds real-time sync to Phoenix. Expect a tour through the basics of the library, how to use it to sync data into both backend and frontend applications, and its potential uses in AI systems.

Davide Bettio and Mateusz Front: The AtomVM and New Horizons for Elixir

SECO Mind’s Davide Bettio has years of embedded systems and IoT experience, and began work on AtomVM , a lightweight BEAM implementation tailored for IoT devices, in 2017.

He’ll be joined by Mateusz Front , an Elixir developer at Software Mansion , to explain the results of a collaboration that has proved Elixir can be run on a whole new platform. They’re keeping quiet about the specifics, so you’ll have to check out their keynote to find out what they’ve come up with, along with plenty more information about AtomVM and Elixir runtimes.

Industry Stories

Anita Ludermann: Turn Old Into New: Moving to Elixir Feature by Feature

Anita Ludermann is a software engineer currently at Modell Aachen GmbH , where she has spent the last few years working with a team whose goal is to modernise a legacy codebase by transitioning it to Elixir.

She’ll be offering a first-hand account of what adoption of Elixir and the functional paradigm in general looks like in a real-world industry context, with all the challenges of shifting an entire system to a new language bit by bit while maintaining consistent functionality for the user.

Ettore Berardi: How Elixir Powers the BBC: From PoC to Production at Scale

After a stint at MacMillan Science and Education , Ettore Berardi joined the BBC , where he has now been working for eight years as a tech lead.

He’ll be relaying another story of Elixir adoption in action, namely the four-year process of shifting to Elixir at the BBC, starting with an initial proof of concept and culminating with nearly all BBC app and web traffic being served by Elixir. On top of the technical side of things, he’ll also discuss the realities of building and maintaining Elixir expertise in an environment largely unfamiliar with the language.

Libraries and Frameworks

Gus Workman: Introducing Trellis: Open Source Hardware for Nerves

You may already be familiar with Nerves , a framework for using Elixir to build embedded systems. Gus Workman is the founder of Protolux Electronics , a company specialising in Nerves-based hardware and software.

His talk will introduce Trellis, an open-source hardware platform reminiscent of Raspberry Pi , but specifically built with the purpose of producing custom circuit boards for Nerves and Elixir.

Parker and Shannon Selbert: The Architecture of Oban Web

Oban Web , the live dashboard for the prominent Elixir background job library Oban , recently became fully open source.

Now, Oban’s creator Parker Selbert and Oban core team member Shannon Selbert, co-founders of Soren , will be diving into the internals of the project, touring its key elements and interesting features. They promise to reveal how to structure a complex LiveView application with extensive real-world use, backed by Oban Met , a purpose-built distributed database.

Ridwan Otun and Sola-Aremu ‘Pelumi: Whisperer: An Elixir-Based Multi-Agent Framework

Ridwan Otun and Sola-Aremu ‘Pelumi are two self-described Elixir evangelists working as engineering vice presidents at Juicyway and Bank of America , respectively.
Their talk will introduce Whisperer , a new and recently open-sourced framework that allows users to define, sequence, and orchestrate multi-agent AI systems. It’s another talk that’s well worth checking out if you’re interested in learning how Elixir developers are taking advantage of the new possibilities afforded by agents and LLMs.

Deep Dives

Conor Sinclair: Meta-Programming in Elixir: Dynamic Function Calling with LLMs

Multiverse’s Conor Sinclair is a senior software engineer specialising in frontend and with a passion for Elixir.

He’ll be joining the conference to address the now-ubiquitous topic of LLMs. Conor will be addressing Elixir specifically, walking the audience through the process of creating generic interfaces and using the Langchain library to expose them to LLMs. It’s sure to be a fascinating talk for anyone curious as to how these models interface with an existing application.

Robert Virding: Unveiling the Magic of Erlang/OTP Behaviours: A Deep Dive in the Codebase & Björn Gustavsson: My Beam History

We’ll also be getting talks from two developers whose experience with Erlang and the BEAM goes back to the very beginning. Robert Virding was one of the co-creators of Erlang at Ericsson , and now works for Erlang Solutions as Principle Language Expert.
He’ll be offering a deep dive into the Erlang/OTP codebase, as well as a BEAM VM training session the day before the conference proper. Björn Gustavsson , meanwhile, joined the OTP team in 1996 and later became the main developer for the BEAM, which is partially named for him. His talk will explore his three decades of history with the BEAM.

And More!

Of course, that’s only a fraction of the talks at this year’s event – there are plenty of others, and it’s worth checking out the full list of speakers to see if there’s anything else that catches your eye. If you’ve already committed to attending, the schedule is now available, so you can start deciding which talks to attend.

There’s sure to be something for everyone with an interest in Elixir and the BEAM, and Erlang Solutions will be present at the event as always, so be sure to say hi to our team if you do attend. We hope to see you in Kraków in a few weeks for ElixirConf EU 2025!

The post Looking Forward to ElixirConf EU 2025 appeared first on Erlang Solutions .

“When an operation cannot be expressed by any of the functions in the Enum module, developers will most likely resort to reduce/3.”

-From the docs for Enum.reduce/3

In many Elixir applications, I find Enum.reduce is used frequently. Enum.reduce can do anything, but that doesn’t mean it should. In many cases, other Enum functions are more readable, practically as fast, and easier to refactor.

I would also like to discuss situations that are a good fit for Enum.reduce and also introduce you to a custom credo check I’ve created, which can help you identify places where Enum.reduce could be replaced with a simpler option.

Readability

Here are a few common reduce patterns—and their simpler alternatives.  For example, here’s something I see quite often:

Enum.reduce(numbers, [], fn i, result -> [i * 10 | result] end)
|> Enum.reverse()

This is a situation that the Enum.map function was designed for:

Enum.map(numbers, & &1 * 10)

Perhaps you know about Enum.map , but you might see a call to reduce like this:

Enum.reduce(numbers, 0, fn number, result -> (number * 2) + result end)

Let me introduce you to Enum.sum_by !

Enum.sum_by(numbers, & &1 * 2)

Let’s look at something a bit more complex:

Enum.reduce(numbers, [], fn item, acc ->
  if rem(item, 2) == 0 do
    [item * 2 | acc]
  else
    acc
  end
end)
|> Enum.reverse()

This is a perfect case for piping together two Enum functions:

numbers
|> Enum.filter(& rem(&1, 2) == 0)
|> Enum.map(& &1 * 2)

Another option for this case could even be to use Enum.flat_map :

Enum.flat_map(numbers, fn number ->
  if rem(number, 2) == 0 do
    [number * 2]
  else
    []
  end
end)

This is a decent option, but while this achieves the purpose of both filtering and mapping in a single pass, it may not be as intuitive for everybody.

Lastly, say you see something like this and think that it would be difficult to improve:

Enum.reduce(invoices, {[], []}, fn invoice, result ->
  Enum.reduce(invoice.items, result, fn item, {no_tax, with_tax} ->
    if Invoices.Items.taxable?(item) do
      tax = tax_for_value(item.amount, item.product_type)
      item = Map.put(item, :tax, tax)

      if Decimal.equal?(tax, 0) do
        {no_tax ++ [item], with_tax}
      else
        {no_tax, with_tax ++ [item]}
      end
    else
      {no_tax, with_tax}
    end
  end)
end)

But this is just the same:

invoices
|> Enum.flat_map(& &1.items)
|> Enum.filter(&Invoices.Items.taxable?/1)
|> Enum.map(& Map.put(&1, :tax, tax_for_value(&1.amount, &1.product_type)))
|> Enum.split_with(& Decimal.equal?(&1.tax, 0))

Aside from improving readability, splitting code out into pipes like this can make it easier to see the different parts of your logic.  Especially once you’ve created more than a few lines of pipes, it becomes easier to see how I can pull out different pieces when refactoring.  In the above, for example, you might decide to create a calculate_item_taxes function which takes a list of items and performs the logic of the Enum.map line.

Performance

You may have already thought of a counterpoint: when you pipe functions together, you end up creating new lists, which means more work to be done as well as more memory usage (which means more garbage collection).  This is absolutely true, and you should be thinking about this!

But I find that 99% of the time, the data I’m working with makes the performance difference negligible.  If you find that your code is slow because of the amount of data that you need to process, you might try using the Stream module — it has many of the same functions as Enum , but works lazily.  If that doesn’t work, then by all means, create a reduce (and maybe put it into a well-named function)!

As Joe Armstrong said:

“Make it work, then make it beautiful, then if you really, really have to, make it fast.”

For some information about benchmarks that I’ve run to understand this better, see this analysis and discussion .

Good Opportunities for Enum.reduce

Aside from occasional performance reasons, Enum.reduce can often be the simplest solution when you want to transform a data structure over a series of steps.  For example:

• Build a data structure based on an enumerable (like a fragment in an Ecto query )
• Transform a data structure (like replacing variable references in a string )

Find Cases in Your Own Code with credo_unnecessary_reduce

Remember that no one pattern works in all cases, so know what tools you have available! If you’d like to quickly find instances for potential improvements in readability, I built a Credo check to help spot where reduce can be swapped for something simpler.

You can drop it into your project and start catching these anti-patterns automatically.

https://github.com/cheerfulstoic/credo_unnecessary_reduce

Simply add it to your mix.exs file:

{:credo_unnecessary_reduce, "~> 0.1.0"}

…and then enable it in your .credo.exs file:

{CredounnecessaryReduce.Check, []}

The post Reduce, Reuse… Refactor: Clearer Elixir with the Enum Module appeared first on Erlang Solutions .