For some time now, I have been using a service called Happy to perform remote web coding.
”Happy” is a suite of tools that runs on both computers and mobile devices. Through this service, I can use my phone to connect to the programming terminals on my computer, specifically Claude Code and the Codex editor. This setup allows me to easily access and utilize these programming tools even when I am away from home.
As of today, Claude has released a new feature called Remote Control. This functionality allows users to control Claude Code directly within their own apps.
This new first-party native feature has immediately caused me to lose interest in continuing to use Happy. Because the native method is more convenient and offers better performance, it has sparked a reflection: should we really be developing peripheral features around the products of major corporations and tech giants?
Standing on the shoulders of giants.
Developing peripheral applications around mature products to fill gaps in their functionality and mechanics has historically been a very good idea.
The reasons are as follows:
- It is a validated market. You don’t have to worry about whether the demand is fake, as users genuinely need these features.
- There is lower risk. Because you are operating around a mature platform, you don’t have to worry about investing significant time and effort only to end up with nothing.
- These products typically have established charging and subscription mechanisms. Since they have already completed the process of educating users on how to pay, the resistance you face when implementing commercial monetization will be much lower.
Speaking for myself, I have had a similar experience. Several years ago, I found that GitHub’s star management was not very user-friendly. The official platform only provided a very rudimentary API and user interface, making it difficult for me to accurately search for or review repositories I had already starred.
To solve this problem, I developed an application called StarOrder. While it wasn’t a massive commercial success, it was certainly appreciated by many users, and I personally find it very comfortable to use.
“Gul’dan… what is the cost?”
I’ll start with my own experience. In its early years, StarOrder worked and operated quite well. This continued until GitHub’s official team recognized the gaps in their own star management. They gradually improved their management page, providing a richer API and a much better UI.
This eventually made my development of StarOrder meaningless because the official solution became good enough. Since the requirements for such a tool are quite limited, it became very difficult to continue discovering or expanding its features.
Returning to the broader reality, developing software around tech giants is an inherently risky move for the future. Many missing features are only temporary; the giants simply haven’t invested the time or energy to fix those details yet.
When their products are growing rapidly, they focus 100% of their energy on areas that drive user growth and generate more revenue. While this leaves some opportunities for us, once that growth plateaus or reaches a certain scale, they will inevitably look back and fill those gaps or flaws. For small developers building around these “titans,” that shift can often result in a fatal blow.
To give another example within the Apple ecosystem, their Notes app used to be a very primitive and simple application. I saw more than one developer attempt to enhance it by adding Markdown support, syntax parsing, and better highlighting for attachments and code.
Over the past few years, as iOS versions evolved, Apple gradually integrated these features as native, first-party enhancements. This leads to my main point: when we build tools on the shoulders of giants to fill the gaps we perceive, we lack a true “moat” for our business.
If the giant shifts even slightly, you might fall off completely. Reflecting this onto our business logic:
- Our product lifecycle is entirely dependent on the strategic roadmaps of these tech giants.
- An even more ironic point is that the more useful the feature you develop around their ecosystem is, the more likely you are to be eliminated as they notice and eventually Sherlocked your functionality.
After all, development and life must move forward.
My personal philosophy is to focus as much as possible on developing original content, rather than exhausting too much energy on filling the gaps left by tech giants.
For small developers, I believe this is a much better path for long-term growth.