Blog of Raivo Laanemets

I'm often approached by potential clients wanting to build something. Usually they have a vague vision of the final result but not a concrete execution plan to reach it. My job is to reach the successful result but there are always constraints out of my control.

I do not want to drive the potential clients away but sometimes the overhead of arranging and attending meetings is not worth it once I discover that I won't be able to meet some of the project requirements or I won't fit into the existing team. This is a wasted time for both my potential client and myself.

The most common reasons for turning down a project have been:

1. Timeline is unsuitable.
2. The budget is way underestimated.
3. Timezone makes communication hard.
4. Type of technology (desktop, mobile, embedded, etc.) is not my expertise.
5. Gut feeling.

Timeline

The most common reason is a timeline. A project should have a start and an end. It is often helpful to divide the project into shorter periods each with a definite length.

I always have a queue of projects. These projects pass many of the constraints I point out here and often have negotiated deadlines. A single project taking longer than planned is much worse than a project ending prematurely. A project running longer requires re-negotiation of every other project in the queue and forces me to break promises I have made to my clients. My clients will suffer and I do not want that to happen.

Budget

Estonia is not the most expensive country to live in but the difference with Western Europe countries is not 2-3 times, it's more likely 20-30%. The employment taxes are relatively high. On top of the personal income tax is the hefty 33% social tax, increasing the employee cost. Experienced developers are in high demand. Estonia is not a country to find cheap developers. Clients with a certain budget range are preferred. A budget is nearly always underestimated but knowing the budget helps to set expectations. Sometimes low-quality work is expected. This is not something I would like to do.

Communication

A software project cannot be carried out without effective communication. This is especially important in a remote project. Some time ago I had a remote project with a client in US West Coast. I shifted my workday to late hours and she shifted hers to early hours. This was very exhausting and took a heavy toll on the life outside the project. Eventually we gave up on this schedule but important questions had to often wait an answer a day which slowed down the project.

Technology

The choice of the technology is often more important in short projects. There is enough time in a 3-year project to learn whatever language or platform but you can't realistically create a mobile app in a week if you haven't built any before.

Couple of years ago I worked on a desktop application. We chose Qt as the application framework because it was cross-platform and had a suitable free license. Qt uses C++ and C++ is a complete beast to learn. I had no experience with C++. I was able to get the initial prototype out in 3 days by copy/pasting together source code from examples. In the following months I picked up proper C++ and added all those const qualifiers I had missed before.

One of my clients needed an Android app recently to be done in a week. I thought I give it a chance. I spent 3 days trying to install Android development tools. I always got some weird errors. Once I got it running the emulator turned out to be extremely slow and useless. The time pressure did not help either. I had to admit defeat. The project would have been doable in the timeframe by someone knowing the tools already.

The choice of the technology is also important for longer projects to ensure project continuity. Example of a such negative choice would be Flash which is currently being removed from browsers and is completely dead in 1-2 years.

Gut feeling

I must be able to envision myself using the product or service, getting a great value out of it. Is it actually possible to accomplish it given all the hard constraints? That is the ultimate indicator for me.

Throughout the career I have had only a single client who gave me too much information. Every day I received 3-4 page essays containing bug reports, weekly plans, long term future plans, what-if scenarios and dreams all mixed together. In every other case it has been the opposite.

Business ideas

I'm careful about discussing business ideas. Ideas are considered worthless but frequently the client has some existing business tied to the idea. The existing business can contain crucial details that are important for the project's financial success. These details are trade secrets and the client should not be put into a situation where these are to be accidentally revealed.

A not-go decision for a project does not mean that you should reject the client. I have had clients with multiple projects and I have proceeded with some and turned down some others.

Simple questions

Some time ago I was studying a frontend framework and wanted to make an app with it. I decided to make an app asking questions about a potential project. It is available here. Using the app does not mean you have to work with me. It contains simple questions with yes/no answers and does not ask anything about your business idea. You get a shareable link with the answers and a downloadable PDF file.