We're entering into new relationships here to put web interfaces on
existing applications. The questions are flying about how much it
will cost to develop a new UI for specific existing apps, how much
they can be sold for, and what sort of pricing models can be used.
With so many people building new user interfaces for their apps, I
figured this would be a fun group topic.

Many examples of pricing are below, and questions follow. Some of
these example models can be mixed. Item numbers are used for
reference only. Example values are in dollars just to cite numbers,
substitute pounds, euros, yen pesos, or lire if you're so inclined.


Which pricing models have you used for a new UI, and what sort of
variations do you use?
1) End-user pays per-seat for DBMS, application, and UI. The same
number of seats must be used for all components.
2) End-user pays a single application fee regardless of the number of
users. DBMS is of course still per-seat. Thick-client is available
for a per-seat charge for as many seats as the user wants.
3) End-user leases application by the year (no up-front
purchase/licensing costs). No additional cost for thick client vs
character interface.

For thin-client UI the licensing gets much more complicated - again,
some of these models cross-over or may be redundant.
4) Thin client is licensed per named-user.
5) Thin client is licensed as a persistent user, the same as a
character UI or persistent thick-client (client/server).
6) Thin clients are licensed in ranges. Example, 1-20, 21-100, 101+.
7) Thin client licenses are pooled with some estimated N-to-1 ratio.
The end-user pays for some fixed number of server processes (S) to
satisfy an estimated N*S users.
8) The client pays for usage equal to the maximum/peak number of S
servers, or N users connected during the month.
9) Client pays for bandwidth, transactions, or some multiple of both.
10) Thin client is free for all users as part of the app.
11) Thin client cost is presented to the end-user as a flat fee
regardless of your tool costs. Example, you charge $200 per
thin-client license, your web tools have a $100 run-time cost, and you
have $100 profit. If your costs go up you may absorb it.
12) Thin client cost is itemized with run-time licenses and separately
with your cost for the UI benefit. Example, your tool license costs
$100 and your fee is $100. If the tool increases to $125 the end-user
is responsible for for 125+100. (This brings up the basic question of
whether you itemize costs or do you try to isolate the end-user from a
lot of numbers by presenting them with a flat-rate which may increase
over time?)

How do you handle the internet vs extranet vs intranet concepts?
Example: End-user has a small but fixed number of internal users.
They also have some larger but variable number of extranet trading
partners who want to check product and order status. And they have an
internet site with an unknown number of anonymous or perhaps
registered user/customer/prospects polling truly dynamic data. As
acknowledgment that it's difficult to charge for an unpredictable
number of internet users, do you use different technologies (free/OSS)
for internet vs intranet and/or extranet?

For better or worse, how many of you have actually experienced the
trade-offs when the number of non-persistent users (N) goes up,
allowing the number of DBMS seats and other licenses go down? Have
you needed to adjust your models because of this? Do you actively
encourage users to purchase more pooled connectivity licenses to
decrease the number of server licenses?

How many of you are selling or using hosted applications? Yes, I'm
talking about the service bureau, Application Service Provider model.
Does this really save you money or help to generate new income? Can
you toss out a realistic percentage in savings or increased
profit/clients/seats?

Please feel free to add new model examples to the list and provide
some real numbers. E-mailed responses are welcome if you wish.

Thanks,
Tony
TG@ removethisNebula-RnD .com

Hi Tony:

qood question. I will separe two parts. Database and app. software.

I think the range users/ports are out of the market.

For the database vendor i like the "old" Doug way of work with Coyote,
Bandwidth.

For App. software (and also databases) i will like a mixed system that
can use MB of data, number of reads per month and number of writes per
month or something like that. Of course we must "rent" systems.

It is only a quick opinion.


joseba

We simply work on "concurrent" users still.

Bearing in mind we use a think client written in vb.net that does not
maintain a persistent connection - we can't count the concurrent sessions
very easily!

The application has a logon/logoff concept which takes and releases the
licence. As the licence database is mapped to pcname/ipaddress if your pc
crashes whilst you are logged in, you will retake the same licence token
when you reconnect.

The licence database is cleared at night just to make sure..

The counting is not foolproof but pretty good...

This concept would work for a web interface, using cookies to hold the
session reference...

Regards
Simon
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Also, we strictly have no components on the client end that have run-time
licences (development licences only with foc run-time).... This means we
don't have to copy-protect or allocate licence keys etc for our client
installs (we can just give away the install cd's on mass to customers).

On the database front, high licence pooling (on jbase a ratio of 100:1+ for
client/server licence ratio is the norm..) means in reality we only need a
couple of database licences on the server. We hide this cost to our
customers in the server price. When we move to a full ASP model, we
will simply write off this cost ourselves. In the long term, licence
pooling like this will start to hurt the database vendors - they will need
to come up with different pricing models to counter this... (not that I care
if they don;t of course!!)

Just some thoughts.

Simon
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote