Official website / landing page for drt

[Muawiya-contact]

Official website / landing page for drt

Opening this as the dedicated Ideas Discussion, following from #309.

Goal: a public landing page + docs site that funnels new users to pip install drt, shows the value prop and connector matrix, and links into the docs — without ever drifting from the repo (the SSoT requirement).

Proposed stack: Docusaurus (React-based static site generator). Why it fits both sides:

• It's React/Node/npm — the stack I'm most comfortable in, so I can move fast on the landing page.
• It generates the docs section from the repo's existing markdown (docs/ + README), so the repo stays the single source of truth — the site is just a view of it.
• The marketing landing page is a hand-built React page (src/pages/), so we get full design freedom there while docs stay auto-generated.
• Deploys free to GitHub / Cloudflare / Vercel Pages, with CI rebuild on every docs merge / release.

(Astro Starlight is a solid alternative if you'd prefer Astro; MkDocs Material is great too, but Python-templated rather than React.)

SSoT guardrails (matching your points):

• Docs generated from docs/ + README — no duplication.
• Connector matrix generated from the plugin manifests, so new connectors appear automatically.
• Version + install badges pulled live from PyPI.
• CI rebuild/redeploy on release/docs-merge so the site can't fall behind.

Page sections (first cut): Hero (value prop + pip install drt CTA) → Why reverse ETL with drt → Connector matrix (generated) → Quickstart → links into full docs.

Split (as you suggested):

• @masukai : infra — website repo, hosting, domain/DNS, CI sync + SSoT guardrails.
• @Muawiya-contact : landing-page design & build (layout, copy, React components) + docs theme.

If Docusaurus sounds good, I'll sketch a rough landing-page wireframe to start. What do you think of the stack?

[masukai]

Love this, @Muawiya-contact — thanks for opening a dedicated thread and for working through the SSoT angle before writing a line of code. That's exactly the right instinct. Let's do it. 🙌

Stack: Docusaurus 👍
Agreed. Your reasoning holds — docs auto-generated from docs/ + README keeps the repo as the single source of truth, and the hand-built src/pages/ landing gives us full design freedom where we actually want it. It's also the stack you're fastest in, which matters: I'd rather you move quickly on the part that needs creativity.

To keep us honest on SSoT, let's lock these guardrails from day one:

1. Separate repo: drt-hub/drt-web. Keeps the Python package clean and lets the site version/deploy independently. Docs are synced from drt-hub/drt via CI — never copied by hand — so there's still exactly one source of truth.
2. Docs generated from docs/ + README — no duplicated prose. The only way to change docs content is a PR to the main repo.
3. Connector matrix generated from the plugin manifests, so new connectors show up automatically — never a hand-maintained list.
4. Badges (version/install) pulled live from PyPI, and CI rebuild/redeploy on every release + docs merge, so the site can't drift behind the code.

Split — agreed:

• Me (@masukai): infra — create drt-web, GitHub Pages hosting + deploy workflow, domain/DNS, and the CI sync job that enforces the guardrails above.
• You (@Muawiya-contact): landing-page design & build (layout, copy, React components) + docs theme.

Page sections — your first cut is great (Hero + pip install drt-core CTA → Why reverse ETL with drt → generated connector matrix → Quickstart → into the full docs). One small add: let's keep the hero copy aligned with the repo's positioning — "Reverse ETL for the code-first data stack" — so the message stays consistent everywhere.

Next: yes please — go ahead and sketch the landing-page wireframe. In parallel I'll stand up the drt-web repo + a GitHub Pages deploy so you've got somewhere to drop the first components. To keep it simple we can ship first at drt-hub.github.io/drt-web/ and attach a custom domain once the landing's taking shape.

Thanks again for driving this.

[Muawiya-contact]

@masukai, yes, I will start work on that soon. A few things to be discussed here:

• We should use a modular approach, as you talked about. First, we create and deploy the first component. If everything is fine, then add more and more.
• Completely sync with repo.
• It is important to create pages on social media accounts such as Facebook, X, and especially LinkedIn. LinkedIn is particularly important; I often post there, but there is no benefit from using the hashtag #drt-hub because there isn't a dedicated page for it.

Further, we will discuss here. For now Can you review and the PRs i open #657 and #659. im working on #619 ready to open PR. im just waiting to prevent conflit.
Thanks ❤️.

[masukai]

Sorry for the slow reply here, @Muawiya-contact — and thank you 🙏

PRs: both merged — #659 (VS Code extension) and #657 (OTel Phase 3), reviewed and green. #664 (the #658 export-flush follow-up) I've reviewed on the PR — it needs a clean rebase (left the details there).

Modular approach: 100% agreed — let's ship the first component (hero/landing) to drt-hub.github.io/drt-web/, confirm it's clean and fully synced from the repo, then grow it section by section.

Social:

• X: there's already an account — @drt_hub. Full transparency though: it's basically dormant right now — I haven't been posting, and I haven't decided on any operating/content plan yet. So consider it an open area.
• LinkedIn: agreed it's worth doing. I'll set up the official page myself — I want to keep the brand/social accounts under the project's own control (continuity + credentials) — and I'd really value your help shaping content and amplifying once it's up. Having the landing page live first will make the social push land much better, which is another reason to ship the site's first piece first.

Looking forward to the first wireframe whenever you're ready 🚀

[Muawiya-contact]

First pass at the landing is live 🎉 → https://drt-landing-page.netlify.app/

Built it brand-accurate (the violet #7C3AED straight from the icon), with the sections we agreed on:

• Hero — "Reverse ETL for the code-first data stack" + a live drt run terminal, and the dlt → dbt → drt lineage with drt as the lit "activate" step.
• Why drt — code-first, 25+ destinations, dbt-native ref(), OpenTelemetry, dry-run/diff, CI-native.
• Connectors — destinations + sources grid, with a "generated from connector manifests" badge so the SSoT intent is visible in the design itself.
• Quickstart — three steps + a real sync YAML.
• Light + dark mode, using the same data-theme convention Docusaurus uses, so it ports cleanly.

It's a static HTML mockup on purpose — so we can lock the look before I convert it to Docusaurus src/pages/. A couple of things that are placeholder until your CI lands: the connector list/colors (real matrix will be generated from manifests), and the copy can flex to match the repo's voice.

What do you think of the direction? Once drt-web is up I'll open the first PR with the Docusaurus port of this.

[masukai]

This is genuinely great work, @Muawiya-contact — and fast 🔥 The direction is right: brand-accurate violet, the hero with the live drt run terminal + the dlt → dbt → drt lineage, the connectors grid with the "generated from manifests" badge making the SSoT intent visible in the design itself, and light/dark via the Docusaurus data-theme convention so it ports cleanly. Let's ship this direction.

Two small accuracy fixes for the copy:

• Install is pip install drt-core — the PyPI package is drt-core (the CLI is drt). Your landing already has this right; just locking it in.
• Connector count — let the generated matrix drive it rather than a hardcoded "25+" (it's ~30+ destinations now, and the real number should come from the data so it can't drift).

And the unblock you were waiting on — drt-hub/drt-web is up, with the full SSoT pipeline already wired and verified:

• Live now (placeholder): https://drt-hub.github.io/drt-web/
• sync-from-drt.yml regenerates the connector matrix from drt's own CLI (drt destinations|sources --format json) → data/*.json, pulls docs/ + README.md → synced-docs/, and reads the version from PyPI. It runs weekly + on a drt-updated dispatch fired from the drt repo on every release/docs change, and opens a PR (see docs: add CHANGELOG.md for v0.1.0 #2) rather than committing — so nothing deploys without review.
• deploy.yml publishes to GitHub Pages on merge to main.

So: open your Docusaurus port PR against drt-hub/drt-web (app at the repo root — package.json, docusaurus.config.js with baseUrl: '/drt-web/', src/pages/ + docs/). Wire the matrix to data/*.json and source docs from synced-docs/ — they stay in sync automatically, so your placeholders become real data with zero upkeep. deploy.yml switches from the placeholder to your Docusaurus build the moment package.json lands.

The repo README has the contract written up. Excited to see the port — this is going to be a great front door for drt 🚀

[Muawiya-contact]

@masukai, do you have any updates? Let's discuss the next idea or page we should build. Instead of just starting to build, we should think and dive in first. What is your opinion about the next page?

[masukai]

Good call to scope it before building, @Muawiya-contact 🙌 The landing's a great front door — I think the highest-value next piece is the docs section: turn the synced-docs/ we're already pulling into a browsable Docusaurus docs nav. That makes the repo's own docs/ (connector reference + guides) the public docs site — completing the original landing + docs SSoT vision, and it's already half-wired (the sync brings the content; we just expose it via the docs plugin + sidebar).

Concretely:

• Connector reference pages from synced-docs/connectors/* — pairs perfectly with the landing's connector matrix (click a connector → its doc).
• The guides (synced-docs/guides/*) as a "Guides" section.
• Keep it generated/SSoT — no hand-maintained content.

Later candidates: a dedicated connector catalog page + a blog (releases / build-in-public). But docs first — it's the backbone. The connector reference is probably the cleanest first slice. What do you think?

[Muawiya-contact]

@masukai Agreed — docs section next, and connector reference as the first slice is the right call. It completes the original landing+docs SSoT vision, and since the sync already pulls synced-docs/, it's mostly wiring: docs plugin + sidebar, no hand-maintained content.

Scoping it before building, as you said:

• Connector reference from synced-docs/connectors/* — one doc page per connector, auto-discovered so new connectors appear without edits. This pairs with the landing's connector matrix: click a connector in the grid → its reference page. That cross-link is the thing that makes the two pieces feel like one site.
• Sidebar grouped Sources / Destinations / Integrations, mirroring the README matrix structure so the mental model is consistent.
• Guides (synced-docs/guides/*) as a second section right after — same generated approach.
• SSoT: sidebar generated from the synced file tree (autogenerated Docusaurus sidebar) rather than a hand-listed one, so it can't drift from what the sync brings.

One thing worth deciding up front: the connector-matrix → connector-doc link needs a stable slug convention shared between data/*.json (matrix) and synced-docs/connectors/* (pages). If the sync already emits a common key (connector id / filename), I'll key both off that so the links never break as connectors come and go.

Want me to fold the connector-reference docs nav into the same Docusaurus port PR as the landing, or land the landing first and add docs in a follow-up? I'd lean landing-first (ship the front door, confirm it's clean and synced), then docs as PR #2 — matches the modular approach we agreed on.

[masukai]

@Muawiya-contact — landing-first, agreed 👍 Ship the front door as PR #1, confirm the sync + deploy pipeline is clean, then the connector-reference docs nav as PR #2. Exactly the modular rhythm that's been working for us.

On the slug convention — I did a full cross-check of the current data, and there's already a de-facto convention we can just bless:

• Canonical key = the registry type (snake_case: email_smtp, rest_api, …). It's what data/*.json already carries, and it's the one identifier guaranteed stable because it is the connector's YAML config surface.
• Doc slug = kebab-case of the type (type.replace('_','-')). This already holds for every one of the 30 type↔doc pairs that exist today (email_smtp → email-smtp.md, github_actions → github-actions.md, etc.) — so keying the matrix→doc link off kebab(type) needs zero renames and never breaks as connectors come and go.

Two things the cross-check surfaced that are worth handling in the same pass:

1. Four connectors have no doc page yet (duckdb, redshift, sqlite, sqlserver — source-side). The matrix should degrade gracefully for those — render unlinked (or point at the README row) rather than 404, so a missing page is cosmetic, not broken.
2. data/*.json is lagging the registry — it has 34 entries and none of the v0.7.9/v0.8 connectors (Klaviyo, Airtable, Mixpanel, S3, GCS, Azure Blob, Elasticsearch, Delta Lake, Iceberg) even though their doc pages are already in synced-docs/connectors/. Whatever regenerates the matrix should come from the registry the same way the docs sync does — then "new connectors appear without edits" is true end-to-end, matrix included.

So: sidebar autogenerated from the synced tree (as you proposed), matrix keyed on type, links via kebab(type), graceful no-page fallback, and a matrix regen wired to the registry. That combination means nothing in the site is hand-listed. 🚀

[Muawiya-contact]

Hi @masukai! 👋

No rush at all on these issues. (#26,#27,#28) I opened them mainly to capture ideas while they're fresh and to provide a roadmap for future improvements.

Whenever you have some time, just review them one by one at your own pace. If any idea doesn't fit the direction of the project, I'm completely happy to revise it, split it, combine it, or close it.

Thanks again for all the guidance on drt-web—I'm looking forward to continuing to build it together. 🚀