Mashdun
AI GrowthWorkCapabilitiesIntegrationsProcessLabsMarketplaceBlogAbout
Get in Touch
Mashdun

Full-stack web developer, AI engineer & growth marketer. Building production-grade apps and intelligent solutions.

Navigation

  • Portfolio
  • Capabilities
  • Process
  • Labs
  • About

Resources

  • Blog / Notes
  • Marketplace
  • Contact
  • RSS Feed

Legal

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Do Not Sell or Share
  • Delete my data

© 2026 Mashdun. All rights reserved.

Built with Next.js, Tailwind CSS & Prisma

    All Labs
    Engineering
    First-party CDP
    ICP Scoring
    Lifecycle Automation
    Product-led

    The Growth Stack

    The whole loop on one page, and a button that runs it end to end in under a minute. Advancing a project to production emits an event through our own collector, which updates the account's behavioural signals, which moves its ICP score and fires a routing rule that queues a drafted follow-up. For a parts supplier, prototype → production is the account-graduation moment — and it is the one signal no data vendor can sell you, because it happens inside your own product.

    The Growth Stack

    First-party CDP
    ICP Scoring
    Lifecycle Automation
    Product-led

    Three labs, one system. An engineer's action becomes a signal, the signal changes a score, and the score triggers an automated, personalised next step.

    1. 1Apply fix

      The failed fingertip is redesigned as Rev B

      LynIP
    2. 2Retest passes

      Rev B records its own bench test

      LynIP
    3. 3Gate opens

      Every Must requirement Satisfied on Rev B

      LynIP
    4. 4Event

      Project Stage Changed, emitted server-side, once

      Event layer
    5. 5Score

      Behavioural signals move the ICP score

      SDR pipeline
    6. 6Rule fires

      Keyed on the transition, so it fires once

      SDR pipeline
    7. 7Draft queued

      A follow-up citing the project, for review

      SDR pipeline
    Applies the fix to GripLite, retests it, and moves it to production — the same calls LynIP makes.

    What this stack does not do

    17 named

    Kept in lib/growth/gaps.ts and rendered from there, so it cannot drift from the code. An entry is deleted in the commit that closes it, never softened into a roadmap item.

    experimentation

    • Fixed-horizon tests only
      not built
      The analysis refuses a verdict before the pre-registered sample size, because a fixed-horizon interval is only valid read once. Always-valid sequential testing is not implemented.You cannot legitimately stop early on a big win. At B2B sample sizes that is the difference between a decision this quarter and one next year.
    • Two arms, no multiplicity correction
      not built
      Only control against the first treatment is compared. A third arm is reported descriptively, with no Bonferroni or Benjamini-Hochberg adjustment.Multi-arm messaging tests would overstate significance, and the tool would not warn you.
    • No variance reduction
      not built
      No CUPED or covariate adjustment using pre-exposure behaviour.Sample sizes are larger than they need to be — often by 2x — which on a low-traffic B2B site is the constraint that decides whether a test is runnable at all.
    • Every baseline is a placeholder
      not built
      Both registered experiments are `draft` and have never run. Their baseline rates are stated as unmeasured, so the sample-size horizons computed from them are illustrative too.The machinery is real and tested; the numbers it would act on are not yet. Nothing here has told anyone anything about a real audience.

    attribution

    • No attribution model
      not built
      The Measure panel is a live event tail. There is no first-touch, last-touch, position-based or data-driven attribution, and no channel spend joined to outcomes.The stack can say an account converted and what it did first. It cannot say which channel to credit, so it cannot answer a budget question.
    • No cost data, so no CAC or ROAS
      not built
      The build-vs-buy panel prices tooling. Nothing ingests ad spend, agency cost or sales time.Efficiency claims are unavailable rather than estimated — which is the honest answer, and still an answer nobody can act on.

    data infrastructure

    • No warehouse
      not built
      Analysis queries the operational Postgres directly. There is no dbt project, no modelled layer, and no separation between serving and analytics load.Correct at this size and wrong at any real one: a long analytical scan competes with page renders on the same instance.
    • Identity resolution stops at the email domain
      not built
      A profile joins to an account by the domain in an email address. No CRM identity join, no reverse-IP company resolution, no cross-device beyond stitched anonymous ids.Anonymous traffic from a target account is invisible until somebody types an email address, which is most of the funnel.
    • Consent is gated but not auditable
      not built
      Collection is gated on the analytics consent category. There is no consent audit trail, no record of which version of a notice was accepted, and no deletion or export path.Enough to behave correctly; not enough to answer a data subject request or prove behaviour after the fact.

    pipeline

    • The sequencer drafts but never sends
      not built
      There is no sending infrastructure: no domain warmup, no bounce or complaint handling, and no suppression list enforced at send time.Deliverability is most of whether outbound works, and none of it is modelled here. A reply-rate experiment cannot run without it.
    • Enrichment vendors are adapters, not connections
      not deployed
      Provider adapters exist and are env-gated. None is configured, so coverage and cost figures come from fixtures rather than from a live account.The build-vs-buy comparison is structurally right and has never been priced against a real invoice.

    geometry

    • The geometry service is not deployed
      not deployed
      services/geometry has a Dockerfile and 23 passing tests. GEOMETRY_SERVICE_URL is unset, so the viewer serves recorded figures from a real earlier run.Every geometry number on the site is a replay. They are real measurements; they are not being taken now.
    • No manufacturability rule is cited to a published standard
      blocked
      Every rule carries source: "project brief", source_url: null, verified: false and checked_on: null. The rules are ordinary process constraints, but the specific thresholds — 1.5 mm minimum wall, pocket depth within a few cutter diameters — are not traced to a handbook or a process standard anybody read.The rule set is the right shape and may carry the wrong numbers. It is labelled unverified everywhere it appears rather than quietly presented as current. The vendor name that used to sit on it has been removed: it implied an authority the thresholds did not have.
    • DFM findings cannot be highlighted in the viewer
      not built
      dfm.py finds a defect on a B-rep face; GLB tessellation discards face identity, so three.js can only pick a triangle. No face-to-triangle-group mapping is baked at export.A reader is told a corner is too tight and cannot be shown which corner.
    • Enclosure inputs are illustrative
      not built
      The derived enclosure measures real geometry, but the component dimensions feeding it are a stand-in rather than read from STEP models or datasheets.The derivation is demonstrated. It has not yet been run against a real board.
    • The Python suite does not run in CI
      not built
      .github/workflows has no pytest or ruff step for services/geometry, so its 23 tests only run when somebody runs them by hand.A change to the geometry service can merge red.

    labelling

    • The 3D panel is mislabelled
      not built
      The LynIP viewer panel is titled "AI 3D model" and badged `live` while serving recorded figures from an undeployed service. Nothing in that path involves a model, and it is not live.It contradicts the four-state provenance vocabulary the rest of the labs are built on, on screen, which is exactly the failure the vocabulary exists to prevent.

    First-Party Event Layer

    page/track/identify in the Segment Spec shape, our own collector, identity stitching, optional vendor mirrors.

    LynIP: Invention to Production

    Idea → parametric 3D model → slice → BOM → verify → revise → DFM → production package, with provenance on every number.

    AI SDR Pipeline

    Source → enrich → score → route → sequence, with a source URL and a supporting quote on every enriched field.

    How it works

    1. A bench test fails, so the design changes: the fix becomes Rev B, with its own retest.
    2. The production gate opens on Rev B — and only on Rev B — once every Must requirement is Satisfied.
    3. Moving to production becomes one event in our own store, emitted server-side so it cannot be forged or doubled.
    4. The account's ICP score moves, and the reason is stated rather than implied.
    5. A routing rule fires once and queues a drafted follow-up that cites the project.

    Why this moment

    For a parts supplier, prototype → production is the account-graduation moment: it is when a company stops evaluating and starts buying, and it is the one signal no data vendor can sell you, because it happens inside your own product.

    Start at the beginning: idea to production package