Prepared for CareerPlug · July 2026
VisionWrights operates a composable analytics platform assembled from established open-source components. This page describes the platform's structure, the default tools in each role, the selection criteria each component passed, the status of CareerPlug's migration pilot, and answers to questions raised by CareerPlug's engineering team.
01 · The architecture
Each layer in the architecture below has a single defined role and a default component filling that role. Every layer connects to the next through a stable, standard interface — SQL, open table formats, or versioned API contracts — so components can be upgraded or replaced independently. Click any layer to expand its bonafides. The dashed boundary marks what Dagster orchestrates and observes.
These engineering teams reached their conclusions independently — every evidence link in the expandables above is a first-party case study or engineering blog, and the layered pattern itself is the industry's converged blueprint — a16z emerging architectures →
02 · Component selection — Why these defaults
Each role in the architecture above is filled by a default component, and every default passed the same selection checks — the ones that matter most for this evaluation are below; the full nine-check rubric, including what disqualifies a component, is in the technical appendix.
The license is permissive enough to embed in a product, run in the client's own account, and hand to an internal team — and it permits independent continuation if the vendor relationship ends.
Active maintainer base and governance structure that outlasts any single vendor. Foundation governance (Apache) and fork-permitting licenses are the clearest forms of this.
Named companies with first-party engineering evidence — blogs, case studies, and conference talks from the practitioners who run it.
Every component deploys to the client's existing cloud account and runs natively on their data warehouse — the client controls the infrastructure and the data, end to end.
Each layer sits behind a contract — the semantic layer API, the dbt SQL contract, the orchestrator's asset model — so components upgrade or swap independently.
Product embedding and per-user RLS are first-class capabilities of the layer, enforced server-side before data leaves the semantic layer.
03 · Migration pilot
To demonstrate migration speed, VisionWrights migrated one of CareerPlug's production dashboard suites onto the platform during the evaluation — hours per dashboard with the translation tooling described below, days for the full suite. The suite runs against CareerPlug's June data; every figure matches Domo's output to the unit on hires and to the cent on revenue, and the reconciliation checks remain in the pipeline as permanent tests — standard dbt test functionality, applied per VisionWrights' implementation practice. The remaining suites will follow the same path in the migration proper.
Responsive, viewport-aware dashboards in CareerPlug's product surfaces — web and mobile — using the same integration pattern as the current embeds. Row-level security is enforced server-side via signed tokens; per-user scope is set at the semantic layer before any data reaches a browser.
Every load-bearing component carries a permissive license (Apache 2.0 or equivalent) that deploys freely on CareerPlug's own infrastructure, without per-seat reader pricing or per-query metering. Platform costs are the VisionWrights subscription — the assembled software, its operation, upgrades, and support — plus CareerPlug's own infrastructure. Metabase's AGPL edition serves internal analysts; product embedding uses the VisionWrights widget (proprietary, source delivered) or Superset (Apache 2.0).
Plain SQL in dbt, in a git repository — readable by any analyst, diffable, testable, reviewable in a pull request. dbt runs natively on Redshift; everything moves to CareerPlug's AWS account when ready. The work produced during this engagement remains valid under any future infrastructure decision.
Natural-language query for staff and partners who work outside BI tools — restricted to governed measures only, so generated queries cannot reach un-modeled data. The generated SQL is shown; the system escalates rather than improvising when asked for something outside the semantic layer.
Measure definitions live once in the semantic layer and serve every tool — the BI dashboards, the embedded widget, the plain-language interface, and future AI modalities. Full lineage, per-step SQL, test results, and freshness in one operations portal rather than five separate consoles.
Per-user signed tokens; RLS enforced at the semantic layer API before any data leaves the server. Tenant isolation and per-engagement data-access grants are enforced by design. Audit lineage is available on request.
04 · See it
The live environment is at careerplug.bi.visionwrights.com — a recorded walkthrough of the rebuilt analytics and the logins are on their way separately, so CareerPlug's team can drive it on their own schedule. CareerPlug's engineers can also go straight to the technical appendix.
05 · Questions from CareerPlug's engineering team
The questions CareerPlug's engineering team raised about the platform — answered on their technical merits. The full component inventory and deployment models are in the technical appendix.
The decision at hand is whether to start a parallel build — pipelines running against CareerPlug's data while Domo keeps running, untouched and fully authoritative, with no change visible to any user. The build and reconciliation stages run entirely on the VisionWrights side and require nothing from CareerPlug's team beyond the data access already in place for the evaluation. Nothing user-facing moves until the internal-trial stage, and each production surface cuts over only on CareerPlug's team's explicit signoff for that surface.
That path is how the stack was designed. dbt runs natively on Redshift — CareerPlug's Redshift, in CareerPlug's account — and the past year of work moving logic into Redshift fits this design: the platform is built to run against the warehouse CareerPlug already owns. The technical appendix defines three deployment models (A through C); model C puts everything in CareerPlug's AWS — dbt against Redshift, Dagster on ECS or MWAA, BI tools on client infrastructure. Moving from the current VisionWrights-hosted evaluation environment to CareerPlug's account is configuration and deployment work; no component is tied to where it runs. VisionWrights operates the platform as code in every model — deployment, configuration, and monitoring are programmatic — so the same automation that runs the evaluation environment runs identically inside CareerPlug's account, under a scoped deployment role CareerPlug grants and can audit. The SQL, models, tests, and measure definitions transfer regardless of which infrastructure decision is made.
The VisionWrights-built portion is principally a transparency layer: a platform sitemap, monitoring, and health visualization that sits on top of the tools comprising the platform. It is built for operator convenience and visibility — surfacing live lineage, per-step SQL, test results, and freshness from dbt, Dagster, and Cube in one view rather than five separate consoles. Every underlying function — pipelines, dashboards, embeds, row-level security — continues unaffected if this layer is unavailable. It is proprietary to VisionWrights and part of the platform's value; it is not load-bearing for the data itself.
The custom surfaces are thin by design, and each has a clear ownership shape. The product-embedded widget (React/JS over documented semantic-layer APIs) is delivered as source into CareerPlug's repository from day one — licensed for use, modification, and continued operation, and small enough for one in-house engineer to review and maintain; source review is available before any commitment. The plain-language query builder and operations portal are VisionWrights' platform product, built to serve many clients and operated as part of the platform: the builder composes queries from the semantic layer's named measures only, surfaces its generated SQL, and escalates when asked for anything outside the semantic layer; its architecture and behavior are walked through with CareerPlug's engineers on request. Every underlying data function continues unaffected without either surface.
Reconciliation runs as a permanent test suite inside the pipeline on every build — dbt's built-in test framework, applied as best-practice implementation from VisionWrights' experience with this technology. The suite covers the measures the business actually reads — total hires matched to the unit, revenue matched to the cent, and the table-level totals behind every major surface. A check that fails blocks promotion, so a number that stops matching is caught at build time. The tests are plain dbt tests in CareerPlug's repository; CareerPlug's team can run them, inspect them, and extend them. The oracle is Domo's own output during the migration window, so correctness is demonstrated against the system CareerPlug already trusts.
A senior data architecture and engineering team, with AI-accelerated delivery that compresses timelines — the firm's data architecture and governance experience shapes the work; AI tooling shortens the build time. A term agreement commits VisionWrights to deliver a working solution for that term; the technology choices underneath remain changeable during the same period — components swap inside the agreement as needs and the industry change. The engagement scales from fully managed to co-owned to client-operated, and the artifacts (dbt models, semantic layer definitions, test suite) belong to CareerPlug at every stage. The glide path toward a CareerPlug data engineer hire is built into the design: that engineer would inherit a documented, tested codebase built on standard tools.
The demo recording, live-system logins, and the technical appendix accompany this page — review at the team's own pace. Questions travel well in writing and get written answers: mark@visionwrights.com.