1. It is easy to create a custom web or mobile application

Many of our first-time clients know that a fair amount of work goes into building custom apps, but they often underestimate the number of things that need to be done before development even starts.

The common understanding of the flow, and a chart we frequently see at other agencies, is just 6 steps: concept, discussion, design, code, testing, launch. This is extremely simplified and a significant portion of the project is summarized as “discussion”. It also does not show the many iteration cycles involved in a typical custom application project.

EZB has their own workflow diagram as part of their pitch. Their workflow, which includes our Solution Architecture services, is 35 steps. We go far more into detail covering research, the various cycles between discussion, research and reporting, the design iterations and the monthly development / testing / review cycles. Our workflow which includes how we manage our development vendors, can be found on our Solution Architecture page.

Breezing over important steps might be an easier way to present a work-flow but it does not manage client expectations properly. We feel that education is key to managing expectations and ensuring transparency between the vendor and the client.

2. Developers are computer experts

Developers are professionals that have dedicated a significant portion of their life to learning programming languages. Asking them to troubleshoot your Windows error is not the best use of their skill set and would distract them from doing the more important work of developing your application. While most developers will be willing to help a client in need, we do recommend letting them do their job and getting an IT support person to help you with computer troubles.

3. Programming is like it’s depicted in the movies and on TV

As with most entertainment media, the representation of real life activities is often different to how they are in real life. Hacking and programming in TV and media typically involves 3D interfaces, newly developed and untested apps working without any issue at all and coding or hacking being completed in a matter of minutes. Not realistic, but watching someone tap away at their keyboard for 6 hours straight to produce 1 feature of an application would not make for good entertainment. Most software used for programming will colour the code nicely but that is about it in terms of special effects.

4. Things that seem easy must be easy to code

This is related to my 90/10 rule. Clients tend to see 10% of the app with the underlying 90% being a mystery to them. This 90% includes management, back-end code, infrastructure, testing, qa and more but none of this is directly visible to the client. The 10% is the interface that the client can see and work with. A client sees a feature and changing that for the interface part may seem minor but in fact that is just the a tiny part of everything that needs to be changed (and tested) in the 90% to make that feature work as expected.

For mobile apps the time needed increases by a factor of 3 on average. This is due to mobile app languages being more complex than web apps, mobile apps often having different interfaces for different size screens and the number of devices that need to be tested for each change.

5. Developers and graphic designers are UX designers

This is probably one of the most costly misconceptions on this list as it has a very real impact on project scope and timeline.

A developer knows how to code things, but usually does not have an eye (or an interest) for design. For older readers who remember Geocities websites, many of these were the product of developers. Older versions of Sharepoint and SAP interfaces are typical examples designed by developers.

A graphic designer knows how to make print. Logo, branding, business cards, PDF’s and other designs that are generally not interactive and do not move/change once presented.

Using one of these to design your website or web application will typically result in a less than optimal design and need an equal amount of budget again to turn into something more usable for an interactive product.

A UX designer is more technical and has a deep understanding of dynamic and interaction design. They often have hands-on experience with programming languages and a technical understanding of browser and device capabilities. To them a design is a moving landscape with elements affecting other elements and where special attention needs to be paid to how a user flows through a page and interacts with different elements.

A very simple compare example would be an input form for a website.

6. A low hour rate for developer = lower total cost of project

This is something we are confronted with from time to time from prospects that are looking for the cheapest deal. Only looking at the hour rate and not the total project cost is very short sighted however. Always remember, you get what you pay for.

When we talk about total project cost we are referring to the amount paid in total by the time the project reaches the last invoice. Very difficult to predict up-front, sufficiently so that I have been able to build a business around doing exactly this. The difference between estimate and invoice is what we call the risk margin, this is calculated by evaluating vendor, client and project behaviour and specifics. The margin is then added to the estimate to give a better indication of what the total cost of the project might look like.

For example, an established, more expensive local vendor will have a higher day rate, but generally speaking there will be far less communication issues. From a certain price point they will very likely have clear work flows and policies in place to ensure that projects are properly thought out, planned for and researched before hand. The client, or their staff, will need far less hours to manage this type of vendor, incurring less cost on the client’s end. Because of all this, the risk margin added to their estimate will be in the range of 10-30%.

An overseas and less experienced vendor would have a far lower day rate. But miscommunication is a serious risk factor. Implemented requirements may need redoing with considerable structural changes that need fixing and testing again. Vendors such as these will need significantly more time from the client or their staff to manage, support with testing and provide constant feedback and quality controls. The risk margin added to this type of vendor could be as high as 200%.

These risk margins are applied to estimated dates as well as cost. The increased time needed cna delay deadlines and cause a lot of frustration on the client side. The final cost will likely still be higher for the local developer but not by the amount that only looking at a day rate would indicate. Furthermore, the local developer will have significantly better managed expectations in terms of budget and timeline with minimal difference between estimate and actual.

7. The software developer will steal your idea and build it themselves

No, just no. Maybe if you are briefing your idea to a freelance developer-entrepreneur who has no conscience and knows 100% sure that your idea will be the next best thing since sliced bread. Otherwise it is just not worth it for so many reasons.

As a start-up with a new concept you need to talk to as many people as possible about your idea. You need to get feedback and be able to iterate and fine-tune every aspect based on real-world experience and knowledge from those you speak too. This is how good ideas become great ideas with a significantly higher chance of success!