Here’s our honest take. It’s not impossible, but it’s harder than it looks, and the reasons are mostly not about writing code.
Data security is the real work
Performance data is among the most sensitive information a company holds. Before you write a line of code, you’ll need clear answers to: Where does data live? Who’s responsible if something goes wrong? Who has access, and how do you revoke it automatically when someone leaves?
We’ve been running on Google Cloud’s platform infrastructure for 15 years and we still invest heavily in firewalls, encryption, independent backup networks, and data access controls. Beyond configuration, you’ll need ongoing security reviews. We run a public bug bounty program and bring in external auditors annually. A serious in-house solution will need something comparable.
The permission problem is subtle but serious
One of the hardest parts of a performance management tool isn’t the UI, it’s access control. A manager should not be able to read a review they weren’t assigned to. An employee should not be able to see who wrote their anonymous 360 Feedback. Getting this right requires careful spec work and thorough testing.
We have thousands of automated tests that run on every code change, specifically to verify that our permission and visibility logic holds. AI can generate the code, but a senior developer still needs to review it closely. A single ambiguous requirement can expose data it shouldn’t.
Software doesn’t stand still
Even if you build exactly what you need today, you’ll need to maintain it. Third-party libraries that your codebase depends on ship security updates constantly, and the larger upgrades aren’t just drop-in replacements. Without regular maintenance, the security of your tool erodes on its own.
At Small Improvements, we’d still need roughly half a developer’s time to manage dependencies even if we stopped building new features entirely.
Your requirements will evolve
You might want anonymous 360 Feedback today and decide against it next cycle. The problem: you can’t simply remove anonymity from your codebase. Old cycles need to stay anonymous, new ones don’t. That’s exactly the kind of option vendors build in from the start, and exactly the kind of thing that becomes a significant engineering project when retrofitted.
Staffing costs more than it looks
If a $10k/month developer spends a month building something that saves you $15k in SaaS fees, that sounds like a win. But if that developer should have been generating revenue, the opportunity cost is likely higher than the saving. Factor in the ongoing maintenance, the bus factor risk if they leave, and the cost of covering bugs while half the team is on vacation, and the math shifts quickly.
The bottom line
If HR is genuinely core to your business, building in-house can be the right call. But if you’re in a different industry and performance management is a means to an end, a large and open-ended software project is probably not where your best people should be spending their time.
There are dozens of established vendors to choose from. The right one matches your current process closely, handles the security and maintenance burden for you, and lets your team stay focused on what you actually do.
Curious for more information and want to read our extended version? Click Here.
