Does this sound familiar?
You had been working with your prospect for a while; there’s a decent understanding of the scope; you even had gone into detailed discussion about some risky aspects; the deal is now signed and the enterprise software project is ready to start. Younger developers look convinced that this time things will be done right from the start and the project will go smoothly. The prospect can’t wait to get this great new product built. There’s excitement and high expectations. This is a great moment, right?
Well, not for me. I swear I’m not a pessimist, it is just that after 20 years, these are the two main thoughts in my head:
“Here we go!: We are going to have to do yet another login screen, database connections, logging module, a dozen of integrations, too many lists and detailed views plus, how many reports did they say they wanted?… Yay, fun!”
“I wonder what will be the disagreement or misconception this time that will derail this project for months…”
More than a decade ago I realized that there had to be a better way to build enterprise software.
At the end of the day, enterprise software is not meant to be fun or engaging. It’s meant to make corporations more productive and efficient, and custom software development was everything but efficient! That’s when I dropped my developer/architect persona and jumped into BPM and service orchestration
That was a better experience for both the prospect and us as the provider. Technology was closer to the business users and these platforms took care of a lot of the most common use cases. As somebody with a coding background, I could build great demonstrations and sample applications to showcase the capabilities to our prospects. The potential value was tangible so prospects were eager to jump in. The first step was usually to train the business users on how to use our visual modeling tools and low code capabilities to build their applications… but that was the end of our honeymoon.
Here’s the thing: these were all smart customers but they were not developers.
Visual modeling and low code platforms were much easier than actual coding but these business users had very little interest in becoming visual or low code developers. It was just not something they wanted to do. They would realize that very fast, and get their IT departments involved which would create a completely different dynamic. Now we would need to have a lot of discussions about our visual modeling vs building the UI using their favorite framework or defining business logic in the low code module vs just coding things in Java Spring. And once again projects would get derailed and efficiency was not achieved.
Earlier this year I found myself in the job market and ran into the opportunity at Appify. I still have tons of coder traits so when I read about their “No-code” approach my first instinct was to be skeptical. I knew that to be a true “No-code”, the platform would have to make a large number of assumptions about the use cases it would support and quality would be directly dependent on how much can be achieved through configuration. Their value proposition was very bold so I wanted to see if they could back it up.
As the interview process progressed things went well. The team I was meeting was capable, brilliant and had a proven success track record, so I was very interested. Then it was time to dig into the product and I honestly couldn’t wait. The platform was simple to engage but powerful. The resulting apps were polished and delivered successfully on each use case they claimed to support. The current state of the platform can deliver on the promises but, will they be able to fulfill the goal of an enterprise no-code platform?
I knew I was engaging with the right team
When the people are awesome, technology has potential, and I was learning something new. My “I need to get this job” came when I finally understood the foundation of the no-code goal: There is a finite number of interactive experience types that can be packaged as building blocks that need no code to use, only configuration. If we combine those capabilities with the premise that customers will bring their own data sources and business services, we can provide a no-code platform for the enterprise customer.
The goal is brilliant and it puts the burden of creating a successful development and operation platform on us, not on the customer projects. Appify already has large success cases when the development of large apps connected to multiple backends had been done in a handful of weeks. With the focused building blocks, customers spend less time thinking of what they want and truly configuring an application that can deliver value immediately. Customers are happier because, as I said before, they don’t want to be developers; they just want to be more productive.