27 Ways App Developers Deceive
Their Clients and How to Protect Yourself

Find out how to protect yourself in the FULL VERSION.

arrow 1 1 1 development

Technical Situations

#1 Cheating on the demo

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.

#1 Cheating on the demo
#2 Disregard for development standards

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. 

#2 Disregard for development standards
#3 Security: Access to critical data is not protected well enough or not protected according to the standard

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.

#3 Security: Access to critical data is not protected well enough or not protected according to the standard
#4 Security: Granting unauthorized access in breach of a contract

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.

#4 Security: Granting unauthorized access in breach of a contract
#5 Security: Providing access to infrastructure

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.

#5 Security: Providing access to infrastructure
#6 Careless reuse of code chunks

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.

#6 Careless reuse of code chunks
#7 Accumulation of technical debt due to ill-considered and rushed decisions

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.

#7 Accumulation of technical debt due to ill-considered and rushed decisions
#8 Poor testing

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.

Find out how developers execute efficient tests.

#8 Poor testing
#9 Substandard testing: When the client is offered to conduct testing

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.

#9 Substandard testing: When the client is offered to conduct testing
#10 The choice of technology is not based on the project’s needs, but on the skills that the dev team has to offer

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

#10 The choice of technology is not based on the project’s needs, but on the skills that the dev team has to offer
#11 Interview with a senior, work 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.

#11 Interview with a senior, work with someone else

Resources

#12 Deception with the workload

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.

#12 Deception with the workload
#13 Deception with the seniority level of developers

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.

#13 Deception with the seniority level of developers
#14 PM is not transparent about resources being spent on the project

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.

#14 PM is not transparent about resources being spent on the project
#15 Putting the product into operation can be under question

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.

#15 Putting the product into operation can be under question
#16 Development results don’t match the client’s expectations

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.

#16 Development results don’t match the client’s expectations
#17 Understanding the customer and the product

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.

#17 Understanding the customer and the product
#18 Creation of MVP with a limitation for further scaling and not informing the client about the consequences of such a decision

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.

#18 Creation of MVP with a limitation for further scaling and not informing the client about the consequences of such a decision

Management & Communication

#19 Overestimation

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.

#19 Overestimation
#20 A language and cultural barrier, though they assured there was none

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.

#20 A language and cultural barrier, though they assured there was none
#21 Lack of transparency about the project status and provision of results

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.

#21 Lack of transparency about the project status and provision of results
#22 Manipulation of estimates

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.

#22 Manipulation of estimates
#23 Provision of unclear deadlines or purposeful underestimation

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.

#23 Provision of unclear deadlines or purposeful underestimation

Legal Situations

#24 NDA: The portfolio with the NDA project is immediately published

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.

#24 NDA: The portfolio with the NDA project is immediately published
#25 NDA: Hidden portfolio with NDA projects for new clients

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.

#25 NDA: Hidden portfolio with NDA projects for new clients
#26 Using add-ons, plugins, and libraries without a corresponding license

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.

#26 Using add-ons, plugins, and libraries without a corresponding license
#27 Security: Providing access to unlicensed specialists

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.

#27 Security: Providing access to unlicensed specialists

How Do You Protect Yourself?

Now that we’ve listed every type of deception our clients have encountered, let’s talk about the ways to protect yourself.

27 Deceptions & 10 Ways to Protect Yourself

will be sent to your email

ios-app-development-company

Conclusion

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 deceive you and avoid these problems.

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!

27 Ways App Developers Deceive Their Clients
Jetruby guide

The MOST complete Guide to Finding 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

bonus gift

Automated Developer Evaluation Matrix

Score every developer and hire the best one!

Developers Comparison Template

Most important decision-making information organized in one place.

JetRuby: Leading Software Development

12 years on the market

250+ accomplished Apps in 16 niches

58%
annual growth

Clients from 24 countries

100+
in-house engineers.

29%
Senior+ level.

ISO 30414 (Human Capital) and ISO 10018 (People Engagement standards) Compliant

We are experts in:

27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
27 Ways App Developers Deceive Their Clients
SOC 2 AWS

Jetruby Academy

We run quarterly courses on Ruby on Rails, React.js, iOS, Android, Quality Assurance, and Product Management.

Let's build great things together!

By submitting request you agree to our Privacy Policy