Ask YC: Where are the real web 2.0 apps?
14 comments
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.
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.
@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?
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?
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.
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.
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.
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.
Thanks for the great reply. I agree with pretty much everything.
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.
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.
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.
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.
I agree. A few years ago our consulting group developed a web service that manages and explains all the environmental laws and regulations in canada to companies. However, it has been a pain selling it directly to companies. The sales cycle is so long that it ends up running up expenses and forcing us to price it out of the reach of Small and Medium sized businesses who need it most.
Our plan is to go web 2.0 with this product, adding comments, article rating and building a community around the job of environmental management. I would love to see examples of this in other industries.
Our plan is to go web 2.0 with this product, adding comments, article rating and building a community around the job of environmental management. I would love to see examples of this in other industries.
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?
"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.
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.
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.
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.
Any hints as to what you're launching?
you ignore it. you target small and medium size companies who have no need for clunky java app. Work with them, play to your strengths (fast response time, quick customer service), and earn money to build features and kick clunky software in its ass.
You don't. Lower the price and focus on top priority features. Also, focus on small-medium business.
Microsoft does this against IBM. Most Enterprise Business Units at Microsoft starts at the small-medium size business and work their way up toward IBM's level.
Microsoft does this against IBM. Most Enterprise Business Units at Microsoft starts at the small-medium size business and work their way up toward IBM's level.
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
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
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.
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.
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. ;)
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. ;)
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.
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.
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".
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".
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.
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.
and most importantly, need the One True Release Date.
This also assumes that the business has UX folks--in my experience, this isn't the case.
How about StreamFocus? http://www.streamfocus.com
Here's my review: http://www.pchristensen.com/blog/articles/streamfocus-an-org...
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)
Here's my review: http://www.pchristensen.com/blog/articles/streamfocus-an-org...
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)
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.
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.
awareness and skillset.
many don't have the awareness of the market nor the skillset to attack it.
many don't have the awareness of the market nor the skillset to attack it.
But theres another thing. Working on problems like that are boring. Nobody here wants to do that.
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.
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.
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.
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.
There is a lot of knowledge that can be shared within a company, and even more within a given industry or line of work. Tons of networking opportunities - I think.
mostly 'ajax' it isn't even always really ajax. Just ajax-ish.
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...
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.
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.
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.
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.
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.
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.
YES!!!! It can be done. I created a web app with LAMP and we are selling it to the top companies in Switzerland
What kind of products? I am looking for developers. Do you have a url?
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?