I came across this article this morning. Iceberg comes with an interesting platform allowing everyone to create web applications with “zero code”. Looking at the market, you can find other competitors such as Coghead, Longjump, BungeeLabs, WyaWorks or Zoho.
There is something striking me in all the video presentations I have seen on those web sites, it is the complexity for any normal user. There is indeed the “zero code” approach but you still need to understand what is a web service, that those web services have variables or that you can link those with workflows.
There are a lot of good ideas but I don’t see the point for the following reasons…
- Users (not technically aware or early adopters) expect you to come with an answer to their business needs and not with a big toolbox;
- One of the biggest challenges when creating applications is not about building it but listening to the customers and translates their functional needs into automated processes and web screens;
- Web applications builders are putting high limitation to the developers’ freedom.
Creating web applications is about 4 big steps:
- A user expressing a need;
- Translation of the need into automated processes and web screens;
- Development of the web applications;
- Fine tuning and adjustments of the web application thanks to the users feedbacks.
Each of those steps requires experience. It takes years of experience to be able to listen to users and translate their needs into ergonomic applications; it takes years of trainings and school courses to be able to develop robust and stable applications; it takes a few tries and feedbacks to get an application right.
My feeling is that those platforms try to address those four steps but instead of empowering each of the actors of the process (users, business analysts, developers) they become some kind of jack-of-all-trade giving average tools for each.
Developers have to choose for a complete framework that will not give them all the possibilities they might expect, users are not guided in the translation of their needs and business analysts need to be aware of the platform limitations.
At BeeBole we have another approach.
We think the right platform should:
- Let the users decide which functionalities they want to use, without having to think about ergonomic issues and developments.
- Let the users choose in a catalog for functionalities that are the conclusions of best practices and user feedbacks and created by IT professionals.
- Let the developers choose the tools they want to develop new functionalities and give them the integration possibilities that wouldn’t create a lock in for them.
I would be happy to have any of your thoughts about this.
[...] Beebole, on the other hand, appears quite pessimistic about the ability of these tools to ever live up to their promise. According to it, Creating web applications is about 4 big steps: [...]
If I understand well, you want to allow user to choose from a catalog of applications. Just wondering what would be the pricing strategy.
User pays for all selectable applications?: not fair if application is not used. Will you invoice if a user selects an application? Tracking this might be some kind of nightmare.
Hi Mo,
Our first ideas were balancing between a price per application strategy and a pay per use strategy.
The problem with the pay per use is that it’s not sexy.
If a future customer lands on your pricing page and has to fill in a form and think about how much timesheets, expenses, … his company is doing every month, just to have an idea about how much he will have to pay… Well, I guess, it’s already a customer lost. (At least in the SMB industry).
We have also abandoned the price per application because it wasn’t flexible enough.
What we want to achieve is to give the maximum freedom to the customers.
If we decide to package the modules in applications, it means that we have decided for the users which modules are grouped.
Innovation comes from the possibility to rearrange modules in a way that nobody has ever though before.
Of course, we couldn’t go with a price per module. This would suffer the same problem than the pay per use. It’s just not sexy and too complex.
We finally went for a flat price for everything contained in the catalog.
It also makes sense when you compare that strategy with our development strategy, which is more to integrate existing applications and APIs in our platform than developing the applications ourselves.