How Primentra Addresses Small Business Master Data Challenges

I worked with Microsoft Master Data Services as a consultant for years. It did the job. Using it was miserable, slow screens, an interface nobody at Microsoft had touched since the Silverlight era, and an Excel add-in that everybody actually used because the web interface was so unpleasant to be in. Then a client asked me the obvious question. Microsoft is clearly not investing in this any more, so what do we move to? I went looking properly, and I could not give them an answer I believed. Everything was cloud-only, or priced for a company with a procurement department and a data governance team to run it. If you cannot put your customer master in someone else's data center, and plenty of companies cannot, there was nothing for you at any price you would recognise. So I had two problems at once. A tool I did not enjoy using, and no honest answer to give a client who trusted me to have one. I started building Primentra so that I would.

Worked, the blog. I write about what people actually search for when they are stuck with master data. Not what I want to say about my product, but what they type into Google at four in the afternoon when two systems disagree about a customer and nobody knows which one to believe. I pull the queries out of Search Console, write the answer properly, and link the documentation page that covers it. It is slow. The first posts did nothing for months. Then they started ranking, the downloads followed, and now those old posts keep working while I sleep. Flopped, paid ads. I spent money, got clicks, and got nothing that turned into a trial. It makes sense in hindsight, and it annoys me that I had to spend the money to see it. Nobody buys an on-premises master data tool because an ad interrupted them. They buy it because they already have the problem and went looking for a fix. An ad has to create the need first. Search does not have to.

Small bugs, mostly. Nothing architectural. A field that behaves oddly, a screen that does not refresh when you expect it to, a number that formats correctly in one place and wrongly in another. Some of that is what the product is. Primentra installs on the customer's own server, against their own SQL Server, with their own data in it. I cannot see any of that. So, the bugs that reach me are usually the ones that only appear on a machine I have never touched, and the person reporting it is the only one who can describe what actually happened. I ship the fix fast. Twenty-one releases since April, and most of them carry something a user reported. For a one-person product, that is the trade I can actually offer. I cannot give you a support desk with four people on it and a ticket reference. I can tell you that when you report something broken, it usually ships in the next release rather than the next quarter.

That master data management is an enterprise-only problem. The tools are priced that way, so everyone assumes the problem is that shape too. It is not. A company with four hundred people and three systems that disagree about the customer list has the same problem as a company with forty thousand. Smaller in euros, identical in kind, two records for one customer, and nobody sure which is right. The invoice goes to the old address. The report counts them twice. Somebody loses a morning working out which record to believe. What those companies do not have is a six-figure budget line, or a data governance team to run the thing once it is bought. So they keep their master data in a spreadsheet with a name ending in final underscore v three, and call that a process. It works until the person who maintains it leaves. It is not that they do not need this. Nobody has ever offered them a version they could afford, install themselves, and run without hiring anybody.

Lookalikes. Finding records that are the same real thing typed two different ways, Acme Ltd and ACME Limited, or the same customer entered twice with a space in a different place. A unique key never catches those, and every master data set I have ever opened is full of them. The design is done and the explainer is written. Building it is next. The one rule I will not break is that it never merges anything by itself, not at ninety-nine per cent confidence. It finds the pairs, scores them, and puts them in front of a person who decides.

21 releases since April 2026, and every one still upgrades cleanly.

SQL Server and business intelligence consulting. Data warehouses, reporting, and the master data layer sitting underneath both of them. That is where I met MDS, and it is why Primentra is built the way it is. Every piece of logic lives in a stored procedure, with no raw SQL anywhere in the application. Partly, that is how I have always worked. Mostly, it is because a customer's own DBA can open a stored procedure and read exactly what it does to their data. On-premises buyers ask that question, and "trust us" is not an answer. I had not shipped a commercial product before this one. The data part I knew cold. The selling part I am learning now, later than I should have.

I built far too much before asking anyone to pay for it. Approval workflows, a REST API, staging tables, business rules, a migration wizard for coming off MDS. All of it needed by somebody. None of it validated by someone handing me money first. I was building against my own idea of what a customer needs, which is a guess wearing the clothes of experience. The honest version is that building is comfortable and selling is not. I am a consultant who knows how to make software, so I made software, and every week I spent making it was a week I did not have to hear anybody say no. What I should have done is sell an unfinished version to five companies and let them tell me which half mattered.