Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta

Entries in startups (19)

Wednesday
Jul042007

Selling your mISV (the PeopleWords.com case)

Anthea has just acquired PeopleWords.com. PeopleWords was my first mISV project. My efforts being invested in a more ambitious project (namely lokad.com), I was not able to push PeopleWords any further. Thus, selling was a natural option.

This post is a modest attempt to gather the few noticeable elements about this experience.

Auction websites do not work


There are places (ex: eBay, SitePoint) where you can sell websites through auctions. I tried, and in the end, it was pure waste of time. Basically, those auction websites are overwhelmed by people trying to sell turnkey websites (ex: web forums about some random topic). As a result, the only thing that comes into the price equation is your traffic; no matter if your website is driving Venture Capitalists or Paris Hilton fans. Unless, you are trying to sell some social networking web application, I would really suggest NOT to go for auction websites.

Contacting the right people might have work


Making direct proposals to the "right" people to buy your business might be a good option, especially if you are doing B2B. For PeopleWords, the task was looking time consuming (there are too many big translation agencies out there). Thus, I did not even tried that one. Although, I think this approach could have been effective nonetheless (but I can't tell for sure).

Putting a "For Sale" sign on your website does work


I have been hesitating one month about putting a "For Sale" sign on the front page of PeopleWords. I was wrong to hesitate, the sign proved to be very effective. I was wondering if the sign could negatively impact the business that I was precisely trying to sale. It turned out that the sign had no tangible effect on the business operations. Yet, within a few weeks, I had received half-a-dozen of offers from people that seemed to be genuinely interested.

You do not sell a mISV, you sell a business plan


Being the sole author of PeopleWords, the main concern of the potential buyers was to know whether PeopleWords had any value without its founder (i.e. myself). At this point, I was no more selling a website, but I was selling a business plan tailored to the profile of the potential buyer. Basically, two points that had to be detailed were: PeopleWords can be maintained and extended without me - PeopleWords can leveraged through the buyer business (and vice-versa).

Saturday
Jun162007

Screwturn powered front-end for your mISV

I have just finished to migrate all the web content of Lokad.com into a brand new skinned Screwturn wiki instance. Thanks to the design skills of Sergey Pozhilov, the result does not look bad :-) .

I have been writing about wiki misuses in the past. One of my recommendation of at the time was do not use wikis for public diffusion. I still believe that this recommendation is a good one (even highly popular forums have hard time to get anybody contributing to a wiki). In fact, even if Lokad.com is now hosted in a wiki instance, the accesses have been restricted to the Lokad team. Thus, we are using Screwturn as a CMS and not as a wiki.

This migration was the 3rd step:

  1. At first, the Lokad web application and website were mixed. As a result, it was taking as much effort to update the web application or the website. The situation was just painful by design.

  2. Web application and website have been separated. The website was now regular static HTML. The update overhead was still significant, FTP being just a pain when it comes to fix typos.

  3. We have hired a professional designer to get a decent XHTML skin and then we have migrated the web content into a skinned Screwturn instance. The update overhead is now super-low.

Do not break URLs: When migrating your web pages, it's important to include the proper redirections. I have been using UrlRewritingNet, a nice open-source URL rewriting tool. UrlRewritingNet is very convenient to migrate ASP.NET pages because ISS does not intercept the requests even before they hit the ASP.NET machine.

Benefits of the Screwturn CMS for your mISV


I have been relying on a CMS for 48h to manage Lokad.com, I do not think I am ever going to move backward toward a static HTML again.

  • wiki markup is more compact and more readable than HTML. Page editing becomes easier and faster. Ok, most wikipedians have been knowing that for ages, but I would expect the percentage of websites relying on compact markup to be still quite low.

  • snippets are really convenient for website templating. The concept is both simple and powerful. After going through 70 web pages, I find snippets way more practical than ASP.NET master pages.

  • spell checking is native because Firefox becomes your IDE. Visual Studio should have been supporting spell checking for ages, meantime you can still use CodeSpell.

  • native user accesses management simplifies the task of integrating external contributors, typically professional translators, writers or proofreaders...

Scripting tricks for Screwturn


When it comes to skinning an ASP.NET application, the goal is to change the minimal amount of lines of ASP.NET code (optimally zero) during the skinning process. This process ensures that upgrading toward the next version of the ASP.NET application will be painless. Thus, I have been resorting to a couple of client scripts to avoid touching the ASP.NET code.

The search box is using

<a href="javascript:document.location = 
'Search.aspx?FullText=1&Categories=&Query='
+ encodeURI(document.getElementById('TxtSearchBox').value);">search</a>

The Edit and History links are using

<a href="javascript:document.location = 'Edit.aspx?Page=' + encodeURI(
document.location.pathname.substring(1,document.location.pathname.length - 5));">Edit</a>

<a href="javascript:document.location = 'History.aspx?Page=' + encodeURI(
document.location.pathname.substring(1,document.location.pathname.length - 5));">History</a>

Finally, the navigation tabs rely on a small script dynamically adjusting the CSS classes.

<script type="text/javascript">
var navItem = document.getElementById('HomeTab');
navItem.className = 'active';
</script>
Thursday
May312007

Buyer's guide to development outsourcing

Outsourcing parts of your IT developments can be highly cost effective. While running Lokad.com, I have outsourced most of the work for 3rd party connectors (23 of them at the time) and I am considering the outcome as more than satisfying since I would never have achieved the same amount of work without outsourcing, considering comparable delays and financial investments.

This document is a small guide for mISV or ISV that might be willing to go freelance too. May this document help you to avoid my early mistakes.

Getting freelance proposals


Finding freelancers is easy, but being a good freelance manager is hard. Indeed, you have plenty of open freelance websites. I have been using Guru.com and GetACoder.com (among others), but I think that the freelance website has a very limited impact on the outcome of your outsourced projects. Just stick to freelance websites with significant traffic and it should be OK. Do not ever accept to pay anything upfront to post your job, you would be wasting your money.

Multi-posting is cheap, I suggest not to hesitate to cross-post your job descriptions. It requires a bit more work to keep track of all your postings but it increases the amount of proposals that you get. Since you are going to navigate within tons of websites, proposals, coder profiles, I suggest to create some bookmark repository to manage the whole process: a non-public wiki page is perfect for that especially, if you work in a team. Having 100 proposals is not an issue, you just need the right sorting algorithm (see next section).

Disclose your name and your company. Usually the freelancer gets paid at the end of the job. Thus, the freelancer is taking the risk of not getting paid. By disclosing your name and your company, you are reducing risk, in the opinion of the freelancer, of not getting paid. Anonymous job posting are just more suspicious; and the freelancers are going to charge you more based on that suspicion.

The job must be factual and non-ambiguous. Writing a good job description is hard, especially if you want it done quickly. The first paragraph should be a Job overview. In 5 lines or less the freelancer must know whether this job match his technical skills. It's really important to list all the technologies, languages and tools in this section. If that list can't fit into 5 lines, then you should consider splitting this job into smaller ones. The comes the Delivery section. This section is the exhaustive list of all the documents that you expect to be delivered by the freelancer and the end of the job. Do not forget to specify the formats and possibly the encoding. At the end, the extensive description and your requirements should be found. Notice that this order is respecting the inverted pyramid principle.

Make the job as much stand-alone as possible. Taking over a job can be a significant investment for a freelancer if he has to get familiar with your tools, your own software libraries (worse, your home-made programming language). The freelancer is going to charge you for this take-over investment. Thus, if you want to save money, make the job as much stand-alone as possible. Often it means that you ill handle yourself the integration of the delivered code into your systems.

Go for small jobs (no more than $1000 at once). The larger the job, the more uncertainties; thus it's better to stick to small jobs. First, freelancers are only paid at delivery, thus they will not accept to commit themselves to bigger jobs without being paid upfront. Then, if it's safer on your end to be able to make adjustments along the way like changing of freelancer (if the one you picked does not match your requirements) and/or adjusting your requirements.

Suggest reasonable price and delay. Although, it might be a bit counter intuitive, suggesting a reasonable price is actually a good way to lower the final price. First, it sends a signal to the freelancer about the scope of your job. The worse situation for a freelancer are the ill-defined requirements that leave a large latitude in the workload estimation. By helping the freelancer to make his workload estimation, you are decreasing the job uncertainty and thus, the price associated to this uncertainty.

A question at the end of your job description. This question should be factual and related to the job itself. The purpose of this question is to facilitate your choice when you will be sorting out the dozens of proposals that you did get for the job. Basically, you can discard all the proposals that do not start by addressing your final question. Indeed, if those freelancers did not even bother to read your job description until the end, trusting the job in their hand is a bad idea anyway.

Choosing the right freelancer


Do not trust ratings for IT projects. Many freelance jobs are actually home works submitted by US students. Since 1st year college home works do require much skill (think of Hello World style exercises), many poorly skilled freelancers ends up with tons of positive ratings. Also, non-technical people submit loads of trivial IT jobs like converting CSV data into Excel data. I mean "trivial" for IT professionals, not for your Uncle, the divorce lawyer, who is also buying IT services occasionally. At the end, I have found that positive ratings aren't reliable for coders.

Discard cut and paste proposals. A lot of Indian companies (well, not only India in fact, they just tend to be more visible) are just cut-and-pasting generic proposals. Those companies do do not even bother to read your job description, and automatically propose a random amount for your job (typically $2000). They also tend to send you a private message (cut-and-pasted as well). Spotting those proposals is easy. Do not even bother to read their long stories about the 1000 satisfied customers. Choosing such a company is only asking for trouble. To be discarded at first sight.

Go for specialists. A lot of freelancers go for the "Jack of all trade" strategy and submit proposals at random no matter the technology (PHP, Java, C#, C++, ...). In my experience, the best freelancers are those who are heavily specialized in a few areas; even better but it's rare, the freelancer who's an expert with a list of applications (like Oracle 5 to 10). The cost of outsourcing is highly dependent of the final productivity of the selected freelancer. More specialization means shorter delays and increased code quality.

The country has no importance. The "right" person can be anywhere, including the "expensive" countries. As stated previously, the price depends heavily on the final productivity of the selected freelancer. In my experience, productivity easily varies of one order of magnitude between specialized and non-specialized developers. Skills matter, countries do not as long as people are fluent in English.

Go for independent freelancers. Outsourcing companies just complicate the process without adding value. The company is just another communication layer: you get a "manager" between you and the "coder". If the requirements need to be adjusted along the way (it happens often for the fine-grained detail of the job), you have to negotiate with a manager who do not really understand the problem, because he is not in charge of the job and then re-forward the decisions to the coder. Worse, all the good freelancers realize quickly that an outsourcing company on top of their head is not adding value but eating a significant part of their lunch. As a result, the best freelancers are always those who work for themselves. Do not get fooled by pretty websites of outsourcing companies. At the end, the only thing that matters is the skill of the person working for you.

Probe freelancer responsiveness. Once you've cornered a small set of interesting offers, I suggest to probe the "responsiveness" of those freelancers. Most freelance websites provide some sort of private message system. Just a send a private message (raising a question about the freelancer proposal for example) to see if you get an answer within a short delay. In my experience, discard any freelancer who can't respond to your message within 24h. Responsiveness is a key of effective freelance works, if you can't even get an simple answer like "I am too busy right now, give me 48h", then the chance to get the job done are low.

Managing the freelancers


Outsourcing must be part of your strategy. Managing freelancers take time and skills. Taking the "right" strategic decision can significantly simplify your outsourcing processes. For example, at Lokad, we have put released all our 3rd party integration components as open source. Disclosing this source code is not an issue since it does not impact the Lokad core business. Yet, in terms of outsourcing, it significantly simplifies the process. We do not need to transmit any access codes to freelancers, everything being readily available. Furthermore, it facilitates price and delay estimation on the freelancer side. Open source is only one option among others; but keep the idea in mind: a lot can be done to facilitate 3rd party developments without damaging your core business.

Anticipate a high failure rate. A lot of things can go wrong. You might realize that the freelancer do not have the required skills. The freelancer is bidding on many jobs at once and takes other commitments after bidding on your job. Your job description was ambiguous. etc... Anticipating a 30% failure rate while hiring a "new" freelancer is not unrealistic. Yet, a 99% reliability would cost you x10 more; thus it's a trade-off between acceptable risks and costs. Part of the reasons that make outsourcing cheap is because nobody takes strong commitments.

The infrastructure has to be ready. There are tons of tools that facilitate remote freelance works: source code manager, bug and feature tracker, open forums, etc... This infrastructure has to be ready before you actually start to look for freelancers. Otherwise, you and your freelancers will end-up wasting a lot of time on mundane communication details.

Strong IT skills are required. You must be able to do what you are asking from the freelancer; at least potentially, if the time was given to you. First, if you're not an expert yourself, you will not be able to write an "efficient" job description that include the necessary technical details. Second, the freelancer is going to raise very technical questions on the job (like "What encoding do you want?"), if you are not able to answer, then the whole process is in trouble because even the smartest freelancer does not know the exact technical requirements of
your business.

Be super responsive. Remember that most of the time, when the freelancer is raising a question, it's because he is stuck. In order to move forward, he needs your answer NOW. Making yourself available through your favorite Instant Messenger can greatly increase the speed of your freelancer. Worse, if you're slow to answer, the freelancer might be tempted to start another job because, you're not keeping him busy (wasted time = wasted money) and this is not going to improve anything for your deadlines.

Nights and week-ends do not count. Most of people in the world do not live in the same timezone as you do. Thus, your "business hours" are completely irrelevant when it comes to freelancing. Also, many freelancers do have a part-time or full-time jobs already and wants to make some extra money during the week-end. In my experience, those people tends to be among the most skilled and efficient freelancers. Yet, those people are working the weed-ends. The "super responsive" condition applies 16h / day and during week-ends too.

Source code must be proof-read. Never trust delivered code without proofreading it. Proofreading takes time, but not doing it is asking for trouble because the freelancer will not be there to answer your questions once the job is closed. First, you must make sure you understand the delivered code entirely (see point below); but you want also to make sure that your coding guidelines are respected and that all the job requirements are met.

Ask for code comments, re-ask for code comments. Once the job is closed, the freelancer is gone; leaving you alone with the delivered source code. As a result, the source code must be heavily commented in order to be sure that the code can be maintained at a reasonable cost. Yet, the code comments somehow conflict with the freelancer goal get it done as fast as possible and move on. Thus, you have often to put some (limited) pressure to get source code comments from freelancers.

A formal testing process has to be devised. If unit testing is possible in the context of your job, then go for unit testing. Otherwise, make sure you that you have a formal way of to validate the delivered source code. If the validation/testing process is manual and tedious, you can include it as a part of the job description. For example, I have often asked the freelancers to provide all the necessary screenshots as a part of deliverable elements.

Once the job is done, pay immediately. Depending on your business, several weeks of delay for a payment might be acceptable. Yet, for online jobs, several weeks is a HUGE delay. As a rule of thumb, freelancers expect to be paid in less than a week. In this respect, instant payment systems (like Paypal) are usually quite appreciated by freelancers (at least for those who have access to Paypal in their country). Being a fast payer is important for the freelancer, delaying the payment for weeks will significantly reduce your chance to get this freelancer working for you again; especially if the freelancer is talented.

Wednesday
May232007

Get your TCO assessments right - fight the urge for home-cooking

TCO stands for "Total Cost of Ownership". The concept has been known for decades, yet when it comes to software, even IT professionals have real difficulties to make correct TCO estimations. It's true that software TCO is a difficult task: first, it's really hard to compare products especially if the products involve hundred of features as it is usually the case, second, TCO heavily depends on the way you are actually using the product, MS Excel has an excellent TCO if you want to make some personal budgeting operations, but the TCO would be abysmal if you would try to use MS Excel as an accounting system for your mid-size company.

An issue that I have often encountered in software companies is, what I would call, the urge forhome-cooking; home-cooking always taste best, no matter the actual skill of the cook, but you can't really criticize a relative. Unfortunately, home-cooking usually costs way more than industrial food as soon as you stop considering that the cooker time is just free.

Is your IT company a victim of the home-cooking syndrome?

Typical symptoms include
- Hey, let's recycle this old PC into a server. Unfortunately, the machine resources are too low for Windows;
thus, you switch to Linux. Then, you start having hardware issues; after all, it's an old PC, what did you expect. At the end, you spend 4h/week just taking care of the old PC. TCO = more than 800 EUR a month, probably twice the price of a new PC.
- We have an home-grown FOO solution. Replace FOO by keywords like compiler, programming language, accounting, time-tracking, billing-tracking, email management, CRM. All sort of things where cheap on-the-self software solutions exist anyway. Software companies are really weak against this because it's fun to start a new project but the costs are just terrible.
- We need to hire someone to manage our systems. In software companies, practically anyone has the skill to manage applications, plus the market cover 200% of the needs for software companies. If you start needing full-time people dedicated to your IT
infrastructure in your less-than-20-people-mISV, then something is wrong.

In order to reduce the IT infrastructure TCO, the most efficient solution that I have found so far consist in migrating to hosted & managed solutions whenever possible. For example, instead of building your own Subversion server (cost = 10h at setup + 2h / per week for maintenance) just go for hosted-projects.com (cost = 10 EUR per month or so). More to come on the subject, stay tuned...

Monday
Apr232007

Minimal back-office for your eBusiness

I have been running two eBusinesses (namely PeopleWords.com and Lokad.com) and back-office systems play an important role in your business.

Basically, there are 3 unavoidable elements for any eBusiness back-office

  • Account & User deletion
  • Error logs reporting
  • Business oriented dashboard

Account & User deletion: IT'S THE LAW, well, at least in Europe, but I suspect that many other countries provide similar laws, rules or guidelines. Intuitively, if a user who has just created an account asks for a deletion of his account (including all the user-related data), complying is a legal requirement. For example, I have been asking for months the people of StrikeIron to delete my account (mostly because they keep pinging deprecated Web Services URLs of Lokad that do not exist anymore); but they never complied so far. I am not going to sue them for that, but I would suspect that they simply never implemented the delete account feature in their back-office.

Error logs reporting: Running your application on your own web server has a huge advantage: collecting the exceptions that are thrown on your web server is mostly trivial. Many tools (such as ELMAH) can be deployed within hours to provide efficient error logs reports. Exceptions are not the only kind of bugs that your visitors can encounter, yet, it's so easy to keep track of them that you must not disregard such a cheap way of detecting bugs.

Business oriented dashboard: It exists many generic web analytics tools ranging from raw webserver logs to sophisticated user tracking system. Yet, when you design a web application, those elements are most probably going to be only a rough estimate of what your users are actually doing. Indeed, it's often much more interesting to design simple (yet highly specific) indicators that reflects some key aspects of the usage of your application. Those indicators could be critical to quickly estimate impact on a web marketing campaign.