Devesh Korde
September 7, 2026
I spent six months building a custom authentication system.
It was perfect. Every edge case handled. Every security concern addressed. Every token encrypted with redundancy. The code was beautiful. The implementation was mine.
In my existing company they used Duende Identity. It did 80% of what my custom system did. It was maintained by a company whose only job was maintaining authentication. It had security patches released regularly. It was boring.
My custom system had done its job well. But it had also tied me to it. I could not leave. Someone had to maintain it. That someone was usually me, even after I stopped working there.
The custom authentication system I built was a trap. Not because it was bad code. Because it was code that did not need to exist.
Accountants do not fall into this trap. Accountants use Excel. They do not build custom spreadsheet software from scratch because they could.
Designers do not fall into this trap. Designers use Figma. They do not build custom design tools because they could.
But developers? Developers see a tool that is 80% right and think: "I could build that last 20%. It would take me a weekend."
And they are often right. It would take a weekend. It would work. It would be tailored perfectly to their needs.
But they are also wrong. Because the weekend of building is not the cost. The cost is every day after the weekend when that custom code has to be maintained, debugged, updated, and kept running.
The trap is that developers have the ability to build, and having the ability creates the illusion that building is the right choice.
Let us do the math.
You find a tool that is 80% of what you need. It costs $50 a month. But you know you can build the missing 20% in a weekend.
Your calculation:
Seems obvious. Build it.
But the calculation is wrong. It ignores the hidden costs.
The real cost of building:
Year 1 cost of building: $10,000 (development + maintenance + opportunity cost + knowledge transfer)
Year 1 cost of using the tool: $600 (12 months × $50)
Even if you never build the missing 20%, the tool is 16x cheaper.
But wait. The tool has one problem. It is 80% of what you want. That 20% gap is the problem.
Except it is not really a problem. It is a gap. You live with it. Most of the time, the 80% is enough. Sometimes the 20% gap matters. You work around it. The workaround takes 5 minutes.
The 20% gap costs you 5 minutes a month. That is 1 hour a year.
Compare:
You save 23 hours a year by living with the gap.
Most developers get this math backwards. They see the gap and think it is the problem. But the gap is not the problem. The maintenance is the problem.
One custom solution is a decision. Three custom solutions are a pattern. Ten custom solutions are a lifestyle.
I knew a developer who built:
Each one was built because he could. Each one was 80% to 90% good. Each one solved a real problem that an existing tool solved for $50-500/month.
He had built five tools. The organization now had five tools that nobody else understood. Nobody else could maintain them. He was the single point of failure for all of them.
When he left the company, every single one of those tools was replaced. His code was deleted. Five months of his time. All of it gone.
The trap multiplies because the first custom solution makes the second one feel justified. "We built that authentication system and it works great. Let us build this monitoring tool too."
But the first system working great does not mean it was the right decision. It means you got lucky. You built something that worked. That is different from it being the right thing to build.
When you encounter a tool that does 80% of what you need, there are three options:
Option 1: Use the tool as-is
Cost: $600/year
Benefit: You do not have to maintain anything
Pain: The 20% gap
Verdict: Best choice most of the time
Option 2: Use the tool and build the missing 20%
Cost: $3,000 (build) + $600 (tool) + $150/month (maintenance) = $5,400/year
Benefit: You get 100% of what you want
Pain: You maintain both the custom code and the tool
Verdict: Best choice if the gap is truly blocking you
Option 3: Build it yourself
Cost: $3,000 (build) + $150/month (maintenance) + $375/month (debugging) = $6,500/year + $2,000 (knowledge transfer) + opportunity cost
Benefit: You own it completely
Pain: You maintain it forever, it becomes tech debt, it blocks others, it slows down hiring
Verdict: Rarely the right choice
The trap is that developers default to Option 3 because they can, skipping the cost-benefit analysis that would reveal Option 1 is almost always right.
Reason 1: Proximity Bias
You can build it. It is right in front of you. The build option is proximal. The tool option requires research. Your brain defaults to the proximal option.
Reason 2: Skill Validation
Building something validates your skills. Using a tool does not. There is a psychological reward to building. To creating. To owning something.
Using a tool feels like admitting you could not build it yourself.
Reason 3: The Customization Illusion
Your specific needs feel so unique that no tool could possibly handle them. But when you actually use the tool, you find that 99% of organizations have the same needs. The tool handles them fine.
You think you are special. You are not. Most of the time, you are average. The tool was built for average. Average is enough.
Reason 4: Underestimating Maintenance
Developers are notoriously bad at estimating maintenance. They estimate the build (40 hours, seems right). They massively underestimate the maintenance (2 hours/month becomes 10 hours/month becomes a full-time job).
Maintenance is boring. Maintenance is not fun. Developers do not like to think about it. So they underestimate it.
Reason 5: The Myth of "One More Feature"
"The tool is 80% good. We just need to add one more feature. Then it will be 90%. Then one more and it will be 95%."
But building the 20% requires building the first 20% (1 weekend). Then you realize the 20% is not enough, you need 30% (another weekend). Then you realize the tool itself is causing problems, you need 40%.
The scope creeps. The custom code grows. The maintenance burden expands.
You never reach 100% because 100% is not the goal. The goal keeps moving because you can always build more.
The developers who are most effective are not the ones who build the most. They are the ones who build the right things.
They see a tool that is 80% good and ask:
If the answers suggest building is worth it, they build. If not, they use the tool.
They have internalized a principle: The best code is code that does not need to exist.
If a tool does 80% of what you need, and the tool is maintained by someone else, then not building your own code is the right decision. Even if you could build it better.
Even if your custom version would be more perfect, more tailored, more beautiful.
Because perfect custom code that you have to maintain forever is worse than 80% good code that someone else maintains.
You are probably using a custom solution right now that should not exist.
Look at your codebase. Find the code that:
That code is the trap. It is beautiful code. It is code that works. But it should not exist.
The reason it exists is that someone (maybe you) looked at a tool, saw it was 80% good, and thought: "I can build the other 20%. It will take me a weekend."
They were right about the weekend. They were wrong about the cost.
The weekend was free. The year after the weekend was not.
Your ability to build is not permission to build. Sometimes the best engineering decision is to not build. To use someone else's 80% solution and spend your time on the 100% problem that only you can solve.
The developers who are most valuable are not the ones who build the most custom code. They are the ones who know when custom code is worth the cost.
Most of the time, it is not.
