The Ideal Customer. Vendors define who he is.

So many times I’ve reviewed web-based systems from common user’s perspective looking for solutions that correspond to their expectations. This time my aim is a bit different. The other thing which is not less important is the vision of IDEAL CUSTOMER vendors have.

I’d like to clear up which user type attracts them the most and whom they would like to deal with. Because all these hype "we can serve EVERYBODY and solve EVERYTHING" almost all vendors proclaim only puzzles users rather than shows what to expect from the service.

So, I asked main vendors to specify their IDEAL CUSTOMER picture and this is their description:

Chris Basham from TrackVia:

A business (not a consumer).

Rapidly solving a business-critical problem (not a minor issue, or simply building a list of items).

Needs a sophisticated workflow application where each item in the app is valuable to the business, and each item is frequently processed/updated, with event-based alerts sent to users.

Requires a highly secure platform, with 100% availability and fast response time (no downtime or slow page loads).

Values "astounding" customer support, including live phone support during business hours, and hands-on help.

5 to 5000 users, of different levels of technical sophistication, will be working in the account frequently, with differing access levels to features, records, fields, etc.

The app is used by users who’re logged-in to the account (not by website visitors.

Treff LaPlante from WorkXpress:

"WorkXpress is focused on providing programmatic-level functionality faster and more easily than if using traditional programming languages. Our ideal customer is either a non-developer who wants to produce superior software functionality or a developer who wants to greatly accelerate their software development timeframes. The ideal customer is typically creating software to automate one or two departments, or in smaller businesses they are automating the entire company."

Frank Zamani from Caspio Bridge:

"The right customer is one who has a relevant project and appropriate skills.

As far as required skills, Caspio is a feature-rich and capable platform that is intended for tech-savvy business users. Tech-savviness is a spectrum, and depending on the user’s knowledge, or skills gained by using Caspio and our free training, they can learn to utilize more complex features to create truly sophisticated web applications. With this philosophy, customers don’t grow out of Caspio. There is always something new and exciting to learn and add to their web apps.


As for the projects themselves, we strive to offer capabilities that most common internal and public facing applications require. In particular, we uniquely make it easy and affordable to build and maintain

mass-scale apps that go on to have thousands of named authenticated users, and

are deployed to customer’s own site in a seamless fashion.

For us customer size is of no consequence."

Kirill Bondar from TeamDesk:

"Our ideal customers are ones who set up an application themselves and get the most out of it. We've seen it many times: they start changing and tuning their application and can't stop because of opening possibilities to automate this and that and even more and improve it further, and quickly become addicted by the process. They enjoy the process of improvement because our customers are business people typically - not the developers - and the opportunity to do it themselves is like climbing the peak with ready application as the reward.

Such customers will have two major advantages over the rest:

A full control - they know how their application works and they do not afraid to change it.

A speed - noone knows their business process better than they are; they do not need to write the specifications and explain it to developers, they just do what they need. They can try to do it in different ways to see what works best for them or quickly adopt their application to the changes in business process."

Paula Selvidge from PerfectForms:

"PerfectForms is designed with the business user in mind as the target audience. Our goal is to empower the person closest to the problem to create the solution that meets their needs.

Now, with that said, I fully understand and agree that application development encompasses a wide range of unique skills. I think the complexity of the solution that the customer intends to build is a key factor for consideration. I feel business analysts tend to have the best broad skill set, in regards to identifying requirements, designing interfaces and understanding workflow which enables them to create, usable and effective, complex applications in tools like PerfectForms. Admittedly, it is possible to use any of these development tools to create some very poor applications. The inherent product challenge is offering the power and flexibility for more advanced users, while still providing an interface that supports less experienced or novice users. I believe PerfectForms is straddling the middle at this point but this is not where we strive to be. We will continue to enhance our product and find ways to effectively help those that don’t have the optimal skills for application development to build solutions that meet their needs.

In terms of our market focus, we target SMBs. We are at a price point that falls in the strike zone for smaller group budgets, which tend to be business focused, so they are empowered to quickly purchase a tool that meets their needs without the lengthy enterprise evaluations. For those groups, they tend to select PerfectForms as a solution because they lack access to IT resources or are prioritized lower for development since their deliverables may not be as ‘mission critical’ to the organization."

As you can see, the question is not that easy as it seems at first but some of them managed to shed some light on this point anyway.

Which type of database does your vendor rely on?

In the majority of cases users have no direct access to database back-end that their system uses for data organization/storage. Usually you manipulate data with interface or API. One can say it doesn’t really matter from the end user standpoint.

But still the choice of the database back-end defines system possibilities and ideology in many respects. This is the reason why I questioned vendors of products I review in my blog which database they use (if any), the reason of their choice and what kind of advantages it offers.

Avi Bryant from Dabble DB:

"We use a custom, in-memory object database. This allowed us to more easily provide the flexible data migration, sophisticated data types, and fast interactive querying that we wanted to offer our users."

Frank Zamani from Caspio Bridge:

"Caspio utilizes Microsoft SQL Server for its database. From day one, back in 2000, we knew that employing a powerful and scalable database is of utmost importance to us. We initially chose Oracle but soon encountered issues operating Oracle on a Microsoft stack. As a result in, our next release we dropped Oracle and replaced it with SQL Server.

The criteria remain high reliability and high scalability within a Microsoft stack. The result of our choice is evident in our ability to power some of the most demanding web applications for our enterprise customers."

Jim Salem from QuickBase:

"QuickBase chose to build a proprietary database to store app data. There are three reasons:

1) Scalability
Traditional relational database platforms are targeted towards supporting a relatively small number of potentially very large databases. Because of this, they run into significant scalability challenges when trying to host millions of independent databases. QuickBase’s architecture avoids these traditional scalability issues entirely. It can continue to support more and more applications just by adding additional hardware. Our application density (number of active applications hosted per server) is significantly higher than other online databases.

2) Performance
We chose an "in memory database" architecture because it’s significantly faster (and simpler) than traditional database architectures for the size problems that QuickBase targets.

3) Native Support for Easy-to-Use Web Data Types
We wanted to avoid the complexity of traditional databases leaking through into QuickBase’s UI. Unlike traditional databases, QuickBase was built from the ground up with the web in mind. Primitive QuickBase data types include email addresses, URLs, and versioned file attachments. These all require special coding (and overhead) on traditional databases. In addition, we implemented an easy-to-use relationship model that our users find simpler than the SQL "join" operations and index configuration required on traditional databases."

Chris Basham from TrackVia:

"TrackVia is built on the LAMP stack (Linux / Apache / MySQL / Perl).
The reason that we chose the LAMP stack is that TrackVia is differentiated from our competition by 1) Security, 2) Uptime, 3) Fast page loads.

Unlike many technology companies, we actually don’t want to have our service run on the newest technology that’s available. We only want our service to rely on mature, "battle tested" technologies that have been around for so long that all of the bugs have already been discovered and fixed. For example, we don’t run the most current version of MySQL. We run an older version that’s more stable and predictable.

As a result of this philosophy, we are able to truly deliver on the 3 items above – security, uptime and fast page loads."

Kirill Bondar from TeamDesk:

"We are using Microsoft SQL Server for TeamDesk.

In fact, we are using it for all our products for about 8 years. It proves itself reliable and scalable, delivers good performance in almost every case and provides tight integration with server platform, web environment and development tools.

Just one fact: rather than storing formula or summary column evaluation results and tracking the changes in dependend columns to know when the value needs recalculating, TeamDesk, thanks to Microsoft SQL Server performance, just calculates it on the fly. Even with large data sets and a lot of interconnected tables, this way rarely causes performance problems."

Yoge from Zoho Creator:

"We use our proprietary grid storage that is based on MySql. The reason for our choice is open source solution allow us to scale the performance to the desired level."

Treff LaPlante from WorkXpress:

"We use MySQL. We began our R&D in 2001 on MS SQL backend, and in 2003 switched to MySQL. We made the switch primarily because we knew we wanted to save our customers licensing costs, however, it's turned out to be a great decision on many levels. First, MySQL has a talented user community that we interact with to share knowledge and code. Second, MySQL has established itself in recent years with all manner of enterprise as an accepted and in some cases preferred database. Finally, the available packages and options for MySQL have greatly accelerated our time to market with new feature sets."

Aditya Tandon from Wolf Frameworks:

"We support Microsoft SQL Server and MySQL database. Currently for our OnDemand model, we offer the MySQL database which helps to lower cost for our customers. For us, database is storage and we plan to add support for other databases soon."

Paula Selvidge from PerfectForms:

"When we began development of PerfectForms in 2006, we primarily evaluated Oracle vs SQL and chose SQL due to the factors outlined below. We are also going to support SQL Express by year end, since it will further reduce costs for our customers who want to pursue an on-premise solution.

We chose SQL over Oracle due to:

1. Reliability and scalability
2. Lower cost for customers
3. Consistency with our MS stack
4. Our API is built on asp.net, so going with SQL offered better performance
5. Less costly from a support, maintenance and resource perspective for us internally."

I hope you’ve enjoyed reading all the answers as I did. Frankly, I don’t want to make any conclusions here. But I think this information can help you choose the system that is of better use for you.

So, you can check out the summary on back-end database vendors provided us with:

Dabble DB	Custom, in-memory object database
Caspio Bridge	Microsoft SQL Server
QuickBase	Custom proprietary database
TrackVia	MySQL
TeamDesk	Microsoft SQL Server
Zoho Creator	Custom storage based on MySQL
WorkXpress	MySQL
Wolf Frameworks	MySQL (for hosted service option)
PerfectForms	Microsoft SQL Server

Too many features with too many options

I believe that most web-based data driven system today are overbuilt.

Too many features with too many options, it leaves users frustrated and lost.

One of the main reasons it happens: System feature death spiral. The thing is that vendors try to sell the product demonstrating its new functionality that must beat the functionality of competitors, but that only complicates the product and makes it quite cumbersome.

The second reason for that is vendors attempt to solve two opposite tasks within one product: enable users no-programming app creation pursuing to build a system that can build apps of any complexity at the same time, what results in a plethora of options. The truth is you really don’t have to code on PHP or .NET, but instead of that it requires knowledge how to build the app within their system with their specific elements (visual, for example) and you must know how to handle this huge quantity of options. As the matter of fact the difficulties you face learning how to operate can be fairly compared to efforts of mastering a programming language, but in options.


There is one more thing. Give any system a time and eventually it turns into Salesforce. When your client base grows day by day it’s pretty difficult to decline requests of big and important customers to add some feature or option they literally can’t live without. One can say what’s wrong with that? Everybody is happy! The client is satisfied and the product has one more "useful" feature. The problem is nobody needs it but only this particular customer.

What’s your opinion? I think the time has come to do more with less.

No programming myths need reality checks

Today many vendors of data driven web apps declare their systems allow literally anybody creating the app with no programming.

Let me explain and show you how easy you can generate your first book or article. No writing required.


Do you think this device will turn you into a true writer?

The same thing is with programming. Yes, you don’t have to write PHP or .NET code, but business app creation as well as writing a book requires certain skills that no device or system can replace.

Marketing bullshit or looking for a silver bullet

Have you ever paid attention to vendors’ promo pages and how they promise you the moon? It’s been always interesting to observe how they manage to count your saved money and compose comparison charts the way competitors completely suck displaying such charateristics you can't come up with any idea why they exist at all if so.

I think these 2 examples I’ve stumbled upon recently illustrate this approach better than words can say.

Zoho Creator can count your saved time and money, see? They already know!


The full version can be checked here.

What especially amazes me in this table is 0 in "Data Modeling" row of Zoho Creator. Do system developers really believe there is no need to think how to organize data in the system? The truth is you have to think about it and this is an important moment that defines future functionality of the application.

My point is you’ll have to pay more attention to it in Zoho Creator (and in any other PaaS system), therefore spend more time on it than with Traditional Model. All these platforms have their own peculiarities and limitations and there is a huge probability you will go non standard way organizing the data to build needed reports or get an acceptable app performance and work efficiently within the app.

There is one more peculiarity this table of "saved time" doesn’t mention. Each PaaS (unlike Traditional Model that uses only well known proven methods and instruments) has its own unique approach you’ll have to learn. Take Zoho Creator Deluge Script, for example. Believe me it takes some time before you know how to deal with that.

I’d say even more. It seems to me that in general time spent on PaaS solution can even exceed time Traditional Model requires. The same situation with money. The thing is it’s not that obvious for the cycle is extended. It means you get the app that works really quickly and you have to invest your time until you see its good enough.

This is one more example how vendors compare their products with competitors. Let’s take a closer look at WorkXpress:


Full version of this you can find here.

Laugh all you want, but vendors really believe there is no system that can compete with WorkXpress. We can simply shut our eyes to this for parents always believe their children are the best in the world with no flaws at all. I can’t say exactly how far this "Anyone can use" axis goes and where the vendor places his own product, but I couldn’t jump start with it at once without reading a tutorial. And that wasn’t necessary while testing other products. Maybe this is just me or I am simply too dumb to handle these new 5GL system?

Who knows? I decided to check if things were different with my old friend, software developer for many years by the way. Just asked him to create a table with 2 columns to input two numbers where the 3 column displays the result of its division without any tutorial or help. And guess what.. It was quite a surprise he didn’t manage to handle it and just gave up. Is something wrong with us?

So, I want to say that marketing people seem to create these pages with no knowledge of product actual advantages and what really distinguishes it from the rest of competitors. But they know its limitations very well. The funny thing is somehow they manage to present it as product advantages. That’s why I’d strongly recommend you to check these pages so you know what can cause issues in the future.

And don’t forget there is no better way to get a complete picture than try and check yourself.