Building a Test Case for the Mid-Market SaaS Scenario: MB-SaaS Data Systems, Inc.

May 4, 2026

In our previous post, we laid out the case for three ideal beta partner profiles for the kDS Data Source Discovery App. Scenario 02 — the mid-market B2B SaaS company — is the one we built first: a post-growth software business whose data infrastructure has outpaced its documentation, where “what data do we have and where does it go?” cannot be answered without a multi-month archaeology project. To put that scenario to work, we needed a test case realistic enough to exercise the full platform — every form, every foreign key, every AI look-up. This post summarizes how we built it and what it found.

The complete test data is documented in the MB-SaaS Data Systems Test Data Planning Document, which contains all entry-ready field values for the parent organization, all six subsidiaries, all twenty-one business units, and all six contacts, organized in exact app entry sequence.

The Company: MB-SaaS Data Systems, Inc.

Private B2B SaaS — Austin, TX — 1,000–5,000 employees, $100M–$500M revenue, NAICS 511210

MB-SaaS Data Systems is a fictional private B2B SaaS company headquartered in Austin, Texas. Its flagship product is MB-SaaS BI, a cloud-native analytics and reporting platform serving enterprise clients in financial services, healthcare, and manufacturing. The company has grown steadily through product expansion and two cloud migrations. It is now preparing for a major enterprise sales push that will require demonstrable data governance maturity — the trigger event that makes a kDS DSD deployment immediately justifiable.

The test case models the exact problem described in the Scenario 02 post: organizational knowledge about data flows concentrated in a handful of long-tenured people, with no systematic documentation. The CDO has recently arrived. The warehouse has been migrated twice. The product has four modules each generating event data that “flows somewhere.” Nobody has a clean lineage map.

Organizational Structure: Six Subsidiaries, Three Divisions

The six subsidiaries in the test case each represent a distinct functional domain with its own location, revenue band, employee size, and NAICS classification — deliberately varied to exercise the platform’s organizational hierarchy handling across different entity types:

MB-SaaS Analytics Cloud (Austin) — core SaaS product, NAICS 511210, $50M–$100M revenue
MB-SaaS Data Integration Services (Chicago) — ETL and connectors, NAICS 519290, $10M–$50M revenue
MB-SaaS AI Labs (San Francisco) — R&D division, NAICS 541715, cost-center
MB-SaaS Professional Services (New York) — consulting and implementation, NAICS 541512, $10M–$50M revenue
MB-SaaS Security & Compliance (Austin) — shared-services division, NAICS 541519, cost-center
MB-SaaS Customer Success Platform (Denver) — customer lifecycle division, NAICS 561499, $1M–$5M revenue

Three of the six are classified as Divisions rather than Subsidiaries — exercising both Organization Type values through the data model and confirming they display correctly in the hierarchy view.

Twenty-One Business Units, Six Tool Ecosystems

Each subsidiary carries three or four business units, for twenty-one total. The business unit layer is where the kDS interview engine operates, so each unit needed a realistic description of what it does and what systems it touches. Across the twenty-one units the dataset references Snowflake, Salesforce, Gainsight, Zendesk, Confluent Cloud, Vanta, OneTrust, Splunk, Amplitude, Jira, GitHub, dbt Cloud, Fivetran, and a dozen others — a cross-section of the SaaS toolchain that any mid-market analytics company would recognize.

One unit worth calling out: Data Discovery Automation within MB-SaaS AI Labs, assigned to contact Jonah Esperanza. His team researches AI-assisted data source mapping — the same problem space as kDS — which means the test case includes a respondent who is simultaneously a sophisticated evaluator of the instrument conducting his interview. That is a useful edge case to exercise.

A Schema Constraint Worth Noting

Building realistic business function descriptions immediately surfaced a platform issue: the rag_business_function column in stage.business_unit is defined as varchar(96). The original descriptions ran 258–331 characters. The Seacoast seed data that ships with the platform leaves this column blank, so the constraint had never been tested against real content. The resolution was to trim each description to a single functional sentence at or under 96 characters — but the constraint is a candidate for a future schema revision, with downstream impact tracing required before widening it.

Six Contacts, One Project Sponsor

The six contacts span five subsidiaries and carry a deliberate distribution of role flags. Only one — Rachel Okonkwo, CDO — carries the Project Sponsor flag. Five of six carry SME Identifier. Derek Fontaine carries SME but not SME Identifier, reflecting a narrower but deep domain scope.

Rachel Okonkwo, CDO — Executive Data Sponsor / Project Sponsor. Owns the data governance program and chairs the Data Governance Council.
Marcus Delacroix, VP of Data Engineering — Senior Data Engineering SME. Seven-year tenure, owns the Snowflake warehouse and dbt pipelines. Densest node of tribal knowledge in the organization.
Priya Nambiar, Director of Integration Engineering — Integration Architecture SME. Owns 200+ connectors and all client-specific integration delivery.
Derek Fontaine, Senior Security & Compliance Analyst — Compliance Data Flow SME. Owns the DPA registry and SOC 2/HIPAA audit evidence. High-value SME for regulated data domains.
Tamara Whitfield, Director of Customer Data Operations — Customer Data Architecture SME. Built the Gainsight/Salesforce/Zendesk integrations herself over four years. The canonical tribal knowledge scenario.
Jonah Esperanza, AI Research Lead — Data Discovery Research SME / Evaluator. Researches AI-assisted discovery and evaluates tools like kDS critically from the inside.

What the Test Case Validates

The entry sequence and testing checklist walks through the full workflow in the order the app requires: parent → subsidiaries → business units → contacts. Beyond the basic entry flow, the dataset specifically exercises NAICS look-up against seven distinct entities, AI role classification across four SME profile types, Organization Type handling for both Subsidiary and Division values, role flag assignment with a single Project Sponsor, the stage.business_unit bulk import pipeline via \copy in a psql heredoc, and the SME confirmation email workflow end to end.

All field-level data for all thirty-four entities is in the MB-SaaS Data Systems Test Data Planning Document. If you’re working through a kDS DSD App deployment and want a complete, pre-validated dataset to start from, that document is the place to begin.

Interested in the kDS DSD App beta program? Contact us at talk2us@keeshinds.com or visit keeshinds.com to learn more about the platform and the founding partner opportunity. We’re actively onboarding select beta partners.