No Code Development is Eating the Software World

It is rare that a week or two goes by without seeing a software company introduce no code development features. Sometimes its a startup with a new drag and drop experience. In other cases its a large company buying an existing workflow or business process management vendor. The latest discovery is a story of two battle hardened comms platforms going head to head with competing announcement about their no code development offering.

Twilio and MessageBird Bet Big on No Code Development

Thomas Clabrun at The Register had a great piece on the battle between Twilio and MessageBird and their “code diet”. Twilio Studio is a visual application builder that is intended to accelerate the development of applications that use Twilio’s core comms services. Flow Builder by Message Bird, although in Beta, has similar intentions and claims to be completely code free in its development experience.

I signed into Message Bird Flow Builder and was met with a number of templates to choose from – a design approach I sincerely appreciate.

 

 

I’m sure they’ll be adding to this list of templates over time.

Instead of choosing a template I decided to create a new flow to gauge what the experience will be like from scratch, and even then it prompted me to start with a template. Well done Message Bird. Once I got into the custom flow wizard I was guided by a few setup screens – another area where the product team deserves some credit – where they help me define some of the attributes of the flow I want to build.

 

 

 

I chose a Webhook trigger to begin my flow, because I thought that would give me the most flexibility. Then my mind started to race with how many things I could use as triggers to kick off a prank SMS flow in the internet of things enabled world to creep out my brother in law. I was impressed with the builder as it even simplified some basic logic for me with a branch and a nice if/then level dialog.

 

 

 

After playing around with a few of the steps and seeing the available properties I am able to configure I start to get a sense of the tools boundaries. The step library appears to be limited to 12 or so steps, and that doesn’t include a step for raw code. It is obvious that these steps tie directly to key functions in the core Message Bird service and I would be limited to building a bridge here between my application and Message Bird core. The overall experience is close to a no training required learning curve, which I expect would certainly be true if you are somebody who is familiar with Message Bird and the data you have at your disposal in your internal systems.

Now to Twilio’s No Code Development Tool… 

The Twilio Studio experience is a bit more “enterprise”, with a sign up form that asks questions about what product I plan to use, what I’m building, and if I’m a developer or not. Its a bit more tedious than MessageBird, but that’s just a one time thing. I am a bit turned off when I’m asked for a phone number for extra security when I know its for their sales team. It would have been better if they at least said that this security flow was built using the Studio I’m about to get into.

The launch screen is unimpressive compared to the MessageBird experience. After I create my account I’m presented with a screen where all I can do it give the project a name. Seeing that they cared enough to tell me that I can make changes later if I need to, this experience sets my expectations pretty low from this point forward.

 

 

After fumbling through a few other screens that took me away from my goal of getting into the studio, I finally reach the Studio Dashboard.

 

 

 

They also provided a few templates and step-by-step tutorials. Finally, a redeeming design decision! I appreciate the step-by-step guide, but its not an option for the from scratch experience so we’ll have to look at those later.

 

 

 

Now we can get to the comparison. Instead of forcing me to choose a trigger at setup, Twilio gives me more flexibility in how I start this flow. It’s still starting from a trigger, but it gives me a clear set of choices in the drag and drop experience itself as to whether or not that is an incoming message, call, or a REST call. I actually stumbled a bit trying to select the REST API path. I could click on it and define its properties which was a little less elegant than the MessageBird experience. You’ll also notice that there are a similar 11 to 12 steps in the Widget Library. I found the Split Widget, which I assumed to be comparable to a branch step. After figuring out that I had to drag that step over (instead of clicking on the endpoint in diagram) I was able to connect it to the REST API trigger. I do recognize that I have a skewed lens from my experience in other no code tools, but it felt like a fair number of extra clicks to piece things together.

 

 

I reached a similar point in the design process in Twilio as I did in MessageBird, but I end up feeling a little more confident building apps in MessageBird. I think that is for a number of different reasons. 1) The more refined drag and drop experience in MessageBird and 2) the more technical sounding jargon in Twilio are at the top of my list. Honestly, I’d fumble around for a while longer in Twilio after that Split Widget because I’m afraid of fields like “variable to test” and “condition”. I realize that I’m taking a seriously novice business user perspective here, but that’s the benchmark that I feel MessageBird has set.

 

Who will win? Twilio or MessageBird?

Our first look tells me that MessageBird, even in beta, has created a more approachable no code development tool that should provide an accelerant for the use of their core service. However, I have used Twilio before they announced their Flow Studio and it feels a lot like the rest of the product suite, which should keep the experience consistent for existing users.