

Ask YC: Where are the real web 2.0 apps? - jbrun

The vast majority of the business community relies on poorly designed software. Though Twitter, Reddit, Facebook... are all impressive products, they have little "value" in the sense of building airplanes, treating medical patients, or running a country.<p>Apps in industry need to go beyond functional and user friendliness, they need to be user intuitive. Surely medical document management, social services, government run institutions, and even big nameless corporations need better software - how do we get through their (IT) gates?
======
akeefer
I don't think you'll see it done with a web startup anytime soon . . .

I've worked at a startup (not really a startup anymore) for 6 years that does
software for the P & C insurance industry, and that sort of software is just
an entirely different ballgame to develop, implement, and sell. Yes, their
existing systems are terrible, but they work(-ish), they've been building them
for 20 years so they do a ton of things, and they have anywhere from 5 to 30
different systems that all need to be pieced together. In addition, those
systems are often really core to their business: changing things requires huge
investments in terms of integration work and re-training, and such decisions
are not made lightly. In addition, they're still not (yet) comfortable with
losing control of their data. That's changing, but most big non-tech
businesses just aren't going to put, say, their insurance policies or their
medical records in some third-party website's hands where they don't have
direct access to the database. That part's probably going to change
eventually, though.

The other problem is that building these systems is hard: they're huge in
terms of functionality (a claims system just does a hell of a lot and has a
ton of different screens, rules, and tables), so they take a long time to
build, and they require an enormous amount of industry-specific knowledge that
takes a long time to build up. Feedback cycles are also hard because of the
deployment/integration model; you can't just throw something out there, have
people try it out, and quickly iterate. All that also means it's expensive to
build the software; it takes a decent number of people a really long time to
build something that's even vaguely adequate for replacing their existing,
20-years-of-development COBOL mainframe system. Combined with the general
niche market you're talking about, that means you need to get paid a lot for
every customer, which also tends to preclude any sort of hosted service-based
model; the number of customers is too low and the R & D costs are too high, so
the economies of scale just aren't there. For whatever reason, businesses just
tend to see services as cost centers to be minimized and value them
differently than software purchases.

All that, though, means that 1) their existing systems suck and 2) hardly
anyone smart is working on making them better, which is one reason why our
company is able to be successful. So if you can round up a bunch of smart
developers, some good business analyst-types who can delve into the corporate
world and discover what they really need built, and some persistent sales
people that can handle the agonizing, 12-24 month sales cycles, there's a
whole lot of money to be made there. But it's a very, very different world
than your standard web 2.0 app, and usability really doesn't factor much into
the purchase decisions: their existing systems are so bad and so hard to
maintain, the dev process is so brutal, and the competition is so poor that
the most important thing is to build a system that works and is flexible in
the right ways, and usability is more of a secondary concern. If there wasn't
such a high barrier to entry, you might actually see products compete on
usability instead of just on functionality.

If you don't want to go the full-on enterprise route, you can certainly have
success chopping off parts of their business that are hugely common across
business and industries, like salesforce.com, google apps, or wiki services.
But I don't think that approach will really work for core systems that are
highly industry-specific.

~~~
rickd
@keefer I happen to work for a big P+C insurance company, doing java
integration work on just such an unwieldy set of apps, and I couldn't agree
with you more. Development is nearly impossible due to pretty much everything
you state in para 2 and 3.

I just wanted to get this out there so people might be able to weigh in- you
said "hardly anyone smart is working on making them better." First, let me say
I completely agree. But what I was hoping for some feedback on is the WHY? I
can say, from experience, my company doesn't even TRY to retain the "smart"
people. We've been working on a huge, revolutionary change to our internal
systems for almost 3 years now, but practically every "smart" person has been
smart _enough_ to jump ship. We've lost every senior dev and architecture
person to other giant monolithic companies where they get paid to do EXACTLY
the same thing. The funny part (to me anyway) is that nobody has even tried to
retain those that are leaving. So we just continue to hemorrhage the great
talent and the quality on the project goes down down down. I'm also pretty
disappointed to see those people who were my friends going to companies that
are just as bad as here- only because it's more money (so maybe they weren't
that smart after all!)

I propose that it's a combination of two factors: 1. smart people are bored
doing this type of work and will leave when they perceive a better opportunity
(I'm going to as well in the next few weeks). 2\. Companies don't understand
that getting the "rockstar" talent is important, don't know how to recognize
it when they have it, and don't know how to keep it when they DO find it. I
think this was touched on pretty well in a few previous posts (I'll try to
find the links and stick them on here in a bit).

You don't happen to work for a certain San Mateo based software company, do
you?

~~~
akeefer
Indeed, I work for the company you're thinking of (check out our development
blog and you'll see me as the author of about 70% of the posts).

Getting good people to work for a software company writing enterprise software
is hard enough, due to factors I've mentioned elsewhere (it's low profile,
you're building systems you yourself wouldn't need or use, the deployment
model is rough). Getting good people to work doing software stuff at a non-
software company is much harder, I'd say. Even if you had great working
conditions and got to use innovative processes and technology to do things,
which not many non-software companies do, you're still going to get hit the
"talent attracts talent" problem.

Talented people want to work with other talented people; otherwise it's a
vicious cycle where the best people leave and cause the rest of the good
people to leave, and new good people that come in don't want to stick around.
The only real way to combat it is to start with a bunch of talented people and
then keep your standards high; otherwise, the feedback loop spins you down
towards mediocrity in a hurry.

~~~
rickd
cool- good to know ;)

I'm in Chicago doing integration with some of the brightest minds I've met
recently- my compliments to you guys for being able to get and retain those
people, even in the often crushing world we're working in over here.

Doing software at a non-software company certainly has been a humbling
experience. The spindown toward mediocrity has certainly been a valuable
lesson in how (not to) manage that I'll always keep in mind.

------
collin
The core difficulty is convincing somebody that user experience IS a business
requirement.

Let us set the scene: A small television ad-agency of around 100 employees.
Creative, Production, Replication, Sales, Media Purchasing, Finances,
Management, Shipping, IT and Marketing all work in concert.

This company does it all. Finding products, producing spots, buying time on
the air, duplicating and distributing video tapes and tracking sales.

They have an elaborate database keeping track of everything in motion. There
is a minor breakdown in this system(well, there are many, but I'm focusing on
this one). Replication needs work orders to copy a tape and ship it to a
station.

These work orders are sheets of paper, in triplicate. They contain hand-copied
information from the database, such as station name and address, the code of
the tape, the required date of arrival and the preferred shipping method.

On some days, hundreds of requests come to the replication department and
prioritization begins. But before triage begins the forms must be sorted.

Management knows about the problem. And they know it's expensive. Sorting and
prioritizing takes up precious hours. With a five o'clock shipping deadline
and limited VCRs, every minute you don't have a tape in a deck is a
potentially large commission lost.

In comes IT. And requirements gathering begins. They're a hip, 'with it' bunch
of guys and know how to ask the right questions. "What are you doing?" vs "How
do you think a computer should do it?"

But even that isn't enough. Pressure is on to mechanize and automate the
entire department. Every other department is in the system. Why isn't
replication?

The solution is fraught with bar codes, complex color-coded prioritization
schemes and a host of other features to let replicators know in an instant:
"What tape do I make next?"

That system is ten years behind schedule. Has no hope of completion and most
of what they really need could be implemented for a fraction of the cost.

What went wrong?

They thought of something other than the user experience. They focused on
requirements. But those requirements are already met. Requests come in.
Requests are prioritized. Tapes go out.

In their zeal to improve the efficiency of it all everybody had no sight of
what they should have been doing.

Improving the user experience.

This is what they should have done. And had they been willing to listen it
would have happened.

Simple no-brainer: stick the requests into a database. Only a minor fraction
of the data on those forms was new information and a ridiculous amount of time
was being wasted hand-copying it for each form.

Then give video technicians access to a simple column sorting view of this
data.

Let the computer sort. Computers are good for sorting.

Let the humans prioritize. Humans are good for prioritizing. And the team in
replication knows the infinitely complex prioritization system they use better
than anybody in the world could. They know what attributes matter when, and
when to escalate a time-crunch up the chain of command. What was really
slowing them up was sorting hundreds of sheets of paper.

And there you have the vast majority of the time wasted in this process
knocked out with the features more-or-less already implemented by the database
in use.

Let other features get added on people see opportunities and say: "Hey,
wouldn't it be cool if it did ..."

I worked in that replication facility before I got into programming. And it
has shown me changing the way think about how to use a computer is a far more
daunting task than any design I'll ever come up against.

------
mixmax
I think that you are hinting at an amazingly large opportunity here.

In contrast to the B2C market for web 2.0 apps where consumers expect
everything to be free, once you break into the corporate markets there are
customers willing to pay big bucks for your product.

The primary problem is selling into this market. There are a lot of
technicalities and the customers don't decide to buy after your first meeting.
It requires a prolonged effort. If you get a programmer and a savvy salesman
with experience in selling to large companies together I think there might be
gold at the end of the rainbow though.

~~~
dnaquin
How do you compete with the giant, unwieldy distributed Java application
that's been in development for ten years? Though it's expensive and terrible
to maintain and nonintuitive, how do you catch up to it's feature list?

~~~
mixmax
"how do you catch up to it's feature list?"

You don't. You redefine the problem. It's fire and motion from the big
corporations side. See Joel's classic post here:
<http://www.joelonsoftware.com/articles/fog0000000339.html>

When you look throught the clutter it is obvious that the large companies
don't really need all those shiny features - they need better software. And
what they have now sucks.

Take a totally different perspective, start attacking IBM for being too
expensive, attack Lotus notes for their horrible user interface that takes
employees years to learn. Write about how crazy it is to have an email client
that is XML compliant. Set your own agenda. People will notice.

~~~
lux
Exactly! That's what we're doing in our own niche right now (launching in 1.5
months). Our first phase is targeting businesses exclusively, although for now
not the larger ones because those take mega time and $$$ to sell to (which is
why software they buy always costs so much...).

Look at Basecamp and Highrise and you'll see plenty of proof that this
strategy is totally viable.

The other huge advantage a web-based app can offer over the traditional
corporate apps, which those apps can't easily compete with once you start
rolling, is that there's no hardware + license fees, only a monthly service
subscription. You take the headache and high initial cost out of it, and you
open these types of apps to a much wider class of businesses too.

~~~
pchristensen
Any hints as to what you're launching?

------
cmm324
Ugh.. when I worked for a local hospital, the software they used from
companies such as Siemens and Medhost was poor. Poor in that there were to
many clicks to get to desired information, poor in that the interfaces were
not designed with the user in mind, poor in that they required a difficult
update and install process. One of them would only print properly if a
specific version of Adobe Acrobat Reader was installed. The hospital spent
hundreds of thousands...

Ultimately the break fix staff spent atleast a quarter of their time
troubleshooting issues and patching workstations, not to mention server
maintenance. It seriously was a joke and very dissapointing.

I think there is a huge market out there for intuitive web applications for
large industries. I am game for any combination effort. In fact I already have
rights to the reuse of a performance management application that I developed
for a multibillion dollar corporation as a contractor. I would love to
redevelop it and begin selling for a fraction of what peoplesoft charges :D

Chris

\------------------------------ <http://www.propertystampede.com>
<http://www.stampedeblog.com> <http://blog.itrealm.net>

------
taylorbarstow
There is a reason why the web 2.0 social apps that you cite are so impressive
- it's because they were made to "scratch an itch". Indeed, they were made by
the very people who use them day in and day out.

Note that this pattern is seen at the sub-application level as well, in the
emerging agile frameworks like Rails and Merb, where developers got fed up
with the old way and decided to create a new way instead.

So how do we bring this to business? How do we break through the metaphorical
gate?

First we have to realize that this "scratch an itch" pattern simply cannot
play out in business exactly as it does in the social web. There are two
reasons for this:

1\. Business people - i.e., the people with an itch to scratch - are generally
not programmers on the side 2\. Even if they were programmers on the side, the
applications are so big that if they decided to start programming one, they
would have no time for their day job!

So how can we (a) know enough about the space we are working in and (b) think
enough like our users to build compelling, user oriented business
applications?

To my mind the answer is both simple and obvious: by involving the customer as
often as possible. Only by getting feedback can we fill the gap between users
and developers. And the more often we get feedback, the better. Here we
converge on the agile methodologies that have seen a rise in the past 6-8
years.

Couple this with a startup that is fun to work for, and that attracts the
smartest, most creative web developers, and you just might have a solution.

Of course there's still one missing piece: a couple of passionate founders who
can attract that kind of talent to this kind of software business. I guess
that's left up to the reader, as an exercise.

------
jonah
Data integration is a big factor. Basecamp doesn't use my LDAP directory. Nor
does GMAIL.

That's a big problem I see with the uptake of Web 2.0's SAS model in the
corporate world - each app is a data island. Initiatives like OpenID or
OpenSocial are great within the sphere, but doesn't do much for interoperating
with the legacy systems companies have in place.

I see that as a market opportunity as well. I have some ideas and wish I had
the time to do something about it. ;)

------
muerdeme
Talk to your friends in other industries about what problems they have around
the office.

Chances are that more companies are facing similar problems, and marketing a
solution to a known problem is more effective than showing up on their
doorstep and telling them their software sucks.

This thread made me realize that a problem my boss has been complaining is a
good opportunity for a startup.

------
joshwa
Simple: UX in business apps takes a back seat to the business requirements--
The dollars get spent on making sure the thing actually works the way the
business wants it to.

Also, the UX folks don't really get a say in what business software does,
versus a strong product manager in a startup being able to say "you don't
actually need X".

~~~
jamesbritt
There is also incredible bureaucracy, such that attempting iterative agile
development is almost certainly doomed.

One reason many Web apps are so sleek and fit is that the developers could
code, release, judge, and repeat daily.

This is much harder to do with large entities, who a) will need to present
Accounting with the One True Final Cost for pre-approval and budgeting, and b)
will need to have Official Sign-Off on the Absolute Final Specs from some
dozen department heads.

~~~
joshwa
and most importantly, need the One True Release Date.

------
pchristensen
How about StreamFocus? <http://www.streamfocus.com>

Here's my review: [http://www.pchristensen.com/blog/articles/streamfocus-an-
org...](http://www.pchristensen.com/blog/articles/streamfocus-an-
organizational-power-tool-waiting-to-be-unleashed/)

The reason they have such strict filters is that lots of vendors are after
their $$$ and because of their size, training and maintenance on any new app
is expensive. Plus medical and government have lots of regulations that
entrepreneurs often don't know about (this is where a "domain expert" comes in
handy as a partner)

------
pxlpshr
Seeing that most custom enterprise applications use proprietary
systems/infrastructure, I don't see "web 2.0" fitting in with big business...

However, I do know small/medium companies are beginning the transition into
completely custom apps like web-based POS systems, sales generation, etc..
But, $50-200k is a big chunk of change for a small entity. And as already
stated, there is a significant education process when dealing with decision
makers over ~30 years old who are unfamiliar with current technology... scare
+ relative cost = hard sell.

------
wumi
awareness and skillset.

many don't have the awareness of the market nor the skillset to attack it.

~~~
cellis
But theres another thing. Working on problems like that are _boring_. Nobody
here wants to do that.

~~~
akeefer
Being that I build such systems for a living, from what I've observed you're
pretty much right: the problems are boring in that they're not problems you
the engineer care about solving, no one sees/cares about your work, and it's
kind of a rough way to build software thanks to the terrible deployment model,
long feedback cycles, etc. We make it better by focusing a lot on building
infrastucture for building applications and trying to push the envelope
technologically, which keeps it interesting, and by giving people autonomy to
at least be creative in solving the business problems. But in general all the
rockstar developers have better things to be doing than building enterprise
systems, which just means there's less competition for those of us who do it.

------
elai
Isn't web2 software social software (and ajax :P)? Reddit, twitter, facebook,
flickr, justin.tv, youtube, etc,etc,etc are all socially based with social
networks and whatnot. Each one focuses on a certain competency, flickr for
photos, facebook for your private social network, reddit on geek news, and so
on.

~~~
mixmax
Some companies have more than 100 employees you know.

I bet that the YC news engine could be wrapped as a really nice intranet news
site where the employees locate and vote on content that is relevant to the
company.

There are many more ideas like that.

------
JFred
A lot of it will probably happen virally. Somebody will put up a "Web 2.0"
intranet app inside the company that uses the corporate database for some
small job. Then the change requests will come flooding in...

------
edw519
You need to change their stinkin' thinkin'. They think they need a package for
everything. They don't. They can't imagine what can be done with modern
technologies like AJAX, LAMP, frameworks, etc. They think "agile" is doing
something in 6 months instead of 2 years.

You need to show them otherwise. Telling them is like talking to a wall. How
to show them? Find a specific pain point unaddressed or poorly addressed by
their current software. Then write a prototype to solve that problem and show
them. Give them a chance to digest it, and when the "aha" moment comes, you've
got a prospect.

I didn't say it would be easy, but who cares. The opportunity is so big, it'll
be worth it.

~~~
jbrun
I do not mean how to do it from the inside, I mean how do you change big
organizations as software/service provider. On one side, the guys who cut big
checks want to control the feature set.

And on the flip side, the big companies are not allowed or are unwilling to
pay for web 2.0 server based services such as Basecamp (there are stories of
companies forcing employees to shut down basecamp accounts).

In many ways, it seems hopeless. We have to wait for a new generation of
employees and IT people who grew up with facebook to take over these
organizations.

~~~
trevelyan
Hopeless? You're describing an organization so riddled with inertia that
they'll keep using (and paying for) an obsolete system they are comfortable
with it and have no team inside capable of building something better?

Your problem will be building something that actually IS more useful than what
they've evolved towards. The big problem is here though:

> the guys who cut big checks

Why would any organization like that pay significant funds up front for
something that has no value to them. If this market is worth it, the way to
succeed is to give them a low cost / high trust system that complements the
way they work. Charge them next to nothing for the basic version and once
they've used it bill for ongoing support and further development.

