Programming languages, legal requirements, rules of mobile marketplaces, evolving preferences of your target audience, or neverending tech advancements. There are numerous external circumstances and dependencies in which your product exists. Some you might control; others are out of scope. This article discusses how to successfully navigate through challenges that might jeopardize your product development and limit your maneuvering space.
Products don't exist on deserted islands, nor in a vacuum. They live in ecosystems of other products – be it browsers, app stores, operating systems, programming languages, and even hardware. Many of these have their own agenda that can be beneficial or harmful to your product over time. Let's call them dependencies or reliances. How do you mitigate risks and maximize benefits?
Know your target platform and follow the rules
The chances are that your product will target either mobile platforms, web platforms, or both. While the web is relatively under your control, it's a different story with mobile apps. Let's dive into it.Websites and web applications don't go through approval processes and don't have to meet requirements set by tech dependencies/authorities. You can deploy them immediately once you have all resources and don't have to wait for a green light from anyone.On the other hand, rules and prerequisites for mobile applications can be pretty harsh. Each app version must go through an approval process that might take several days. It's frustrating to see the app stuck under review for numerous hours, especially when the release or update is time-sensitive, so always remember that this can happen.Furthermore, marketplaces have their own guidelines that are evolving over time. If your app doesn't comply, you probably won't be able to push a new version, and in the worst-case scenario, your app can be deleted. Some missteps might not be recognized at first, but that doesn't mean they will be overlooked later. Are you aware of new requirements like the "Sign in with Apple" button, privacy prompts, or the necessity to have a way to delete a user's account right from the app? If not, you might run into problems.As a product owner or a developer, don't ignore these arising conditions and be ready for changes that will occur and affect your roadmap.Also, if you plan to expand to other platforms and different devices, be aware that you will have to meet all the new rules. A great example might be a navigation app that you want to push from the mobile environment to cars. Each platform has an entirely different pack of guidelines that you must follow.
Choice of the programming language
When choosing the programming language, there are two main aspects – suitability for the job and people/developers you have at hand. I see people as the more critical factor. Why? Product future is unpredictable, but you might want to scale up teams quickly if you succeed. However, if you choose some obscure language that might be perfect for the task but no one is using it, you will have a bad time finding new experts for your team. My advice here is not to restrict the talent pool by opting in for rare solutions.Language itself is an important aspect, but our golden rule is that often you will be just fine with several general-purpose languages like C#, Java, etc., that are widespread and sufficient until you need to really optimize and tweak some specific cases. Even then, reflect if you need to write the whole thing in a particular language or just some small part.Of course, these points don't apply only to languages but also to frameworks and other technologies. Your strategy should always be to limit any negative consequences to your architecture.
Adopt new technologies right away, or not?
IT is evolving rapidly, and you can spot interesting new technologies on the market every day. Does that mean that you should jump on every trend you identify? We don't think so. New technologies are risky because they can suffer from issues that proven and tested solutions don't have. The community must widely adopt the technology. Otherwise, no one guarantees its long-term survival.Updates are another topic. Often security and bug fixes come all in one bulk with new features. That means you can't incorporate only things you would like but the whole package. That brings the risk of incompatibility and further adjustments that result in additional unexpected work.How do you avoid setbacks? Get to know every technology you use. Find out more about the author, lifespan, regularity of updates, community adoption, and even alternatives. I recommend making a proof of concept, and if you decide to use the tech in production, have a plan B and be ready to abandon the ship to avoid unnecessary costs.
Open-source, the good and the bad
As developers, we can make our work significantly easier by using open source packages and tools, and it's a common practice. Since open-source is booming these days, there's usually not just one solution to the same problem. That is great because when one solution isn't sufficient anymore, with the right and flexible architecture, it might be easily replaced.It's terrific to speed up the development process but let's not forget that every package, every tool you use has its own dependencies and strings attached. You can't control them nor replace them. So if one of them gets obsolete, you must wait for the direct dependency to take action.Currently, I see the JavaScript ecosystem as the most unstable one regarding the open-source packages available. It's one of the most popular ecosystems, and many people want to contribute. However, their passion doesn't last for long, and therefore there's a massive amount of packages that haven't been updated for quite some time. Unfortunately, open-source can also be used for malicious attacks.To limit these risks, look for dependencies backed by a community, not just individuals. The passion of independent developers is great but doesn't last forever. Open-source projects that generate income for their owners are likelier to stay updated and relevant than a bedroom college project.
Conclusion
Building a digital product free of any dependencies is almost impossible. Pursuing complete autonomy is expensive, complicates future maintenance, and slows you down. On the other hand, adopting new practices at the speed of light and not caring about strings attached is not the way either.The main takeaway is to think about the consequences of technical choices and the broader context. Platforms have rules, languages must have communities around them, technology evolves and dies, and open-source isn't the ultimate answer to everything. Your backlog will accumulate refactoring tickets and unwanted features over time. Don't treat them as low-priority tasks because growing technical debt can easily harm your business.
Reach out to get more information.
Jakub, CTO
Read more about security for IoT device: https://www.designrush.com/agency/software-development/trends/iot-security-issues
