Builderall was eight years old in 2017 according to information I obtained in May of that year. Customer support
also said the size of their user base was > 100,000. I used to be a developer and one of the quickest lessons
I learned was that those who used systems I constructed or enhanced want them to be responsive, intuitive, and
I appreciate the engineering skill that went into making Builderall (although I think some functionality
needs to perform more consistently) but there are "little" things that I think should have been addressed with
the first release. For example, setting a password on the email account. There is a static line of help below
the password prompt that tells you what the length of the password must be, but no more than that.
There's also a bar graph that will indicate the password strength.
So various formats are input, the password strength becomes green (i.e. passes), click a button (improperly labeled
in my opinion) and...nothing.
No error message. No sign that input was even acknowledged. With all of the testing I was doing, I don't recall
if it accepted a special character, but I'm almost certain it did not. Password strength still implies it should
have been accepted.
It only worked when I added a number.
Support confirmed they received the same results (and may have encountered it in other password setting contexts
since they said "they all seem that way").
This "little" thing actually has huge import when considering credibility of a system, particularly when a
subscription fee is being paid. And if someone is my subscriber and perceives this inconvenience...I can expect
a high volume of support tickets.
The email address set in "reply to" (verified according to Builderall criteria) must receive messages and be
accessed for correspondence.
I elected to use the internal mail manager Mailingboss, although other tools are permitted such as Mailchimp.
One anomaly encountered was an embedded link in a subscription confirmation email that didn't get formatted properly
even though it worked in previous tests, leading to a 404 error.
I began to feel as if I'd have to constantly record my activities to convince those occasional respondents who
merely replied "it worked for me."
I saw many complaints that emails were getting delivered to spam folders even though domains were verified.
Support provided extensive guidance on email etiquette and best practices, somewhat countering the admonition in
one of the tutorial videos to ensure domain is verified.
(As an aside, I am extremely impressed with the number of tutorial videos that have been generated. The ones in
the dashboard Knowledge Base have been supplemented by a slew of others independently produced on Youtube. Some
became obsolete needing revision. It became abundantly clear that one needs to consume the entire set of these
short tutorials to get as complete an understanding as possible of a feature.)
There are status indicators for subscribers such as "disabled" which I still have no idea how they aid
automation of administration. I was able to send a subscription invitation to a test account with this status
and able to register it. Similarly this account could register for a free trial. There is a provision for setting
certain types of automation rules, one of which checks custom field values. But associated custom fields did not
get changed from "N" to "Y".
While I was unable to fully conclude that assigning multiple values for a custom field -- while allowed --
render a false test for one or the other value to enforce the rule, the testing I was able to complete seems to
lead to this outcome.
My perception is a significant amount of manual intervention is required.
The mail servers were changed/upgraded some months after I began my membership, evidence that Builderall is
sincere in their mission to be "the greatest marketing platform on the planet." It's only a question of one's
ability to fund that mission.