Find out how to protect yourself in the
•When presenting a demo, the team of developers doesn’t always have time to show everything down to the last detail. However, conscientious employees will tell you everything in advance so you don’t miss a thing, while unethical people may jumble together the piece of code, as long as it works in some scenarios.
•This approach results in the accumulation of technical debt and difficulties with app maintenance in the future.
•Devs usually say they adhere to standards. However, in reality, few of them stick to this rule. It’s important that the code written by the standards is easier to maintain and use as a basis for new solutions. For example, an application developed on Ruby follows strict guidelines and software design paradigms that ensure better code quality.
•In addition to app development, testing is another main component of a successful final project. However, dishonest developers will only fix the code without performing a full test. This will not only delay the development of the application itself but, later on, multiply the work and costs to refactor or even rebuild the application.
Evaluate developers for your project to ensure that development standards will be met.
•In the early stages of development (especially for startups with limited budgets and timelines), it’s all about functionality and the increase of the user base. In this case, the app development companies often neglect data protection. It turns out that that data isn’t protected well enough or not protected according to the standard. This leads to serious security issues.
•Discussion of every project implies a reference to the examples of previous work. Some app developers may grant access to the staging or even production environment (a replica for testing or the actual live product) of their previous projects to those who were not authorized to see this data, in breach of a contract with previous clients.
•Providing access to infrastructure bears even more threats than the above-discussed situation. Let’s say the team does not have a DevOps specialist and brings a third person in to handle the server, granting them access, SSH keys, and tokens to solve the problem. This person will have access to all the app data which breaks the data security.
•Usually, code reuse is a good practice. There are many pre-built digital solutions, so there’s no need to reinvent the wheel most of the time. There is a good chance that a developer has ready lines of code intended to solve a similar issue (perhaps, it was used several times) or can find ready code lines on the Internet.
•The only problem here is that the developer can use pieces of code that are poorly adapted to a particular product or contain unnecessary elements, which affects the speed and stability of the product. In addition, some of the reused solutions may involve licensed libraries that may not be compatible with others in your app or may have requirements that your app doesn’t meet.
Writing a quality code is a skill. Score the skills of potential developers with the help of our table.
•With tight deadlines, the team may choose a strategy of accumulating technical debt in order to meet those deadlines. In this case, the team uses easy (limited) solutions instead of implementing a better approach, making the application development ill-considered and the long-term outlook more uncertain. This situation can also happen if the team is not qualified enough. This kind of technical debt will hinder adding new functionality in the future.
•When hiring app developers, you expect them to put 100% of their effort into creating a top-notch and user-friendly application. Obviously, the lack of proper quality assurance makes it impossible. Some teams claim to have professional testers. However, in reality, things are much worse and a QA team fails to notice critical bugs or errors. This situation may waste your time and make you spend thousands of dollars on a new QA team.
•During the contracting stage, some teams ask the client to test the application on their own (if they don’t have a specialist on their team). The client thinks that if they thoroughly test the application and no bugs are found, then everything is fine. In reality, the client is not always able to identify errors on their own.
•The right choice of technology can often be critical to product success. Unfortunately, many agencies lack the necessary competencies and simply convince the client to use their technology instead of telling the truth about the technology issue. Having an interview with a senior, working with someone else
•An outsourcing company usually wants to show its best employees at the hiring stage. Sometimes, a client may have an interview with a higher-level developer, while in reality the work will be done by a less qualified employee to let the app developers save resources and money.
•Another common problem may occur when the development team claims to work on your project 100% of the time, but in reality, they won’t dedicate more than 4 hours a day to this work. The rest of the time will be spent by them on another task while your project won’t be touched for days. This usually leads to delays and poor quality in the final product.
•Most likely, the development team promises to allocate senior and middle-level devs to work on your product. In reality, however, every company has non-billable junior employees (or underpaid compared to middle and senior) who perform less complex tasks under the guidance of more experienced colleagues.
•The deception begins when the work is done by less qualified specialists without the necessary supervision. As a result, the quality suffers. For example, the company may assign the task to junior-level developers (or even interns), and the senior specialist will occasionally check the task’s status or will not be aware of it at all.
•Some companies do not always consider informing the client about the departure of team members on vacation, sick leave, or from the company in general. The lack of constant reporting to the client leads to failures in meeting deadlines.
•Due to the lack of professionalism, some teams may not launch the product into work unless it’s not directly stated by the tasks. If something happens to the product, they do not consider themselves responsible for fixing the problem. Of course, this is not what the client usually expects.
•One of the trickiest parts of app development is to make the responsibilities of both parties clear. The developers can’t read minds and don’t always fully get the client’s vision regarding certain aspects of the project. Certainly, not every such case is a deception, but without responsibilities being clearly stated, the client’s expectations may remain unsettled.
•This is why it’s important to agree on the essential terms of the partnership and define what metrics will define your success. Depending on the client’s needs and goals, team’s capabilities, and organization, as well as many other factors, the company should offer several pricing models and contracts that will regulate each party’s rights and obligations, as well as define what the client will receive.
•The development team can assure you that your application will be their priority no matter what. In reality, there are very few teams who willfully get into the details of your product and make every effort to make it a success.
•You can easily detect such a lack of understanding during the communication stage. This happens when developers don’t ask enough questions and provide quotes too early before studying the project’s details and risks.
•Building an MVP with less advanced technology, less scalable architecture or less clean code is perfectly appropriate and sometimes even necessary (if product-market-fit or urgent presentation to the investor is considered critical to future success).
•However, the vendor must ensure a sufficient level of transparency in all matters related to the consequences of such a decision. Very often, developers begin to build huge systems based on a product that is completely unsuitable for scaling. Only when a critical number of users is attracted or further functionality is implemented, does the client realize that the product must be redone from scratch.
•There are also cases when MVPs are purposefully created only for idea validation and investment pitches with no intention for scaling. A professional approach to MVP development is to build a code base that can later be used in a full-scale version without the need for long and painful rewriting.
•Sometimes, teams don’t get into the details of the app requirements and fail to evaluate the risks and blind spots in the development plan. As a result, they usually can’t estimate the project correctly. Some teams will be transparent about the risks or offer to spend extra time preparing the requirements and research. Some other teams will just put big numbers in their estimates and resolve unclear goals during the development.
•When working with small outsourcing companies, oftentimes clients get assured that all key employees will communicate with them without language barriers. In reality, the clients find themselves stuck with a single employee who understands them after the tenth attempt.
•Sometimes, the team promises the client certain results but fails to deliver them. For instance, they may guarantee constant updates about the project’s current state current status, but in reality, they end up with rare updates of the task tracker or score on Gantt.
•That is why it is crucial not only to make your idea and requirements clear from the beginning but also to continue constant communication with the team and be aware of what is going on.
•There are times when the development may take longer than projected. Then, a technically unskilled client may start making edits and suggestions to the backlog. However, in about half of the cases, it doesn’t improve the product at all, quite the opposite. Of course, it’s good when it benefits business goals. Some app developers may silently accept these changes without discussing the scope and new estimates. As a result, the client ends up with overspending of the prepared budget and fails to achieve the originally set goals.
•For a variety of reasons, the team can provide deadlines for the implementation of the project that will later be postponed. It can happen for different reasons unintentionally – the team overestimated their strength, didn’t take into account some risks, or anything else. Therefore, the client should always be prepared that the initial budget will be exceeded.
•The real problem arises when the team does it intentionally, knowing they won’t complete the entire project on time due to the lack of necessary competencies or ignoring the risks. Sometimes, an outsourcing company or freelancer doesn’t promptly inform the client about possible problems or delays.
•Not everyone abides by NDAs. Some companies may easily publish a new project from their portfolio (while the project is still in development, for example) before the moment when it would be allowed under the contract, thereby violating the contract terms.
•In addition to the previous point, more cautious companies may publish hidden portfolios (with projects under the NDA), which they send to new potential clients or partners, where both parties most likely also signed an NDA with each other.
•When trying to create a great application, the development team may use add-ons, plugins, or other third-party libraries without licensing. Most likely it can happen due to the team’s lack of professionalism, unintentionally. However, the product owner may face serious consequences, including lawsuits and fines.
•Access to an application is usually regulated at a legal level. If a team grants access to the data to an unlicensed professional, it can lead to serious consequences (for instance, for HIPAA). Therefore, before starting a collaboration, you should thoroughly check if the team has the appropriate licenses.
Now that we’ve listed every type of deception our clients have encountered, let’s talk about the ways to protect yourself.
will be sent to your email
Outsourcing is a great way to save money, find the right specialist, or fill the gap in your team. If you want your app development to succeed, you should educate yourself on how development companies may
With our detailed list of most common deceptions, you can easily avoid these traps.
Finally, to make the hiring process easier and more productive, you can refer to our most complete guide and find the best developer for your app!
Freelancer vs Agency. Pros & Cons
How & Where to look for developers
26 questions to ask any developer
12 signs of a good and bad developer
Automated Developer Evaluation Matrix
Score every developer and hire the best one!
Developers Comparison Template
Most important decision-making information organized in one place.