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.
- The developer wants to ensure security and to minimize the potential for errors. They will create a form using basic browser-native elements with checks to ensure that the user inputs the data in the correct way. No custom design will be applied because that does not add value to the main purpose of getting data. The image upload form will only accept images in the specific type and size that the application needs. For date form the user will have to input a date in a specific format. If the user fails to fill in a field correctly and submits the data they will get an error message and will have to fill out the form again because tracking submitting data and putting it back into the form could present security issues. As the developer used basic fields with no custom design or layout, the form works quite well on mobile devices with smaller screens. It is not intentionally built responsive but its simplicity resulted in it being responsive.
- The graphic designer will design a beautiful looking form using standard fields but with a custom design applied to them. A font type, size and colour is selected for best readability. As the graphic designer cannot do programming the design will be implemented by the developer, so the date field still requires the user to input a specifically formatted date and the image still requires a specific type and size to be uploaded. Errors are displayed in a nice error message popup but the user still needs to fill out the entire form again after an error. Due to the custom design and layout created by the designer the form has a fixed sizing and is not responsive. Mobile users on smaller screens will have trouble using the form and will have to scroll the page around to find all input fields.
- The UX designer will first look at how they can make it as easy as possible for the user to input data. They will also factor in that the form needs to be responsive and work on all size screens and devices. They will create a design that incorporates dynamic elements. An option selected in field A will cause a hidden field C to be displayed for example. This will make the form smaller as only fields need to be displayed that the user needs to fill out. Their focus can be kept on the essential parts relevant to them. For the date field the UX designer will implement a mini calendar so the user can simply pick a date. For the image upload the UX designer will create a resize and cropping popup as well as image type conversion and automatic resizing. This will allow the user to upload almost any image and not have to worry about resizing images on their end. Errors will be displayed before the form is submitted through client-side validation and auto-formatting. This means that the user does not need to fill out the entire form again. Even better, the field that has the error will be highlighted so the user knows where to look.
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.
- Development agency business models revolve around continuously finding clients that need development services for a project. If they steal a client’s idea this will be terrible PR and they will have a lot of difficulty finding new clients.
- Clients usually think their business idea is the next best thing. That is understandable, they are emotionally and often financially invested in their concept and they need to be 100% onboard and optimistic about it to push it to success. It takes an incredible amount of work to build, launch and grow a business. Not everyone will share that enthusiasm so risking everything in stealing an idea without any guarantee it will be a success just does not make any sense.
- Most developers are generally quite creative and will often have many ideas of their own that they probably feel are much better ideas than the client’s. If they had the time and inclination to develop a business it is far more likely they will develop one of their own ideas.
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!