Source note: This post is my written adaptation and summary of ideas from Phillip Choi’s video, “How to actually make money in Tech in 2025”. I rewrote the material in my own words and adjusted the framing and presentation, but the core structure and several examples are based on the original video.
In 2026, if you want to work in tech industry, especially if you are a junior developer, you can’t just grind the tutorials at night, apply everywhere and wait for the jobs to come.
The tech industry has fundamentally shifted in a way that most people haven’t realized yet. I’ve just started working in this industry for more than a year since AI technology booming, and there are three most crucial changes that is happening right now.
AI integration has erased entry-level coding roles: the need for entry level jobs. Company used to hire junior developer to build simple, basic features now uses AI instead.
The traditional hiring system is broken today. Job boards are flooded with thousands of applicants for ghost posts or performative listings. High-value roles are secured internally or through network long before reaching the public.
Broad, generalized knowledge no longer commands a premium. A developer with one year of deep, hyper-focused experience routinely out-earns a generalist with five.
flowchart TD
A["Application"]
A --> B["Authentication"]
A --> C["Profile"]
A --> D["Chat"]
B --> E["Reusable Core Modules"]
C --> E
D --> E
E --> F["Client A"]
E --> G["Client B"]
E --> H["Client C"]
classDef app fill:#f8fafc,stroke:#475569,stroke-width:2px,color:#0f172a
classDef feature fill:#eff6ff,stroke:#3b82f6,stroke-width:1.5px,color:#1e3a8a
classDef core fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#065f46
classDef client fill:#ffffff,stroke:#cbd5e1,stroke-width:1px,color:#334155
class A app
class B,C,D feature
class E core
class F,G,H client
During a client build for a mental health application, a tech firm’s CEO ordered a complete refactor to turn the app’s architecture into reuseable modules for future clients.
This revealed a critical pattern: nearly every application relies on the same core features - authentication, chat and profile management. Developers who can build modular, scalable systems for these core components become irreplaceable. Those who rely on surface-level tutorial knowledge quickly find themselves obsolete.
flowchart TD
A["TECH CAREER"]
A --> B["⚙️ SPECIALIST"]
A --> C["🧩 FOUNDER"]
A --> D["💼 TECH-ADJACENT"]
B --> B1["Deep technical<br/>expertise"]
C --> C1["Solve niche<br/>problems"]
D --> D1["Solve technical<br/>business problems"]
classDef root fill:#f8fafc,stroke:#475569,stroke-width:2px,color:#0f172a
classDef path fill:#eff6ff,stroke:#3b82f6,stroke-width:1.5px,color:#1e3a8a
classDef detail fill:#ffffff,stroke:#cbd5e1,stroke-width:1px,color:#334155
class A root
class B,C,D path
class B1,C1,D1 detail
Forget broad “full-stack” titles. Just master one-high value, critical domain.
Example: Adam focused strictly on payment processing architectures. With 90 days, he secured a six-gure junior role by solving one high-value problem exceptionally well.
Avoid chasing massive customer platforms. Solve a specific bottleneck using targeted SaaS, specialized automation, or technical consulting.
Example: Beth, a former florist, built an inventory management system specifically for flower shops. She generates multi 5-figure revenues by solving an unaddressed niche problem.
High earners in roles like Product Management, Technical Sales, or Solution Architecture often write minimal code. Their primary skill is identifying high-value technical problems.
Building software is not about syntax, it’s about modular efficiency. By identifying recurring application requirements, you can build documented, reuseable boilerplate frameworks rather than reinventing systems for every project.
To apply this mindset, we can do the following steps:
Identify repetitive takss or systematic inefficiencies in your target domain.
Root-cause the issue (apply the “5 Whys” methodology)
Build a proof-of-concept (POC) that addresses the problem at scale.
Document and distribute your solution to validate market demand.
Example: Sheath, a 40-year-old with zero techincal background, focused exclusively on custom e-commerce components for local, small businesses. Within 5 months, he was freelancing for high-profile executives and earning multi-five figures by delivering direct business utility.
flowchart LR
M1((1))
M2((2–3))
M3((4–5))
M4((6))
M1 --> S1["Strategy & Target Selection<br/><br/>• Choose one path<br/>• Research tech stack<br/>• Define roadmap"]
S1 --> M2
M2 --> S2["Core Building & Public Proof<br/><br/>• Learn technologies<br/>• Build components<br/>• Document publicly"]
S2 --> M3
M3 --> S3["Solution Build & Validation<br/><br/>• Build solution<br/>• Test with real users<br/>• Iterate & document"]
S3 --> M4
M4 --> S4["Positioning & Monetization<br/><br/>• Package portfolio<br/>• Pitch companies/clients<br/>• Position as specialist"]
classDef milestone fill:#2563eb,stroke:#1d4ed8,stroke-width:2px,color:#ffffff
classDef card fill:#ffffff,stroke:#cbd5e1,stroke-width:1.5px,color:#0f172a
class M1,M2,M3,M4 milestone
class S1,S2,S3,S4 card
Month 1: Strategy & Target Selection
Choose one path: Specialist, Technical Founder, or Tech Adjacent Pro
Research the minimum viable tech stack required for your target domain.
Define a strict, focused learning roadmap.
Months 2-3: Core buildings & public proof
Learn the target technologies
Construct foundational components
Document your development process publicly to build technical credibility.
Months 4-5: Solution Build & Validation
Build an end-to-end solution for a concrete problem.
Test with real users, iterate on feedback, and produce comprehensive documentation.
Month 6: Positioning & Monetization
Package your solution into a focused portfolio.
Pitch directly to companies or clients experiencing the exact problem you solve.
Position yourself as a domain specialist, not a generic developer.
Focus on solving discrete problems rather than collecting generic skills. To retain leverage as tools evolve, build systems, not just skills. Clean documentation and reuseable components hold as much value as the code itself.
I’m Hung, a recently CS graduated from Vietnam. I share my developer journey for everyone. For someone who have graduated in this AI era, finding a job was really difficult, so I spent time figuring out what to learn and what to build to make sure that I keep up with the pace of technology currently evolving. This harsh job market for entry level has already been turned wild not just around the world, but also in Vietnam in 2026, when I could not apply for the position I want due to the sheer amount of candidates and the competitiveness required by the companies that are hiring. I realized that with the help of AI, developers’s role has changed into an orchestrator, forcing everyone to do more with less time by controlling the AI agents, and the wave of lay off in big tech companies has proved that viewpoint quite well. So I decided to start my own projects and treat it like a real product, no more toy project, buidling something that can be sold to real users. And here it is – ViSub – ViSub is localization video platform that allows users localizing the video content from original language to their native language. It is my first attempt to build a complete, real-world application instead of an isolated tutorial project.
In this series, I will document the decisions, challenges, mistakes, and lessons that shaped the project.
During my internship in Ho Chi Minh city, I witnessed firsthand how incredible AI has become at coding. It bridges the gap between mid-level and senior engineers effortlessly. However, as a recent graduate, I quickly recognize a major disconnect in my preparation. My university background gave me strong AI foundations - math, regression, classification, gradient descent, and evaluation metrics. I also knew basic DevOps and networking tools like Docker, Github, and DNS. But when it came to building real-world, end-to-end applications, I hit a wall. I realize I did not know how to design production databases, handle authentication and authorization, architect systems for high concurrency, or deploy AI models into full-scale software ecosystems. Knowing the algorithm is one thing; building the system that serves real users is a completely different games.
I choose a simple project but targets on real user needs. I saw young people consuming the foreign entertaining videos from Chinese platform like Tiktok a lot, and many people who doing the re-up seems to lack of tools for doing the localizing job. So I made up my mind and chose to build a solution around this problem.
A typical user flow looks like this:
To be honest, among a thousand ideas, I didn’t know what to choose or where to start. But one thing in my mind that was certain: Do it to the very end, and commit myself to build a complete product that can lift the pain point and serve real users. I didn’t have the market experience, so I followed a lot of people who are doing the startups and choose the ideas that I myself could afford to solve them. I found translation market was the easy one to start, especially with the help of AI techonogies. I began to do a market research, learning how people translating the documents, images, and videos. I found the gap in how people still don’t use AI solutions or use the wrong AI tools to translate the videos. Many of the current solutions have bad UX, and are not convenience for Vietnamese users. So I embraced this idea, and embarked on a new journey to complete this project.
I gained a lot experience while working on this project include:
I learned more than I could imagine. I was overwhelmed at first, but I still found a way to work and learned along the way, on the fly.
During building this projects, I was too naive and did not build a SRS and SDS beforehand, so I ends up changing the Database schemas multiple times, keep reaching the quotas limitation because I don’t understand the design and questions from AI when brainstorming a feature and also do not know how to leverage the entire strength of human force in the team.
Although I managed to get away with the problem with some of my workarounds and tricks, I still do not satisfy with my current level of skills. I’ll reveal about them later in the following posts.
In Part 2, I will explain ViSub’s architecture and the reasoning behind its technology choices.
Building ViSub taught me that real system is not something that can be done by talking. I only understand the surface of the technologies I used, not understand the decisions beneath every choice that real engineer would make when developing features.
ViSub is still evolving, and there are many problems left to solve. I will continue sharing both the successful decisions and the mistakes I make along the way.
]]>