This is the first of a short series of posts where I try to reflect on the reasons that forced me to stop trying to make money out of the (now free of use) online code-generation services . I hope you find my experience useful! (and even more that you leave your thoughts as comments). Of course, I can myself point you to companies that have been successful at where I failed but I still think they are more the exception than the rule. So, here we go.
My first advice when selling a software tool/service is to target a “cool” technology. You want to focus on selling your tool not on convincing people that the technology your tool promotes is great for them, otherwise you are fighting the wrong battle. I’m the perfect example. I was trying to sell a model-driven approach for software development where the code is generated automatically from design models. Well, many developers are completely against this idea. They will not be interested in your service no matter how good it is. Even worse, almost no developer will be immediately in favor, which means that you´ll need to work hard to convince developers that the model-driven approach is good for them even before trying to sell them your tool. This feeling is shared by other vendors (e.g. see these lessons learnt in building a mobile development platform).
Instead, imagine that you´re trying to sell some kind of agile tool. (Almost) Everybody will agree that agile is good. For whatever reason (not necessarily a scientific one) agile is “cool” and “fashionable” so agile tool vendors don´t need to waste their time convincing people that buying an agile development tool is a good idea, they can focus their energy in convincing people that their tool is better than the competitors.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
That’s it! You need to sell an *agile* model-driven development tool!
Seriously, I agree with you. Once I presented some slides about ABSE and AtomWeaver to the CEO of OutSystems, a successful company that sells an *agile* development tool, and he immediately told me that a “meta-tool” like AtomWeaver would be very hard to sell on its own, unless it covered a specific need.
The same happens you your service. Developers don’t care much about the means, only about the ends. So, offering a generic code generation service doesn’t matter, because no-one needs that. What they need is, for instance, a [insert you tool-type here] tool to develop iPhone apps, a specific need.
So, if you had a “online code-generation service to develop iPhone apps”, then it would be a success!…
I also like Software Modeling, as an user and as a provider, but I think it is really hard to reach the level of sophistication (technical, standards compliance, marketing, etc.) the profitable products have.
Because of that, I’m creating a product starting from the users perspective. Those that like to use “visual thinking” tools for Concept Mapping, Mind Mapping and general purpose diagrams for work not so specialized as software engineering.
Maybe, from that side of the world, some day the content that users create could be structured enough to serve a usable input for software generation.
For my opinion, the big problem with online tools is – they make development environment too heterogenic.
This is the difference with some “local” tool, that I can download (as jar file for example)and bind in my build process. In future, if I need to extend my product, I can use this tool once again. It’s no matter for me, if my jar version is old or I have no longer support for this tool. It is here and it work. It will be work some next years. With some online tool I have this guarantee not.
Good point Viktor. Maybe for online tools we should have some kind of “permanency” contract that guarantees to the buyer the availability of the tool for at least some time.