When to build the tool instead of buying it
A paid platform isn't always the cheap option.
The default move when a team hits a process problem is to buy a SaaS for it. Usually that's the right call. Occasionally it's an expensive mistake hiding behind a reasonable-looking invoice.
At Picsart we paid a third-party platform to manage localization — the UI strings that ship across every locale. It worked, right up until the moments that mattered most: string freezes before a release, hotfix translations, locale-specific overrides. The vendor owned the workflow, and we bent ours around it.
So I built the replacement in-house: a localization CMS and translation engine that treated strings, locales, and release states as first-class data, with the engine wired directly into our release process. The headline was roughly $50,000 a year off the bill. The real win was getting control back at exactly the points we'd been losing it.
The lesson isn't “build everything.” It's that the buy-versus-build math has a hidden term most people leave out: how much the vendor's opinion about your workflow costs you. When a tool sits on your critical path and its built-in workflow fights yours, the subscription fee is the small number on the page.
The test I use now is two questions. Is this tool on the critical path? And does it own a workflow we need to control ourselves? When the answer to both is yes, building is genuinely on the table — even when the SaaS looks cheaper on the spreadsheet.