Want to make FluentCRM clearly stand out from the competition?

It could be awesome !

From a deliverability standpoint, you don't always want to send as fast as you can. You need to throttle and adjust the sending rate based on several factors, such as domain reputation and bounce messages from mailbox providers (usually 4XX error codes).

I would like to see automatic warm-up in FluentCRM, or split sending via multiple SMTP providers (I do that with Ongage).

This is a recurring issue. Eduardo Sachs has written an extensive post where he highlights the hardcoded limits within FCRM for sending, automation processing, and more.

So far, Shahjahan Jewel and the FCRM dev team have remained silent on this.

It's astounding to me that there are even hardcoded limits in the software. That was the number one rule I learned at University and in industry for building quality software - never hardcode anything!

Further, the fact that Shahjahan Jewel and the team are ignoring the many requests for implementing filters, so that power users can optimise the software performance when they have the appropriate hardware, it just goes against any kind of sense or rationale.

I can only conclude that the team don't actually want to build an industry-grade piece of software, despite all the marketing hype.

I guess I shouldn't be surprised. I have built a plugin extension to allow additional features for Company records via additional Tabs, and it is evident that the architecture for the "Company" module has taken significant shortcuts and is not designed for performance, scalability or extensibility.

Shahjahan Jewel and team, it is ESSENTIAL that these hardcoded limits are converted to "filter-able" values for v3.0 of FCRM so you stop losing power users.

Israel Smith  You hit the nail on the head. The fact that you found similar shortcuts and hardcoded logic in the "Company" module confirms that this is a systemic architectural philosophy, not just an isolated oversight. It seems the software was built for "good enough" scenarios on shared hosting, not for scale or enterprise infrastructure.

To the original proposal regarding multi-threading: While that is a great feature request for the future, we need to fix the foundation first. Multi-threading won't save us if the underlying queries are still hardcoded to fetch data in teaspoon-sized batches. We need the "handbrakes" removed from the database queries before we worry about adding more engine cylinders.

Sella Yoffe  Respectfully, that is a paternalistic approach to software design. You cannot build a tool that artificially limits the user based on what the developer thinks is "safe" or "wise" for everyone.

Imagine if you bought a high-performance code editor or a database engine, but the vendor hardcoded a delay that only allowed you to write 10 lines of code per minute or run 5 queries per second. Their justification? "We did this to prevent you from writing bugs or locking tables."

As a software engineer, you would find that unacceptable. You would say: "I know what I am doing, give me the raw power and let me manage the risks."

That is exactly what is happening here. We are professionals. We pay for dedicated IPs, we manage our domain reputation, and we configure our MTAs (SES, Postmark, etc) to handle the safety logic. FluentCRM is the interface, not the police. If I have a race car and I want to drive it at max speed on a track, the manufacturer shouldn't hardcode a speed limiter to 40mph just because a beginner might crash it in a parking lot.

Shahjahan Jewel The solution Israel and I are asking for does not require a complex rewrite like dynamic threading. It simply requires wrapping your existing hardcoded limits in apply_filters(). This is standard WordPress development practice. It would solve the problem for power users immediately without breaking anything for smaller users. The continued silence on such a simple fix is baffling.

Sella Yoffe  I understand your perspective on deliverability, but we need to verify where these decisions should be made in the software architecture.

I am not saying FluentCRM should have zero safety limits. My point is that these limits must not be hardcoded constants that treat every user the same way. They must be adjustable to fit the specific reality and environment of each client.

Let's use a specific analogy to make this clear:

Imagine you bought a Ferrari. It has a powerful engine designed for high speed. However, the manufacturer permanently locked the software in "Valet Mode," restricting the car to 30 mph. Their reasoning? "Driving fast is dangerous, so to prevent you from crashing, we decided you can never go above 30 mph."

That is exactly what is happening here. My server is the Ferrari engine—it has the power. But FluentCRM is the software keeping me in Valet Mode.

1. The Software Layer (FluentCRM): Its job is to process data. It makes sense to have default safe limits for a "learning driver" (shared hosting, new domains). But it MUST allow an "experienced driver" to unlock the full potential of the engine when they are on a race track (dedicated servers/enterprise infrastructure).

2. The Strategy Layer (Warm-up/Spam): You mentioned warm-up. Warm-up is a temporary phase. It is like learning to drive. Once I have spent months building my reputation and warming up my IPs, I have graduated. At that point, the software should not continue to treat me like a beginner with a cold IP.

3. The Decision Layer (The User): As the business owner, I am the one who pays for the infrastructure and manages the reputation. I should be the one to decide the pace. If I decide to push my server to the limit for a time-sensitive campaign, the software should enable that, not block it.

So, we are not asking to recklessly remove safety features. We are asking for the ability to configure them. If my environment allows for high-volume sending, I should be able to tell FluentCRM: "My environment is ready, please release the brakes."

Right now, we cannot do that without hacking the core files, and that is what needs to change.