MTCC Diagnostics

A consultant’s method rebuilt as configurable product infrastructure, from question design and respondent progress to scoring, comparison and reports.

2025 to 2026 · deployed product · continuing development

Product owner
Consultant method, diagnostic content and interpretation
QDev role
Product architecture, UX, engineering and reporting
Repository
QZee-Ltd/mtcc · application monorepo
Evidence
Sanitised product captures, reviewed code and labelled sample reports
Sanitised My Virtual Consultant dashboard showing diagnostic activity, invitation states, recent activity and reminders due
Sanitised product capture · August 2026The consultant opens on the state of every diagnostic in flight: completed work, invitations that need review, expiring links and recent activity. Names, organisations and figures are fictionalised.
Open full size: Sanitised product capture · August 2026 (opens in a new tab)View source case (opens in a new tab)

Preserve the method while removing its manual repetition

The difficult work was not digitising a questionnaire. It was making a configurable diagnostic remain internally consistent from input to recommendation.

A consultant-led diagnostic combines intellectual property, facilitation and a chain of calculations. Questions can belong to categories and domains, response options can carry different values, some scoring runs in reverse, and an individual answer can later contribute to a grouped view. If that logic is re-created separately in a form, spreadsheet, dashboard and report, small differences make the output harder to trust.

MTCC models the framework as configurable data and keeps the calculation path in a shared core. Consultants use an admin application to define or import diagnostics, manage respondents and inspect results. Respondents enter through a focused tokenised runner that autosaves and resumes. An API coordinates data, email and exports. Shared packages carry scoring rules, Firebase integration and interface primitives across those applications.

The product supports distinct business, ISO 9001 and sentiment diagnostic types, including diagnostic-specific response language. That is evidence of configurable product behaviour, not ISO certification, accreditation or endorsement. QDev’s role covered product structure, user journeys, application engineering, scoring implementation, visual reporting and export design. The consultant remained the authority on the diagnostic method and its use.

Build the invariant core before multiplying outputs

  1. 2025 · Definition

    Translate the consulting framework into data

    Mapped diagnostic types, questions, options, weighting, reverse scoring, categories, domains, respondents and engagements into configurable records.

  2. 2025 · Core build

    Separate consultant and respondent work

    Created focused admin and runner applications over one API and shared calculation model, with tokenised access and resumable progress.

  3. 2026 · Analysis

    Extend one scoring path into group views and exports

    Added respondent and role filtering, ECharts visualisation, spreadsheet interoperability and structured export formats.

  4. 2026 · Reporting

    Make the consulting outcome the product's final state

    Connected the score model to designed report outputs. Commit e11ad600a678 evidences report integration only, not the whole product or its production release.

Every application, shared package and output path

Capability status definitions

  • LiveAvailable in a public or deployed product.
  • ImplementedBuilt, but release or approval is not evidenced.
  • DemonstrationA labelled example using simulated data.
  • ExploratoryResearch, specification or prototype only.
Live

Consultant admin

The operating workspace for diagnostic configuration, engagements, respondents and analysis.

  • Question and option configuration
  • Spreadsheet import and versioning
  • Invitation and respondent management
  • Individual and grouped results

Repositoryapps/admin

Live

Respondent runner

A focused assessment experience that hides scoring machinery and preserves progress.

  • Tokenised access
  • Autosave and resume
  • Diagnostic-specific response labels
  • Review and completion

Repositoryapps/runner

Live

Application API

The service boundary for diagnostics, engagement state, invitations, analysis and export work.

  • Express routes
  • Firebase data access
  • Postmark email
  • Account-scoped request paths

Repositoryapps/api

Implemented

Scoring and analysis

One shared model rolls answers into comparable category, domain and group results.

  • Weighted and reverse scoring
  • 1 to 5 and 0 to 100 representations
  • Respondent and role filters
  • Grouped aggregation

Repositorypackages/core

Implemented

Visual and file outputs

Charts and exports carry the same result model into consultant analysis and client handoff.

  • ECharts circumplex and result views
  • CSV and XLSX
  • JSON
  • PDF reports

Repositoryapps/admin + packages/core

Demonstration

Published report examples

Sample documents show the intended hierarchy without revealing a client engagement.

  • Twelve-area overview
  • Strengths and focus areas
  • Domain detail
  • Sequenced recommendations

RepositoryReport integration at e11ad600a678

Two focused interfaces, one calculation path

From framework to usable report

  1. ConfigureDefine or import questions, response options and scoring rules.
  2. RunInvite a respondent into a tokenised assessment that autosaves.
  3. AnalyseRoll weighted answers into category, domain and group views.
  4. UseReview charts, export structured files and produce a report.

The live entry points evidence deployed access. They do not independently verify tenant isolation. Sample reports evidence output design, not client outcomes.

Inspect runner (opens in a new tab)

The operating product behind the report

These sanitised captures come from the working consultant application. They show how a framework is made publishable, how invitations are tracked and how report colours are checked before any result reaches a client. Fictional data replaces real contacts, organisations and diagnostic titles.

Sanitised My Virtual Consultant diagnostic builder showing readiness checks and a structured question table
Sanitised product capture · August 2026Readiness checks sit above the question set, connecting each item to its domain, category and sub-category before publication. Names and interface data are fictionalised.
Open full size: Sanitised product capture · August 2026 (opens in a new tab)View source case (opens in a new tab)
Sanitised My Virtual Consultant transactions screen with invitation creation and completed, accepted and expired lifecycle states
Sanitised product capture · August 2026Each invitation keeps its diagnostic, recipient, lifecycle, expiry and available action together, so stalled work is visible and can be resent. All identities are fictional.
Open full size: Sanitised product capture · August 2026 (opens in a new tab)View source case (opens in a new tab)
Sanitised My Virtual Consultant domain colour settings with hex values, contrast ratios and a too-pale warning
Sanitised product capture · August 2026Domain colours flow into reports and circumplex charts, so the interface calculates contrast against the report surface and flags colours that are too pale.
Open full size: Sanitised product capture · August 2026 (opens in a new tab)View source case (opens in a new tab)

From score pattern to next action

The report pages use demonstration data. Together they show the output hierarchy: first the overall pattern, then domain-level interpretation, then a practical sequence of actions.

Demonstration MTCC report overview with a twelve-area radar chart, strengths and focus areasDemonstration data
Demonstration report output · sample dataThe overview makes the overall pattern legible before the reader moves into domain detail.
Open full size: Demonstration report output · sample data (opens in a new tab)View source case (opens in a new tab)
Demonstration MTCC report page with domain summaries, category scores and focus guidanceDemonstration data
Demonstration report output · sample dataDomain and category detail turns a headline pattern into a more precise consulting conversation.
Open full size: Demonstration report output · sample data (opens in a new tab)View source case (opens in a new tab)
Demonstration MTCC report page translating a sample diagnostic pattern into four time-bounded recommended actionsDemonstration data
Demonstration output · sample dataThe report closes the loop by translating the sample score pattern into sequenced, time-bounded actions.
Open full size: Demonstration output · sample data (opens in a new tab)View source case (opens in a new tab)

The choices that make a configurable method dependable

  1. Model the method as data

    Decision
    Represent diagnostic types, questions, options, weightings and hierarchy as configurable records.
    Why
    The consultant needs to adapt the framework without asking engineering to rebuild an assessment.
    Consequence
    Business, ISO 9001 and sentiment diagnostics can share infrastructure while preserving their own language and rules.
    Tradeoff
    Configuration needs validation and versioning because a flexible model can create invalid combinations.

  2. Centralise scoring

    Decision
    Keep weighted, reverse, category, domain and group calculations in a shared core package.
    Why
    The admin view, charts and exports must not derive different answers from the same responses.
    Consequence
    One calculation path can feed analysis, ECharts and every export format.
    Tradeoff
    Changes to the core require broad regression coverage because they affect every downstream output.

  3. Split admin, runner and API

    Decision
    Use separate applications for consultant work, respondent completion and server responsibilities.
    Why
    Respondents need a low-distraction experience and should not inherit the admin application's controls or information density.
    Consequence
    Each application can optimise for its audience while sharing domain, UI and Firebase packages.
    Tradeoff
    Cross-application contracts and releases need coordination inside the monorepo.

  4. Autosave the respondent journey

    Decision
    Use tokenised access with resumable progress instead of requiring one uninterrupted assessment session.
    Why
    Long diagnostics are more reliable when an interruption does not erase completed thought or force hurried answers.
    Consequence
    Respondents can return to a known state and consultants receive more controlled completion behaviour.
    Tradeoff
    Token lifecycle, partial state and expiry become explicit data and support concerns.

  5. Design backwards from the report

    Decision
    Treat grouped results, focus areas and recommended actions as a primary product outcome.
    Why
    The diagnostic only creates value when a consultant can interpret and act on the pattern, not when a form is merely submitted.
    Consequence
    Question structure, scoring and visualisation are tested against the quality of the final consulting conversation.
    Tradeoff
    Report design exposes gaps in upstream data early and requires parity across screen and file outputs.

One monorepo, three applications, three shared foundations

Consultant application

QZee-Ltd/mtcc · apps/admin

Live

Owns diagnostic configuration, imports, engagements, respondents, analysis, charts and report workflows.

  • React
  • ECharts

Live authenticated entry and reviewed application code.

Respondent application

QZee-Ltd/mtcc · apps/runner

Live

Owns token entry, question progression, autosave, resume, review and completion.

  • React
  • Token access

Deployed runner route and reviewed application code.

Service application

QZee-Ltd/mtcc · apps/api

Live

Coordinates Firebase data, account-scoped routes, invitations, analysis support, Postmark email and export work.

  • Express
  • Firebase
  • Postmark

Account scoping is documented and implemented. Independent isolation testing is not claimed.

Shared domain package

QZee-Ltd/mtcc · packages/core

Implemented

Carries diagnostic models, scoring behaviour and reusable result logic across applications and outputs.

  • TypeScript
  • Scoring

Reviewed monorepo package and downstream use.

Shared interface package

QZee-Ltd/mtcc · packages/ui

Implemented

Provides reusable interface foundations while allowing admin and runner workflows to remain distinct.

  • React
  • UI primitives

Reviewed package boundary.

Shared data package

QZee-Ltd/mtcc · packages/firebase

Implemented

Centralises Firebase integration used by the application and service layers.

  • Firebase

Reviewed package boundary. No independent security certification is implied.

A repeatable consulting product with a visible reasoning chain

MTCC moves a configurable method out of one-off documents and spreadsheet assembly. Consultants can define, invite, compare and export from one system; respondents get a focused, resumable experience; and the same scoring logic reaches the chart, grouped view and report. The result is a product foundation for repeatable diagnostic work, not a static questionnaire.

Continuing development should pair that foundation with approved outcome evidence: completion behaviour, time saved in analysis, scoring regression coverage and verified tenant-isolation tests. None of those measures is inferred from the demonstration reports.

Turn your expertise into a product.

Define the rules, evidence and experience before development with product definition.

Discuss a project