At most companies, the question of whether to build or buy a tool gets answered the wrong way. Someone finds a SaaS that looks good in a demo, gets approval on the monthly cost, and three years later the company is locked into a vendor, paying for features it doesn’t use, and still doing half the work manually anyway.

This is the story of how we did it differently and why the most important decision we made had nothing to do with technology.

The Problem Nobody Had Fully Named

I was part of the website team at a mid-sized e-commerce company. Our job, among other things, was to get new products live for customers to purchase. Simple enough in theory. In practice, it meant being the last link in a chain that involved procurement, product development, finance, logistics, and marketing, each of which had their own tools, their own spreadsheets, and their own definition of “ready.”

When a new collection was due to launch, we would spend significant time hunting: Are the prices set by finance? Has procurement confirmed delivery? Did product development provide the technical specifications? The information existed - somewhere - but it was scattered across a fragmented landscape of Google Sheets, shared drives, and institutional memory.

On top of that, the Sheets themselves were becoming a liability. Large, complex spreadsheets are brittle. They freeze on underpowered machines, break when someone edits the wrong cell, and don’t scale well as teams and product catalogues grow. Double-entry was common. Errors were common. Accountability was not.

Logistics and procurement had already consolidated onto an ERP (Odoo), but everything else was managed on a team-by-team basis. The result was that the website team (my team) absorbed most of the chaos at the end of every launch cycle.

The Interim Fix

Before proposing any system, I took a simpler first step: consolidate the information into a single Google Sheet covering the full launch and customer support workflow. No new tools, no development work. Just agreement on one source of truth.

This took around six to eight months to stabilise. It reduced friction, but it also made the underlying problem clearer. A spreadsheet, however well-maintained, was never going to be the right substrate for this kind of structured, multi-department data flow. We needed something purpose-built. The endless copy-pasting had to go. The avoidable errors from human mistakes had to stop.

Pitching It Right

Here is where a lot of internal tool projects go wrong. The instinct is to walk into a pitch with a solution: “I’ve found this great SaaS” or “we should build a PIM system.” That approach almost always fails, because it asks decision-makers to evaluate a solution before they’ve agreed on the problem.

I did the opposite. I documented the pain points in business terms: time lost per launch cycle, error rates, the downstream cost of bad data reaching the website. I made the case for why this mattered to the bottom line, not as a technology problem, but as an operational one. The solution came second.

The pitch went to my department head and from there to C-level. It was approved.

Why We Built Instead of Bought

Once the project was green-lit, the build vs. buy question was relatively straightforward, though not for the reasons people usually cite.

Yes, I looked at SaaS PIM solutions. They were significantly more expensive. But cost alone is a weak argument, because SaaS costs are predictable and development costs are not. The stronger arguments were elsewhere.

First, fit. Our requirements were specific: integration with Google Sheets (where our teams already worked), a rich text editor for copywriters, an API connection to our TMS for translation workflows, and a CSV export pipeline into Magento 2. No off-the-shelf tool was going to cover this without significant configuration work, which you’re paying for either way.

Second, control. A lightweight internal tool doesn’t need to be a long-term commitment. We built it to be replaceable. No lock-in, no migration risk, no vendor dependency. If the company’s tech stack changed, we could walk away cleanly.

As it turned out, that mattered. The company later moved toward the Shopify ecosystem, which may eventually make the PIM redundant. Because we built without lock-in, that’s fine. We treat it as a feature of the original design, not an accident.

Third, ownership. Product information had previously lived in scattered Drive documents. Good luck finding anything in that chaos! The PIM gave us a PostgreSQL database with a daily automated backup to the company Drive. 99.99% uptime over nearly a year of operation. Data that’s actually findable and maintainable.

What We Built

The MVP took roughly 150–200 hours across a two-person team. My role was concept, architecture, CI/CD pipeline, and hosting setup. I designed the system and got it running in production. My junior colleague handled the bulk of feature development. End-to-end ownership from whiteboard to deployment was mine. The system:

Uses SSO for authentication
Pulls technical and finance data from Google Sheets, where employees already work
Provides a rich text editor for copywriters, isolated from technical complexity
Requests and receives product translations via the TMS (Smartling) API
Exports a Magento 2-ready CSV, eliminating the manual copy-paste work that previously consumed around 70% of launch time for the website team
Runs on a very affordable, European VPS via Docker, deployed through Bitbucket Pipelines
Backs up the database to Google Drive daily via a cron job

Continuous patches and extensions have been applied over the past year as needs evolved. The total cost - development, maintenance, hosting - remains 80–90% below what comparable SaaS solutions would have cost.

The Principle Behind It

I’ve spent enough time in operational roles to have learned one thing clearly: the best solution is rarely the most technically elegant one, and never the most ideologically pure one. It’s the one that solves the actual problem, fits the actual constraints, and can be handed over, maintained, or discarded without drama.