#eavoices

Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.
Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.
Entrepreneur: I can see that you have, great. Let’s get started.

The entrepreneur, trusting the developer, begins to feed him a couple of ideas. The developer asks questions whenever they get stumped. Weeks and/or months later, behold, a website arises!

But this is not the happy ending – it’s only the beginning. Now the fun part begins.

Because when the entrepreneur gets close to some potential enterprise customers and they ask about such mundane concerns as security, integration and website customization. Uh, what? Worse, they want monitoring and tracking – as does the entrepreneur since he needs reporting on a per/customer basis to understand sales and site usage.

Only the developers have since checked out – either physically or mentally. They weren’t interested in maintaining the site. Their brilliance is only appropriate to building the site. Too bad they never did any maintenance programming, ever. If they could have seen the brilliance of others their effort may have been the better for it.

Now what? It’s unusual for developers to document well in such circumstances, and the entrepreneur doesn’t read [python, .NET, Java, Ruby], nor is he particularly interested in learning how to read them. Of course he could hire someone who does but then he knows how that turned out.

On the plus side, what the entrepreneur has, is a demo capable website. He can sell it.  And, with luck, it’s a stepping stone to something that will stand up to the heavy traffic required to make a “ton of money.”

The problem is that without an analysis of client needs against the strength of the code he doesn’t know. Even if all is well, he knows he has to take a step back to take two forward.

But all is not well – even a cursory analysis shows that the code is not rationalized on the back end – because there is no back end. All the code is in the equivalent asp/jsp server, meaning that, in the end, testing costs will be much higher for changes than is sustainable. All the website text is embedded in the code which equals the need for changes and that there’s no way to easily customize the site to each customer’s content requests. There’s no service or facility to upload large data sets for the corporate customer. There’s no separation between the primitive reporting interface and the operational data store meaning that every time the entrepreneur wants a report it will impact his site’s performance. Oh, and tokens representing sign-on are sent in the clear, and that’s the extent of the security framework. This, in turn, limits the entrepreneur’s top line revenue possibilities, as larger and more established companies require these issues to be addressed prior to considering a purchase or licensing agreements.

At SenseAgility we’ve seen this pattern over and over. It’s not necessarily wrong – it is even encouraged by the Private Equity community who is more interested in a smaller up-front investment than long-term viability. The entrepreneur does have a functional website that he can sell and that might even support a few customers. But by this time, they have usually invested several hundred thousand dollars into what is essentially a throwaway. Was it worth the investment?

You decide.