Going From Software Developer to SaaS Developer Without Giving Up The Ghost
Is transitioning from traditional enterprise software development to SaaS delivery becoming a necessary evil of a tech boom that makes established development firms quiver in fear? We know how platforms aim to empower SaaS startups; the buzz about Apex earlier this week illustrates that much. But while enablement solutions - platforms - aim to lower barriers for new vendors, are they actually fueling reluctancy on the part of established development firms?  The underlying thing here is this: platforms are great if you can build a sustainable business from start to success, but what if you already have a successful business? Platforms, right now, do little to ease the business concerns that exist for established software vendors.
Salesforce.com knows that Apex will appeal to vendors who can build a business on it from inception. Perhaps that’s why the Apex incubator was included (read touted) as part of the initial Apex announcement. Salesforce.com knows that their platform will appeal more to the brand-spanking new startup than the established enterprise software development firm. I use Apex as the example here - but there does exist a wider void in SaaS enablement… and who’s going to be sure that all those existing companies don’t fall through the cracks while waiting for someone to help them make the jump?
A look at the extra hurdles that existing companies face is in order. Here are a few of them:
Identity
The first, and most important, concern of making the transition is maintaining your identity.
You’re a software developer with an established customer base and a brand familiarity with the platform you’ve been developing on for years. You’ve got skills and knowledge. Perhaps you’re a Microsoft Certified Solutions Developer, or a member of the Apple Developer Connection. You’ve worked hard and spent a lot of money on building up the developmental skillsets that benefit your product, the network that gains you market exposure, and ultimately the customers that increase your bottom line.  Now ask yourself:  If you had to throw that all away to pursue SaaS, would you?  You won’t read this in marketing materials from any of the early SaaS players, but as it stands right now SaaS is in fact a level playing field. It’s a new school. The SaaS market doesn’t care what you were in the old school called “Software”, you have to establish your SaaS-dentity just like everyone else. You can choose to go it alone… make a pure play SaaS application and attempt to carve out your space in the industry all over again. In this instance, you may be able to utilize some previously garnered skills, but damn, those SaaS requirements like multi-tenancy and data partitioning are just a huge hurdle right now and by the time you figure it all out a startup down the street might put you out of business. No good. You could choose to develop on a SaaS platform such as Apex and let them handle those hurdles for you… but then you’re REALLY throwing away your identity (you’re a vehicle for the platform instead of the platform being your vehicle). Forget your MCSD, you’ve got to learn a new proprietary programming language - or no programming language at all (SaaSWYSIWYG?).
It sounds harsh, I know. But this is still one of the existing barriers to widespread Software –> SaaS developer migration.  SaaS isn’t yet accessible to the developer who isn’t willing to give up all the things that consitute the identity they’ve worked hard to establish.
Needed: An enablement technology that SaaS-ifies a developer’s identity, skillsets, knowledge base, product, and even market exposure without a single drop of blood spilled.
Ingenuity
To be perfectly accurate, ingenuity can be considered a feature of identity. You are known by what you do that others don’t.  The current problem is that short of building your own SaaS technology stack (potentially catastrophic to your bottom line) you’re going to have to fit all of your ingenuity into the constructs of an enablement platform. Is this going to hurt your ingenuity? Perhaps. After all, you’ll be as ingenius as the platform says you can be. But what’s more is that all-important translation from technological ingenuity to business model - aka. competitive advantage. As far as ingenuity and competitive advantage: for some developers moving from Software to SaaS would be like trading a dollar for a nickel. Sure, the metal is shinier but the dollar’s still worth more.
Needed: An enablement technology that respects (fosters, even) ingenuity and doesn’t shortchange competitive advantage.
Integration
Take a look at your rolodex. You’ve made a lot of contacts over the years. Your network is huge. Your developers know this too because they’re on the phone with partners every day working on tightening integration between your application and theirs. Your strategic partnerships are a HUGE competitive advantage and in most cases mean the difference between sale or no sale. Now imagine giving all that up to pursue your SaaS application.Â
Of course there’s APIs, but you’ll have to relearn them.
Needed: An enablement platform that leaves your integration capabilities intact, perhaps even untouched.  Your focus should be on the software and cultivating those integration capabilities the same way you always have. Â
Exit Strategy
To tie it all together let’s assume that none of the three previous issues have deterred you and you’re ready to jump head first into the SaaS waters. Not so fast. What happens if you fail? More importantly, what happens if your approach leaves you no option but to give up the ghost? Well, going for broke and developing a standalone solution (application with SaaS tenets rolled into it) is perhaps the riskiest bet - and leaves you with essentially no room for error because as soon as it doesn’t work your bottom line dips. Not to mention the enormous outlays in infrastructure and development costs. So perhaps you turn to enablement platforms - they’ll take care of the SaaS for you and you keep just doing what your doing. Again, not so fast. As Sinclair popularly pointed out, current platforms introduce vendor lock-in that leaves you feeling a bit used (and broke, and without reusable code) should something go wrong.
SaaS does not need to be do or die… although it might seem that way right now.
Needed: Enablement technology that breaks up with you gracefully and gives you your stuff back in case it doesn’t work out. That would sure help warm cold feet.
Ok, sure, this post has a tongue-in-cheek tone to it. But I assure you that the issues raised are indeed quite serious to software developers who currently feel that they’ll have to give up their bread and butter enterprise business, company identity, and all the ingenuity they’ve accomplished in order to pursue SaaS, and without the benefit of a safety net.
Needed: A SaaS safety net.
So, I ask you software developers out there: If you’ve considered developing a SaaS offering either on your own or via an existing hosting platform but chose NOT to just yet… what was the deciding factor?




I like the questions you rise. Moving from fully controlled application development to SaaS makes you feel like you changed the profession. I think that to bring a real value to your identity and to build or enrich your brand you need to become more an architect or an analyst than a developer. Otherwise you’re a vehicle, as you mention. But if you realize right how to utilize SaaS to achieve your customer’s needs your importance and an attraction of the new profession grow exponentially (simply since you, together with the vendor, deliver final results much faster and make deployment and support safer and simpler).
Said that I don’t believe in the danger of being locked by a proprietary language. All in all, it’s just a language. If you know only a language and are young and, hence, a coder rather than a developer or an architect you still have to learn new languages. If you’re an experienced geek it shouldn’t frighten you either - you’ve learned a dozen of different technologies and another (relatively simple) is not a negative advantage. Again, presumably that you grow with the profession shift to business.
Very like the questions you rise. I tried to answer a similar question for a developer: “how to evolve from a software engineer to…”
http://roman-rytov.typepad.com/miles/2006/08/evolving_from_a.html