The Day Seven Students Shared One ID: Why Data Architecture Is a Founder's Job

Seven students. One candidate ID. The same phone number registered to fourteen different people across three separate portals.

That is what I found when I opened the master database of a company that had been operating for nearly a decade. I had been brought in to clean, structure, and merge their data from multiple databases into a single source of truth, one central master DB from which their different portals could fetch reliably. I knew going in that the data would be messy. Every database engagement starts with that assumption. What I did not expect was that the data would be so fundamentally incorrect that I could not make sense of it without sitting down with someone who had been at the company since the early years.

Not a documentation problem. Not a schema problem. A decade of compounding assumptions baked into rows and columns that nobody fully understood anymore.

How It Gets This Bad

No founder wakes up and decides to build a broken database. It happens slowly, then all at once.

In the early months, the team is learning what the business even is. A first-time founder is still figuring out their customer, their GTM, their unit economics. The database is an afterthought, which is fine. You need ten rows before you need a schema. A candidate gets registered. Someone enters their phone number manually. Another team member enters the same candidate from a different portal. Nobody notices because there are only fifty records and everyone knows everyone.

Then the company crosses a threshold. Data starts arriving from multiple sources simultaneously: a website form, a CRM import, a third-party API, a bulk CSV upload from a partner. The team that built the original tables has moved on. The new team inherits a structure they did not design and cannot fully explain. Reports start looking odd. Conversion numbers do not add up. Someone notices that the same candidate appears three times in the funnel. A quick fix is applied. Then another. Then another.

By year ten, you have seven students sharing one ID. The fix is no longer quick.

Why False Reports Are Worse Than No Reports

This is the part that founders underestimate. A missing report is obviously broken. A false report looks correct.

When your database has candidate IDs shared across multiple records, your portal will happily report a number. It will show you cohort sizes, drop-off rates, conversion percentages. All of it will be wrong by an unknown margin. You will make product decisions, hiring decisions, and GTM decisions based on those numbers. The company I was working with had been doing exactly that, not because anyone was careless, but because the data looked plausible.

Data quality problems do not announce themselves. They hide inside dashboards that load cleanly and charts that trend in the right direction. The error is invisible until someone digs into the raw tables, which usually only happens when something goes badly wrong or an outside person, someone without the accumulated context of years of workarounds, looks at it fresh.

That outside perspective is precisely what I brought. And I still needed an old employee to explain what certain fields actually meant.

The Stage When This Becomes Urgent

I am not arguing that a seed-stage startup should spend three weeks on database architecture before writing a line of product code. That would be wrong. The early stage is for learning, and premature optimisation of data structure is a real cost when you are still discovering whether your business model works.

But there is a stage, somewhere between consistent revenue and exponential data growth, where the cost equation flips. Past that stage, every new data source you add without a clean master schema multiplies the mess. Every new portal that fetches from an inconsistent database propagates the errors downstream. The technical debt compounds faster than the team can manage it, and by the time it is visibly painful, the remediation work is enormous.

The company I was working with was well past that threshold. The merger of their databases into a single master was not a weekend project. It required reconciling records where the ground truth was locked inside the memory of people who had been there from the beginning.

What You Can Do Differently Now

Here is the principle: data architecture is not an engineering problem, it is a business clarity problem.

The reason databases become chaotic is not that engineers are careless. It is that the business questions were never fully articulated. What is a candidate? Can one person be a candidate in multiple programmes simultaneously? What happens when a candidate changes their phone number? These are business rules, and they need to be defined before they are encoded.

Today, you do not need a data architect on staff to think through these questions. You need to be clear enough about your business: your target audience, your customer journey, your GTM motion, and your reporting needs, to have a meaningful conversation with an AI model about your schema. If you can explain to a model what a candidate is, what an enrolment is, what a conversion event looks like, and how your portals relate to each other, the model can help you think through edge cases before they become ten-year-old problems.

The founders who will have clean data at year ten are the ones who treated data design as a strategic conversation, not a post-launch clean-up task.

Start with the questions. What records matter? What makes a record unique? What do you need to report on six months from now? Get those answers written down. Then build the tables.

The alternative is seven students sharing one ID and a consultant who needs a historian to understand your own data.

---

Related reading:

Beyond the Prompt: Building a High-Fidelity Discovery Engine How I Rebuilt Suvastika.com After a Ransomware Attack