There Is No Such Thing as a Good Deal on Dev - ProductFTW #78
Sorry, not sorry
I’m not an engineer. I’ve never been a developer, and I don’t try to pretend otherwise. As a product manager, I work closely with engineers every day, and after a while, you start to notice the same patterns repeating.
One of the most common ones is this: someone tries to save money on development.
It usually comes from a good place. People think they are being efficient or practical. They look for the cheapest option, figuring that as long as someone can write code and ship it, that is enough. They question why they should pay for senior talent when they can hire junior engineers or lean on AI for much less.
This perspective is not based on authority. It comes from observing how teams actually function. I see what breaks, where the pressure builds, and how often junior engineers are expected to perform at a level they have not reached yet.
You Get What You Pay For
Most teams want to move faster while spending less. Those goals are in tension with each other. You do not get low cost, speed, and high quality at the same time. (see ProductFTW #62).
If you hire junior engineers primarily to reduce cost, the tradeoffs show up quickly. The codebase becomes harder to maintain. Pull request reviews start to pile up. Quality assurance becomes more difficult. Overall velocity slows down instead of improving. Senior engineers spend more time reviewing and correcting work. The product begins to feel inconsistent.
This is not a failure of junior engineers. It is a mismatch between expectations and reality. Junior developers need support, guidance, and time to grow. If those things are missing, they are set up to struggle.
The worst part is, you might not even notice the damage at first. The shortcuts don’t always show up right away. They compound over time. You start to accumulate tech debt you don’t understand. Bugs sneak into edge cases. Scaling breaks. It’s a slow bleed, and then a crisis.
Junior Devs Deserve Better
If you’ve made the call to hire junior engineers, that’s fine. Everyone starts somewhere. Junior engineers can be amazing. They bring fresh energy, curiosity, and a willingness to learn. I love working with them.
The issue is expecting them to operate without support. You cannot hand them vague tickets and expect them to fill in the gaps. You cannot provide unclear product requirements and expect perfect outcomes. You cannot become frustrated when they ask questions or overlook details.
When you hire junior talent, you take on additional responsibility. Requirements need to be more specific. Quality assurance needs to be more thorough. Communication needs to be more detailed. Patience is required. In most cases, a senior engineer should be involved to review work and help guide development.
If you cannot support that structure, then you are not in a position to hire junior engineers effectively.
Set the Right Expectations
Here’s the big point: You have to be realistic.
This ultimately comes down to expectations. There is no scenario where you get high quality, low cost, and fast delivery without tradeoffs. You are always exchanging time, money, or experience.
If you choose to hire junior engineers, your plan needs to reflect that decision. Work should be broken into smaller pieces. Requirements should be more explicit. Timelines should allow for a slower pace. Additional time should be allocated for testing. Learning and mentorship should be part of the process. If those adjustments are not made, the outcome should not be surprising.
AI Is Not the Shortcut You Think It Is
I also want to bring up the other “solution” I keep hearing about: AI.
Let’s just have the junior devs use ChatGPT. Let’s lean into GitHub Copilot. Let’s automate the repetitive stuff. Let’s use AI as a force multiplier. Let’s go faster.
Sure, I’m all for tools that make developers more productive. Copilot is amazing. ChatGPT is a great assistant. Let’s not pretend these things can write production-ready software without oversight. They hallucinate. They miss context. They take bad shortcuts unless they’re prompted very precisely.
You need someone who understands how to use these tools well. Someone who can catch when they’re wrong. Someone who knows what “good” looks like.
Expecting a junior engineer to also act as an expert in prompting, reviewing, debugging, and system design is not realistic. AI tends to amplify the level of experience already present on a team rather than replace it.
It is also important to be clear about the current state of these tools. They are powerful, but they are not reasoning systems. They generate outputs based on patterns, which means they can be helpful in some cases and unreliable in others.
Final Thought
Underpaying and overloading developers is not an effective strategy. Skipping mentorship and relying on tools to compensate for lack of experience does not lead to efficiency. Trying to avoid paying for experience usually shifts the cost elsewhere.
In most cases, that cost appears later and is significantly higher when it does.
About ProductFTW
ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.