One of the challenges of working with entrepreneurs as clients is that their methodology, purpose and culture for building software are different from your average everyday business or web client. OS-Cubed has built their methodology, culture and tools around being able to service the entrepreneurial client. In our case, since we are a small group - we chose ONE platform to support (DotNetNuke on IIS with a MS SQL Back End). We didn't choose that casually. We wanted to remain in the well supported (from a developer and a client's point of view) paid .NET development arena. We wanted to build on software for the back-end that was scalable and reliable. We wanted to build on software (on the front end) that was open source and optionally free. And we wanted something that wasn't so proprietary that we couldn't hand it off to another team when the time came. We also wanted a platform we were experts in hosting - as well as configuring. We've done things with DNN not even Facebook or Twitter have done - and we did it all on a shoestring budget compared to those sites.
A lot of times our clients end up in our shop because they've gone through one, two - even three or four - developers who have let them down. They tried the cheap route with programmers from India. They tried the expensive route with high end business consultants. They tried hiring "the guy down the street" or the guy from Belarus to build software for them. Frequently these forays are wretched failures - the entrepreneur-developer bond is a very specific one and if either side doesn't understand how the other thinks and works - you can end up with a real disaster.
Recently a customer came to my office (through a local referral) who was a perfect match for us - they had a site that was created by at least 4 different programmers doing different tasks (in this case all badly or with the wrong tools). They were ALREADY ON DNN! Their product was in the educational marketplace - awesome I already have an educational entrepreneurial client so I know the culture and subject matter. We didn't even need to convert them to the platform, just fix what had been done wrong and adapt it.
They had some simple, easy to repair (if you know what you're doing) systemic problems that were bringing their site down and making it unreliable, and they were on GoDaddy for hosting - possibly one of the worst hosts in the world. Amazingly though we were able to take them from a wretchedly unstable DNN install to a stable one in a matter of a couple of days - identifying and either fixing or documenting what needed to be done to get them running and meeting their goals. We unraveled the hosting issues, and the stability issues, got them up and running and all prepared for future growth. Perfect right?
A quote from the customer: "WOW! We love your process. You keep us informed, and almost seem to have a second sense for exactly what we need. You let us know before accruing hours that something might go over an estimate, and you work with us - and our other vendor partners - in a kind and courteous way as you have done this - paying attention to our priorities. You've done more in the last 48 hours for our site than has been done in 2 years of development."
Awesome. Our customers say the best things about us and we love them for it - and when we get a compliment like that it lets us shine up our white armor and say - see we CAN ride that horse! But the customer didn't stop there.
"I'm sorry to inform you however that the board has decided to move from the DNN and MS SQL to a php and mysql platform, because of all the frustrations we've had with DNN. We just want to stabilize the current install while we develop a replacement in another languague."
WHAT!? Hold the horses. The problem isn't the platform - it's the programming teams. It's not whether the platform can do what you want - it's whether the team you had used the platform to it's best advantage, using pre-programmed tools when appropriate and developing custom modules where they are needed. It's whether the team understands your requirements, budgets and goals, and works with you to make all 3 fit into the same project iteration. It's whether the team building your software knows the ins and outs of the platform to really take full advantage of it. And it's whether you trust the people building stuff. It won't matter if you move to a new development platform if your developers don't know, understand and live these precepts.
I haven't closed the loop on this yet - I'm still hoping to convince this client (through references from other clients) that it's the team not the technology. Wish me luck!
So for all of you out there right now cursing your platform (whatever it is) just be sure that the problem is really technical not cultural.