8 companies is a demo-scale dataset, not a statistically meaningful sample. The queries below demonstrate schema design and SQL fluency — not a production warehouse or a claim about the broader dev-tool market.
I don't have production Snowflake/Databricks experience, and I'm not going to pretend a weekend demo gives me it. What I can show honestly is the actual skill underneath that line on a job description: designing a normalized schema for GTM data (accounts → signals → activities) and writing SQL that answers real questions against it. SQLite is the honest stand-in — same relational shape, zero infrastructure, nothing to fake.
Full file: schema.sql — 4 tables, one row per real event captured by the other three demos in this portfolio.
| table | rows | sourced from |
|---|---|---|
| companies | 8 | github.com/<org>/<repo> metadata, signal-engine-demo |
| signals | 8 | commit-velocity scores, signal-engine-demo / signal_score.py |
| briefs | 1 | generated brief, account-brief-demo / brief_generator.py |
| drafts | 1 | drafted outreach message, signal-engine-demo / draft_outreach.py |
Full file: queries.sql — run locally with python3 load_data.py && sqlite3 warehouse.db < queries.sql. Every result below is the actual output of that command against the real dataset.
SELECT c.repo, s.score, s.velocity_change_pct FROM companies c JOIN signals s ON s.company_id = c.company_id ORDER BY s.score DESC;
| repo | score | velocity_change_pct |
|---|---|---|
| ComposioHQ/composio | 183.3 | 183.3 |
| mem0ai/mem0 | 61.7 | 61.7 |
| block/goose | 42.2 | 42.2 |
| browser-use/browser-use | 0.0 | -91.7 |
| e2b-dev/E2B | 0.0 | -15.8 |
| langflow-ai/langflow | 0.0 | -77.7 |
| crewAIInc/crewAI | 0.0 | -21.2 |
| letta-ai/letta | 0.0 | null |
JOIN signals → LEFT JOIN briefs → LEFT JOIN drafts, ordered by score
| repo | score | has_brief | has_draft |
|---|---|---|---|
| ComposioHQ/composio | 183.3 | no | yes |
| mem0ai/mem0 | 61.7 | yes | no |
| block/goose | 42.2 | no | no |
| browser-use/browser-use | 0.0 | no | no |
| e2b-dev/E2B | 0.0 | no | no |
| langflow-ai/langflow | 0.0 | no | no |
| crewAIInc/crewAI | 0.0 | no | no |
| letta-ai/letta | 0.0 | no | no |
This is the honest state of the pipeline: only 2 of 8 companies were ever taken past the scoring step, because the brief and draft demos were each run once, by hand, against a top-scoring company — exactly what "no fabrication" looks like when the dataset is this small.
SELECT c.repo, c.stars, s.score FROM companies c JOIN signals s ... ORDER BY c.stars DESC;
| repo | stars | score |
|---|---|---|
| langflow-ai/langflow | 151,180 | 0.0 |
| browser-use/browser-use | 102,817 | 0.0 |
| mem0ai/mem0 | 60,126 | 61.7 |
| crewAIInc/crewAI | 54,940 | 0.0 |
| block/goose | 50,669 | 42.2 |
| ComposioHQ/composio | 29,096 | 183.3 |
| letta-ai/letta | 23,658 | 0.0 |
| e2b-dev/E2B | 12,844 | 0.0 |
The two most-starred repos in the set are both decelerating right now — star count is a lagging popularity signal, not a proxy for current momentum. That's the actual argument for signal-based targeting over static list size, made by the join, not by me asserting it.
Queries 2, 4, and 5 (acceleration-bucket counts, the full signal→draft trace for Composio, and raw commit-volume totals) are in queries.sql with the same real-output guarantee — trimmed here for length, not cherry-picked for the result.
Full files: schema_attribution.sql, generate_attribution_data.py, attribution_queries.sql.
Unlike the tables above, channels/touches/opportunities are synthetic — these 8 open-source repos never ran through a real sales funnel. Rather than fabricate a fake case study, generate_attribution_data.py documents every generation rule in its docstring: 6 channels reused from the real ones run in a prior GTM role, a deterministic seeded touch sequence per company, and a won/lost/open status derived directly from each company's already-real signal score. Rerun it and the output is identical — nothing here is hand-picked per row.
This models the piece of GTM engineering the rest of this warehouse doesn't touch: the plumbing that tells you whether a channel is actually moving revenue. Four attribution models — first-touch, last-touch, linear, and U-shaped (40/40/20) — computed with plain SQL over the same 3 won deals.
first-touch vs. last-touch vs. linear vs. U-shaped, per channel
| channel | first-touch | last-touch | linear | U-shaped |
|---|---|---|---|---|
| linkedin_outbound | $10,078 | $7,666 | $6,083 | $7,582 |
| warm_list_reactivation | $7,666 | $0 | $3,661 | $4,113 |
| cold_email | $0 | $5,234 | $3,661 | $2,860 |
| affiliate_program | $0 | $4,844 | $2,422 | $2,422 |
| agency_partner | $0 | $0 | $1,917 | $767 |
linkedin_outbound wins under every model — but the #2 channel flips depending which model you run: warm_list_reactivation by first-touch, cold_email by last-touch. And agency_partner gets zero credit under either single-touch model despite being a real touch in the funnel — it only shows up once linear or U-shaped credit is run. That's the actual argument for running more than one attribution model before cutting a channel's budget, made by the query, not by me asserting it.
The other three demos in this portfolio (signal-engine-demo, account-brief-demo, the mem0 audit) each produce a real result in isolation. GTM engineering also means giving separate outputs one queryable home — this is that step, done honestly at the scale the underlying data actually supports.
Or write directly: ai.adityachouhan@gmail.com