Skip to main content
Built for ASU · ASU+GSV 2026

Built for ASU.

Using the same process we run our own agency on.

Kimberly, Nate, Kyle, Roger — this page is the follow-up to Monday at GSV. Everything we promised is below. Nothing else.

Read the build logSee how it works
The 60-second version

Who is BetaCraft

BetaCraft is an AI-native product engineering firm — agents ship code alongside humans on every engagement. Led by founder Ratnadeep Deshmane and partner Mayuresh Soni — both serial founders who built, scaled, and exited digital products before joining forces at BetaCraft. We run digital transformation for enterprises, research universities, and mission-driven institutions across education, philanthropy, research, healthcare, fintech, civic tech, and aerospace.

Higher-ed is not new territory. Our active SDD programs include Georgetown University’s Center on Education and the Workforce (credential-to-jobs data viz across 55 U.S. metros), and our long-running Stanford Solutions Science Lab partnership (Our Voice, CORD) is delivered by a remote eight-engineer squad working in daily partnership with the California-based faculty team. For ASU, the points of contact are named and accountable: Mayuresh Soni as engagement lead, Ratnadeep Deshmane as tech lead.

Our engineers slot directly into your delivery process — PI planning, CAB reviews, procurement gates, security and vendor-risk review — and rewire it from the inside. Six-week discoveries compress to two. Quarterly release trains compress to weekly. Your internal team gets faster without getting bigger.

That is Stakeholder-Driven Development. Every person on the project team moves the build forward directly, not just the engineers. PM writes a spec, agents scaffold the tickets. Designer drops a Figma frame, agents wire the component. Domain expert types a question in plain English, gets a verified answer from the shared substrate. Engineers do engineering; everyone else stops waiting on a ticket and starts shipping.

How we are different from Claude itself: Claude ships horizontal, domain-agnostic tools — coding agents, design surfaces, general-purpose primitives that work for anyone. We build specialized agents scoped to your problem. This page was built by agents we defined for this job — a design agent that knows our visual system, a content agent grounded in our case studies, an Astro agent that knows this codebase. Our agentic layer sits on top of Claude, inherits your business goals and domain context, and ships an outcome Claude on its own cannot.

SDD is that operating model, codified. It is also the process that built this page: eleven specialized agents, four stakeholder lenses, one shared substrate — every state-mutating output reviewed by a human tech lead. You are talking to the firm that authored the methodology, not one retrofitting AI onto a 2019 playbook.

Clients served
50+
Projects completed
150+
Industries
10+

BetaCraft at a glance

The facts, not the pitch.

Built to last, not to flip. Self-funded since 2019, 30%+ EBITDA, and the margin to pick engagements we can fully own. Size is not the metric; per-sprint throughput is.

On-time delivery
95%
EBITDA margin
30%+
Funding
Self

Compliance experience

We are not a certified entity — we build products that pass our clients’ audits. BetaCraft engineers have shipped into these regulatory regimes end-to-end: requirements mapping, control implementation, audit support, remediation.

  • FERPA — built for

    HeuriSight, Stanford, CodePath — production traffic under client FERPA review

  • SOC 2 Type II — built for

    DevSecOps stack (SonarCloud, Vanta, New Relic) wired into client certifications

  • HIPAA — built for

    Mocingbird telehealth and OrthoAi dental imaging — passed client HIPAA audits

  • FDA food-safety — built for

    Suntory food-compliance automation in production

Teams and organizations we have built for

We have built platforms, AI tooling, and full products for partners across education, philanthropy, research, healthcare, fintech, civic tech, and aerospace. The list below is a partial cross-section — some engagements are under NDA, some are pre-launch — and every logo here is work we can walk through on a Zoom.

  • iSoftpull
  • GreenFig
  • Teplo
  • CodePath
  • Programination
  • Gates Foundation
  • Stanford University
  • Ziplines
  • Skyryse
  • Georgetown University
  • Ashoka Changemakers
  • Intel
  • iSoftpull
  • GreenFig
  • Teplo
  • CodePath
  • Programination
  • Gates Foundation
  • Stanford University
  • Ziplines
  • Skyryse
  • Georgetown University
  • Ashoka Changemakers
  • Intel
50+Clients served25M+Active users reached95%On-time delivery
The coordination problem

Every AI multi-stakeholder project has the same failure mode

AI agents ship faster than teams can agree on what to build. A single Cowork session can produce thousands of lines of code, a dozen design choices, three migrations — each one made on the agent’s best read of what the team wants. Production is no longer the bottleneck. Alignment is.

Coordination used to be a PM function. In agentic development it is the governor — the thing that decides whether AI velocity becomes real progress or confidently-wrong output at scale. Every multi-stakeholder AI project fails in the same three places:

  1. Beat 1: Context lives in five-plus tools.

    Clients live in email. Devs live in GitHub. PMs live in docs. Designers live in Figma. Every stakeholder sees a slice. No one sees the whole truth. The status update in the standup is a best-guess reconciliation.

  2. Beat 2: Unified workspaces ask for too much.

    Notion, Linear, Atlassian all try to solve this by replacing the native tools. Stakeholders refuse to leave Figma, GitHub, or their inbox. The unified workspace becomes another tab — another source of drift.

  3. Beat 3: AI is sold as a feature, not a substrate.

    Copilots inside individual tools make one stakeholder faster. They do not make the team aligned. No one can ask "what did we decide, why, and what is at risk?" and get a cited answer across every source.

SDD · BetaCraft’s operating model

Stakeholder-Driven Development — the process we run our agency on

Clients live in email, devs in GitHub, PMs in docs, designers in Figma. SDD inverts the "unified workspace" approach — the substrate underneath is unified, the surfaces on top stay native. Every artifact lands in one append-only event log. Agents specialized to your project read from it, cite it, and answer in each stakeholder's voice.

The agents are not generic. They are defined per-engagement — briefed on your domain, your stakeholders, your guardrails — and they sit on top of Claude. You get a cited answer to any question — what did we decide, what is at risk, who owns what — without anyone abandoning their tools or learning a new one.

“Preserve native tools. Unify the substrate underneath. Give each stakeholder their own surface.”
BetaCraft · SDD thesis

  • Event log

    Append-only Postgres table. Every commit, message, email, transcript, file upload normalized to one shape. Immutable — state changes are new events pointing at the original.

  • Cowork plugin

    One plugin, one MCP, six skills. The team lives in Cowork; the plugin owns git mechanics, catchup digests, proposals, ingestion, and session boundaries.

  • Graph + vector retrieval

    Keyword, vector, and graph traversal fused via Reciprocal Rank Fusion. Every cited answer is backed by an edge chain — decisions trace through source events to the people and artifacts behind them, not just to semantically similar chunks. Derived entities are typed projections, regenerable from the event log.

  • Client portal

    Magic-link login, dashboard, chat box. Non-technical stakeholders ask plain-English questions and get cited answers. Zero technical setup.

  • Admin console

    One-time project setup. Create the project, install the GitHub and Slack apps, invite team and client by email, configure filters. Fifteen minutes per engagement, then rarely touched.

Swipe or use arrows to explore all five.
How it works

Four seats. Four surfaces. One truth underneath.

A program lead in Cowork, a sponsor in a browser, an engineer in their IDE, a designer in Figma. Each stays in their native tool. Each gets a cited answer in a voice that fits their seat. The exchanges below are real artifacts from the Sapey engagement, used with permission — on an ASU program, the four seats map cleanly to a Program Lead, an executive Sponsor, an ASU engineer, and an ASU designer. Sunday night, a weekly digest cron fires per project — per-stakeholder briefings, every claim cited, zero status emails to write.

  • CoworkCowork · sapey-docs

    The Program Lead

    Maria

    CoworkTeam surface

    Morning catchup. Figures out what needs her attention first.

    • Session-start digest

      Since Friday: Chetan shipped the overnight schema migration (PR #42 merged Saturday 3:12 AM). Chetan proposed DEC-021 — bump retrieval recall at the cost of ~30 ms latency. Needs your review. Roddy emailed Sunday asking whether May 5 launch is still on track. Not yet responded.

    • what did Roddy say exactly? and draft a reply pushing launch to May 12, honest about the week slip.

    • "Hi Maria, following up — given the scope additions last week, is May 5 still realistic? I’d rather know now than be surprised. — Roddy" Draft reply ready. Frames the May 12 date, attributes 4 days to scope additions and 2 days to the latency investigation, offers to walk him through DEC-020 on a call.

      • email:roddy-apr-14
      • DEC-020
      • risk:embedding-latency
    • and DEC-021 — summarize what changes and what it costs. one paragraph.

    • DEC-021 bumps pgvector ivfflat probes from 10 to 20. Retrieval recall climbs ~8% across the last 1,200 runs. Trade-off: vector p95 rises ~30 ms — the 312 ms average becomes ~340 ms, still above our 200 ms target. Chetan’s rationale: the recall wins matter more for decision-surface queries than the latency hit. Your call to lock or defer — draft comment saved to the decision.

      • DEC-021
      • agent_runs:latency
      • slack:sapey-retrieval-apr-18
  • sdd.betacraft.io/sapey

    The Sponsor

    Roddy

    Browser portalSponsor surface

    Wants a status check before his 10 AM call. Four minutes, done.

    • Dashboard

      Recent activity · 8 commits, 3 decisions locked, 1 new risk. Active decisions · DEC-019 (mutex approach), DEC-020 (May 12 launch), DEC-021 (pgvector tuning, proposed). Open risks · Embedding latency (high, being addressed). Milestones · May 12 launch (revised from May 5).

    • why was launch moved to May 12?

    • Launch moved from May 5 to May 12 for two reasons. First, scope additions last week — the admissibility gate telemetry and the extra migration path — added about four days of engineering. Second, we uncovered a performance issue searching project data (embedding latency above our target), which took two days to investigate. Mayuresh, your account lead at BetaCraft, confirmed this with you by email on Monday.

      • DEC-020
      • email:mayuresh-apr-15
  • sapey-governance-substrate
    webhook.ts

    The Engineer

    Chetan

    IDE + CoworkEngineering surface

    Stays in the IDE. Pulls strategic context on demand.

    • /sdd-ask what did Mayuresh decide yesterday about the admissibility gate approach?

    • Mayuresh locked DEC-019 yesterday (Apr 16, 15:32 UTC). He chose the mutex approach over the transactional-isolation approach you proposed. Rationale: simpler to reason about, no risk of deadlock under high concurrency. One concern flagged for you — the mutex timeout needs to be >10s or the load test will flake.

      • DEC-019
      • slack:sapey-arch-apr-16
    • show me the current latency data.

    • Vector queries averaging 312ms over the last 24h, threshold is 200ms. ivfflat probes currently at 10. Suggested next step: try probes=20 (Chetan’s proposal DEC-021). Full dataset in agent_runs.latency_p95.

      • agent_runs:latency
      • DEC-021
    • /sdd-ask where is the mutex timeout set and what does the load test currently assert?

    • Mutex timeout is set in webhook.ts:142 to 8 s — under the >10 s threshold Mayuresh flagged on DEC-019. Load test in tests/webhook/concurrency.load.ts asserts completion within 15 s per batch but has no explicit timeout assertion. Suggested: bump the timeout to 12 s and add expect(mutexAcquireMs).toBeLessThan(10_000) in the load suite so the regression catches any future drift.

      • webhook.ts:142
      • DEC-019
      • tests/webhook/concurrency.load.ts
  • Figmaacme-design-system-v4 · Cowork sidecar

    The Designer

    Luis

    Figma + CoworkDesign surface

    Stays in Figma. Syncs design decisions to the substrate in one command.

    • /sdd-ingest ~/Downloads/acme-design-system-v4.pdf

    • Ingested. Event ID evt_abc123. 62 pages, 847 design tokens extracted, 23 frames identified. Searchable now.

      • evt_abc123
    • what decisions conflict between v4 and v3?

    • Three differences. (1) Primary button #3B82F6 → #2563EB — no rationale in doc, flag for decision. (2) Grid base 8pt → 4pt — aligns with DEC-024 from the dev team Apr 14. (3) Dark-mode support removed — no rationale in doc.

      • pdf:v3
      • pdf:v4
      • DEC-024
    • which components still ship the old #3B82F6 on main?

    • 11 components still reference #3B82F6 on main: Button/Primary, Tabs/Active, Link/Default, Badge/Info, and 7 chart variants under /charts. All route through tokens.ts:primary — one token swap updates all 11. PR scaffold ready as pr:#45 when you lock the v4 decision.

      • tokens.ts:primary
      • pr:#45
1 / 4
The substrate

Six sources. One log. Every answer cited.

Every commit, message, and transcript lands in one append-only log. Agents read from it, cite it, and answer every stakeholder’s question from the same truth. Below: sample artifacts flowing through the pipeline in real time.

commit abc123 → loggedzoom/apr-14 · 127 utterances@roger approved scope47 events normalizeddecision extracted ✓3 risks flaggeddigest ready for @natekimberly asked 'status?'

Built for your compliance posture

  • FERPA-aware defaults
  • Encryption at rest and in transit
  • Row-level security in Postgres
  • Audit-log retention · 7 years
  • Continuous compliance monitoring
  • Your tenant · your compliance posture

Incident recovery

Incident recovery is designed in, not bolted on. Every extraction runs through verifier agents first — deterministic checks (schema, uniqueness, citation integrity, numeric consistency) plus a non-deterministic LLM reviewer for semantic soundness — so most misfires never reach a projection. If one still slips through, every derived entity (decisions, risks, tasks, concepts) is a typed projection over the append-only event log — we truncate the projection, fix the agent functioning or the verifier, and re-run. Source-of-truth events stay intact and the entire state rebuilds from them. No lost history, no manual fix-up, no silent drift.
Running on SDD today

Three programs. Three stakeholder shapes. One substrate.

Every card below is a live engagement running on the same SDD substrate ASU would get — same event log, same plugin, same agent roster pattern. Named clients and artifact walkthroughs available on the Zoom.

  • Georgetown University · Center on Education and the Workforce

    Higher education · labor-market data

    Active · 4-month contract

    Credential-to-jobs data viz for Georgetown University.

    Georgetown University’s Center on Education and the Workforce — building public-facing data viz that maps educational credentials to labor-market outcomes across 55 U.S. metros. SDD runs the full program: a seven-agent roster with named owners, 34 decisions logged to-date, weekly digests to the client-side program lead replacing status email entirely.

    Named agents
    7
    Decisions logged
    34
    Stakeholder surfaces
    3

    Agent roster

    • pm-logger
    • feedback-digest
    • tech-lead
    • frontend-dev
    • dataviz-dev
    • qa-engineer
    • code-reviewer

    Why this matters for ASU

    Closest structural analog to ASU — higher-ed, public data product, multi-reviewer verification, weekly cited digest to the program sponsor.

  • Sapey · compliance governance product

    Residential care · multi-state compliance

    23 days · Phase 2.1 shipped

    From kickoff to stakeholder demo in three weeks on SDD.

    Roddy Radnia’s governance-and-compliance product for California residential care facilities. SDD ran the build from day one — PM, UI, and UX agents scoped per-scene, 30 decisions logged with rationale, session logs per contributor, zero status emails. The Zoom demo walks the live dashboard end-to-end.

    Days to first demo
    23
    Decisions logged
    30
    Agent roster
    3

    Agent roster

    • pm-agent
    • ui-agent
    • ux-agent

    Why this matters for ASU

    Proves the fast-ramp case — a governance product stood up on SDD in weeks, not quarters. Same loop we would run for a single ASU initiative.

  • Step Up Tutoring platform

    Education nonprofit · tutor-student matching

    ~3 weeks · 5-phase build

    Twelve epics, twenty-three agent specs, one reviewer chain.

    National tutoring nonprofit rebuilding its tutor-matching and student-data platform on SDD. Twelve epic specs, twenty-three agent specifications — builder, verifier, test, code-review — 78 chunked work units, five delivery phases. The reviewer chain (independent critic agents + a decision agent) gates every state-mutating output before it reaches the source of truth.

    Epic specs
    12
    Agent specs
    23
    Work chunks
    78

    Agent roster

    • builder
    • verifier
    • test
    • code-review
    • decision

    Why this matters for ASU

    Shows the methodology scales — epic-level planning plus multi-reviewer verification holding up across a full product build.
The engineering philosophy

AI-native engineering, with guardrails.

SDD is the methodology. This is the engineering philosophy every BetaCraft engineer runs on — codified, measured, and published in our internal handbook. Every ASU-bound engagement inherits it from day one.

“We don't just use AI to code faster — we use it to code better. Our systems make velocity repeatable, measurable, and improvable.”
BetaCraft Engineering Team · AI Engineering Principles

  • Guardrails, not guesswork

    Context files

    A powerful AI without process is a race car without a steering wheel. We build digital guardrails — codified context files covering architectural standards, API design, code quality, UI patterns, and security — that every AI interaction is constrained to before it writes a single line. Rules are enforced more rigorously and automatically than humans ever could alone.

  • Closed-loop validation

    50–60% productivity-gain target

    Design, code, test, and review are one continuous AI-augmented loop. Test agents generate RSpec and Playwright suites automatically from user stories. Gemini Assist runs first-pass code reviews against our guardrails inside CI/CD, catching style violations, security gaps, and coverage holes. Human tech leads focus exclusively on business logic and architectural intent. Every engagement is benchmarked against a 50–60% productivity-gain target, measured sprint-by-sprint and reported monthly — methodology and raw numbers shared with the client, not just the headline.

  • Multi-reviewer verification

    3 critics per output

    Every state-mutating agent output faces independent critics before it reaches the source of truth — two reviewer agents with different prompts and different base models, plus a decision agent that consolidates. A confidently-wrong claim has to survive all three. Every verdict is logged, re-runnable, and cost-bounded.

  • Ops as a quiet agent cluster

    Human-owned · AI-assisted

    Provisioning, deploys, schema migrations, observability, and compliance posture run as a cluster of specialized agents — each scoped to one job, each gated by a named human owner. Most stakeholders never need to see them; that is the point. Compliance evidence (SOC2, HIPAA, FERPA controls) accrues continuously through Vanta-style automation rather than scrambling for the next audit. Ship velocity and audit posture stop trading off.

  • The L2 AI-enabled engineer

    Up to 100% productivity gain

    We have moved past the Junior / Mid / Senior ladder. Every BetaCraft engineer is trained to the L2 standard: a classical expert who masters AI tools to orchestrate agents at a sustainable velocity no traditional L1 or no-code L3 builder can match. Soloist becomes conductor. Progression is formal — 10–15% gain at autocomplete, 25% at function drafting, 40% at file-level refactoring, up to 100% at multi-file agentic workflows.

Swipe or use arrows to explore all four.
What we stand for

Three principles we do not compromise on

  • Transparency & observability

    Every answer is cited back to the source events that produced it — a provenance chain from claim to message to author. Every agent run is observable: trigger, inputs, outputs, tokens, cost, duration, logged to the agent_runs table and replayable on demand. The build log for this page is public. If we do not know something we flag a TBD — honest by default, no stretched numbers, no silent failures.

  • Interoperability & composability

    Native tools stay native. GitHub stays GitHub, Slack stays Slack, Gmail stays Gmail. SDD unifies the substrate underneath through connectors and open standards — SQL for state, git for docs, markdown for specs, pgvector for retrieval. Agents are narrow, sessions are bounded, decisions are logged. Every derived entity is regenerable from the event log. Small reversible moves over big-bang rewrites.

  • Portability & sovereignty

    The repo is yours on day one. The Postgres instance runs in your tenant under your compliance controls. Agent specs, event schema, and migration history live in the repo you own. BetaCraft builds, hosts, and operates SDD on your behalf — monthly methodology review, quarterly model upgrades. If you bring it in-house, exit in 60 to 90 days with parallel operation and training. Zero lock-in, no exit penalties.
What you walk away with

At the end of the pilot, ASU owns this.

Four to six weeks after kickoff, here is the concrete package you keep — whether you renew with BetaCraft or bring it in-house.

The first 30 days, week by week

Every week has a concrete result a sponsor can show. No dark matter between kickoff and the board deck.

  • Week 11 of 4

    Kickoff + connector setup

    We scope one ASU initiative with you, stand up the SDD instance in your Azure or AWS tenant, and wire Slack, GitHub, Gmail, Zoom, Figma, and Docs through Nango. No credentials on any ASU laptop.

  • Week 22 of 4

    First digest lands

    The event log starts ingesting. Sunday 10 PM the weekly-digest cron fires — per-stakeholder briefings land in inboxes with every claim cited. First signal that the status-update email is now obsolete.

  • Week 33 of 4

    First full session loop

    Team members open the project folder in Cowork, read the catchup, work, close the session. The plugin commits with name prefixes, pushes, and notifies the backend. Decisions and risks start accumulating in the typed entity tables.

  • Week 44 of 4

    Review + adjust

    We look at what the substrate caught and what it missed. Agent prompts get tuned, the event taxonomy gets adjusted if needed, and we ship a first-pass walkthrough deck ready for a board or sponsor committee.

1 / 4

  • A live SDD instance on ASU cloud

    Event log, Postgres index, pgvector, agent runs table — running in your Azure or AWS tenant under your compliance controls. Yours to inspect, audit, and extend.

  • One ASU program governed end-to-end

    One initiative — across Slack, GitHub, Gmail, Zoom, Figma, and Docs — indexed and queryable. Every decision, risk, and task on the program is cited back to source events.

  • Board-ready walkthrough deck

    A deck that shows the Substrate, the stakeholder surfaces, the agent roster, the governance controls — annotated with screenshots from your live program. Ready to present to a sponsor, CIO, or board committee.

  • A hand-off path, on paper

    Written runbook for operating the instance: event taxonomy, agent spec templates, migration process, incident rollback. If you bring it in-house, we train your team over 60 to 90 days with parallel operation.

Read the proof

Every decision made while building this page, logged in real time.

One human. Eleven specialized agents. Seventeen logged sessions over ~62 hours wall-clock, from intake to ship. Three reviewer gates, one tech-lead sign-off, session-by-session. If anything on this page sounds like marketing, the build log is where you verify it.

  • 11specialized agents
  • 17sessions logged
  • ~62 hrs1 human · idea → shipped
Read the build log

Public URL. No login, no gate. Updated on every ship by build-log-agent.

This page was built in one Cowork session using Stakeholder-Driven Development — eleven agents, three reviewer-and-decision gates, every state-mutating output signed off by a human tech lead.

See the build log