MDM and data governance are usually framed as enterprise concerns — the province of CDOs, data stewards, governance councils, and seven-figure platform budgets. Building Ortiki, a consumer app I designed and shipped as a solo founder, changed how I think about both disciplines. The questions don't change at small scale. Only the resources available to answer them do.
I've spent twenty years implementing master data management and data governance at enterprise scale — large healthcare retailers, insurance carriers, multi-division distributors. When I started building Ortiki, a warranty, insurance, and home contents tracker, I expected the work to feel different. It did. But not in the way I anticipated.
The technical decisions were smaller. The organizational machinery wasn't there. But the underlying questions were identical to the ones I navigate at work every day — and the cost of getting them wrong was just as real, only faster to surface.
The Same Fundamental Questions
Master Data Management, at its core, is a set of answers to a small number of questions: Where is this data stored authoritatively? Who can access it, and under what conditions? How is it protected? What happens when it moves between systems? How do you know when it's wrong?
Those questions came up immediately when building Ortiki — not as abstract governance concerns, but as concrete architectural decisions I had to make before writing a line of application code. Here's how each one played out.
Six Governance Decisions, Applied at Consumer Scale
Every client — the web app today, the native Android app in parallel — reads from and writes to the same backend record. No local state that can diverge from the server. This eliminates the class of data inconsistency that plagues multi-device consumer apps and is the first principle of any MDM program worth running.
Five product categories. One unified products table. Warranties, contacts, and documents are modeled as distinct entities with enforced foreign-key relationships to the parent product. A warranty cannot exist without a parent product. Orphaned records aren't a production bug — they're a schema failure. This is the same conversation I have with implementation teams on every MDM engagement.
Row-level security is enforced at the database layer, not the application layer. A bug in app logic cannot expose another user's data if the database rejects the query outright. This is a governance control that many production systems — including some at significant enterprise scale — fail to implement correctly. It belongs in the schema, not in the code that calls it.
Free tier versus Pro is enforced via a field in the database, not in client-side logic. The database is the authority on what a user can access. It cannot be bypassed by manipulating the front end, and any future payment processor can update the same field via webhook without touching application logic. Governance enforced at the source, not downstream.
The app collects what it needs to function: names, email addresses, product details, warranty dates, policy numbers. Nothing more. This isn't a legal checkbox — it's an architectural choice that reduces risk surface before the first user signs up. The data minimization principle that underpins GDPR and CCPA is also just good data design.
Photos and documents — receipts, warranty cards, serial number labels — are stored in cloud storage with paths that encode their provenance. The URL for each document is stored as structured data in the product record. The relationship between a document and the item it belongs to is always explicit and queryable. Lineage, at consumer scale.
What I Didn't Expect
None of the principles above are novel to anyone who has worked in data governance. That's the point. They're the right answers to questions that come up any time data matters — regardless of whether the organization is a Fortune 10 healthcare company or a one-person LLC.
What I didn't anticipate was how much harder it is to apply these principles without the organizational infrastructure that enterprise governance usually relies on. There's no data steward to flag the field you left nullable. No governance council to push back on the entity model you almost got wrong. No architecture review to catch the access control you deferred to the application layer.
In an enterprise, governance discipline is distributed across roles, teams, and processes. A solo founder carries all of it alone — and the accountability is immediate. A bad schema decision at week two doesn't get caught in a quarterly data quality review. It shows up in production, in front of real users, with real data.
That experience gave me a sharper appreciation for how much organizational infrastructure the discipline usually relies on — and how much is possible without it, when the instinct is there from the start.
The Broader Point
The managed cloud infrastructure available to developers today — row-level security, point-in-time recovery, SOC 2 compliant platforms, UUID-native databases — has closed the gap between "enterprise best practice" and "what a solo founder can actually implement" faster than the industry's conventional wisdom acknowledges.
The gap that remains is not technical. It's the governance instinct: the habit of treating data as something that needs to be modeled deliberately, protected structurally, and governed from the first line of schema — not retrofitted after the first breach or the first bad report.
That instinct is developed through the work. Years of enterprise data governance built mine. Ortiki gave me a new context to test it — and a new perspective on where the discipline actually lives.