The Client Who Knew Best (And Saved Me From Myself).

I Did My Homework. It Didn't Matter.

I spent real time preparing for this one. Before any offer was on the table, I had already researched the problem space, looked into the relevant EU-wide databases this collection needed to feed into, and had a clear picture of what the right solution looked like. Multiple calls with the director went well. Good energy, interesting project, meaningful work.

Then the technology conversation happened.

I laid out two sensible paths: Azure for managed redundancy, or Hetzner if we wanted to keep costs down and didn't mind a bit of self-managed infrastructure. Both solid options. Both matched the actual requirements. The director listened, then mentioned, almost in passing, that he "speaks IT" because he once did a Scrum Master course.

Reader, I should have ended the call there.

The MongoDB Situation

He wanted MongoDB. He did have a reason this time: the collection contained texts, images, and videos. Different file types. Therefore: unstructured data. Therefore: MongoDB.

I'll give him this, the logic has a shape. It's just wrong. Storing files alongside structured metadata in a relational database is completely standard. The types of the files don't make the surrounding data unstructured. But he'd connected two concepts he'd heard before and arrived at a conclusion, and that was enough for him.

The right tool for this job was Omeka S. It's open source, purpose-built for exactly this kind of cultural heritage digitalization work, and it has out-of-the-box support for the metadata standards and export formats this project needed. It runs on a relational database. It would have covered every single use case here without custom glue code.

MongoDB can technically be made to work. "Technically can be made to work" is a terrible reason to choose a tool.

I explained this. Calmly, with reasoning, more than once. The director wouldn't move. He had decided, and that was that.

The Call On Day One

The project was supposed to start on a Monday. He called that morning.

He'd found someone else. Someone who would do exactly what he wanted. Use MongoDB, no pushback, no questions. He thanked me for my time and hung up.

My first reaction was frustration. I had invested time, done real preparation, and got two hours of paid work out of it. My second reaction, about twenty minutes later, was something close to relief.

What I Actually Learned

Here's the thing: if he hadn't made that call, I would have started. And starting would have been worse.

Not because MongoDB would have doomed the project (though it would have made everything harder and more expensive). The real problem was the dynamic. A client who enters an engagement having already decided how to solve a technical problem, and who treats pushback as insubordination, is not a client you can do good work for.

I'm a freelance software engineer. My clients hire me to solve problems. I want to understand the what and the why deeply, because that's what good solutions come from. The how is mine to own. The moment someone without a technical background starts dictating implementation details, the engagement stops being about solving a problem and starts being about executing someone's half-formed idea. Those projects don't end well for anyone.

The red flag wasn't MongoDB. The red flag was the reasoning behind it. "We have images and videos, so the data is unstructured" is the kind of argument that sounds almost technical if you don't think about it for more than ten seconds. It borrows real vocabulary and reaches a wrong conclusion. That's harder to push back on than pure preference, because the person genuinely believes they've done the analysis.

The Flags Were There Earlier Than I Admitted

Honest self-assessment: I saw the warning signs and talked myself past them.

The Scrum Master comment was funny in the moment. In hindsight it was a signal. Not because doing a Scrum course is bad, but because he led with it as a credential in a technical conversation. That's someone who wants to be seen as technical without doing the technical work.

I kept the calls going because the project itself was genuinely interesting. Meaningful cultural heritage work, EU funding context, a real audience. I wanted the project to be what it looked like on the surface. That's a trap I'll be more careful about walking into again.

Trust The Discomfort Earlier

If something feels off in the scoping calls, it doesn't get better once the contract starts. It gets more expensive.

When a client can't explain the rationale behind a technical constraint they're insisting on, that constraint isn't a requirement. It's a preference. And preferences that can't survive a single "why?" are usually preferences that will create problems throughout the entire project.

I'm genuinely glad he made that call on Monday morning. The person who took the job and agreed to use MongoDB got the project. I got a free morning and a lesson I didn't have to learn the hard way.

That's probably the best outcome I could have asked for.