When Bastionchip delivered its first engineering samples to design partners in Q1 2025, we made a deliberate choice that confused some people who've watched other semiconductor startups: we accepted three design partners, not thirty. We turned down teams with clear technical credibility and real deployment use cases. That decision shaped everything about how our first tape-out went, and I want to explain the reasoning — not as a template for every hardware startup, but as a description of what actually works when the silicon is pre-production and the integration surface is genuinely novel.
Why Breadth Feels Right and Usually Isn't
The intuition behind a wide early-access program is defensible. More integration partners means more usage patterns, more bug reports, more market signal. For a software product, this logic is nearly always correct — the marginal cost of an additional user is close to zero, and the feedback volume is worth the support overhead.
Hardware integration is different in two ways that break this logic. First, the feedback latency is high. A design partner who hits an integration problem at the PCIe driver level needs days of debugging to characterize the issue, not hours. If you have twenty design partners hitting the same class of problem simultaneously, you're not collecting twenty data points — you're spending twenty times the engineering bandwidth on triage for what is probably one or two root causes. Second, the integration surface of a hardware device is deep. A partner who superficially integrates — calls three SDK functions, does TLS offload, moves on — will not discover the problems in key handle lifetime management, session pool behavior under load, or attestation refresh timing. Those problems only surface when someone builds a production deployment on top of the chip.
Three deeply engaged partners give us more actionable data than twenty shallow integrations. This is not a hypothesis — our design partners filed 34 distinct integration bugs during the first three months, essentially all of which required significant engineering engagement to reproduce and root-cause. We could not have handled that velocity with a larger cohort.
What "Deep Integration" Actually Means
A deep design partnership at the pre-production silicon stage has specific characteristics that distinguish it from a standard beta program:
- Dedicated engineering contact: Each design partner has a named Bastionchip engineer as a primary technical contact, not a support queue. Issues go to a person with context on the partner's specific deployment architecture.
- Architecture review before integration: Before the partner writes a line of integration code, we sit with their platform security team to understand the full deployment stack — what's running on the host, how the confidential VM is configured, what key lifecycle requirements their compliance posture demands. This pre-work surfaces integration assumptions that would otherwise become bugs.
- Production-representative workloads: The partner runs actual production-representative traffic against the chip, not a synthetic benchmark. The distinction matters enormously. Synthetic benchmarks don't produce the session management patterns, the concurrent connection profiles, or the key rotation schedules that reveal real behavioral edge cases.
- Bidirectional design input: Design partners can request feature changes or API modifications. Two of our three partners requested changes that were incorporated into the SDK before general availability. That only works when there's trust built over months of close collaboration — it doesn't happen in a shallow early-access program.
What We Learned That We Wouldn't Have Otherwise
Three specific lessons from the design partner program that changed the product in meaningful ways.
Session pool defaults were wrong. Our initial SDK defaulted to 16 concurrent PKCS#11 sessions. One partner's load test immediately hit this limit at modest TLS connection counts — around 200 concurrent handshakes on a single service instance. We raised the default to 64 and added monitoring hooks. A shallow integration would have reported "performance degrades under load" and left it there. The deep partnership allowed us to trace the exact failure mode within hours.
Attestation certificate lifetime needed to be configurable. We had hardcoded a 90-day attestation certificate refresh cycle. One partner's security policy required attestation refresh every 30 days. Another's key management system expected certificates to be valid for at least 180 days. The right answer is a configurable lifetime with a reasonable default — something we wouldn't have discovered without facing real operational policies from real security teams.
The PCIe reset behavior on kernel panic was a showstopper. If the host kernel panics and recovers (or the VM is migrated), the PCIe device state needs to be cleanly re-established. Our initial firmware did not handle this case — after a recovery event, the chip required a full hardware reset rather than a driver reconnect. A production deployment cannot tolerate requiring physical intervention after a VM migration or kernel crash. This was a silicon-level bug that required a firmware update to fix, and we found it because our design partner ran production workloads with real failure scenarios rather than a stable test environment.
The design partner program isn't about collecting testimonials or logos for a website. It's about building the product correctly. Every integration bug we found in Q1 2025 was a bug that would have reached production customers in a wider release.
Selection Criteria for Design Partners
We evaluated potential design partners on four criteria, roughly in order of weight:
- Integration depth commitment: Does the partner have a dedicated engineer who will work the integration full-time for at least two months? A part-time engagement from a team that also has other priorities produces shallow feedback.
- Representative deployment scenario: Is the partner's use case genuinely representative of a production confidential compute workload? We prioritized partners running real key management infrastructure over teams running toy examples.
- Technical feedback quality: Can the partner's engineers characterize bugs at the level of "here's the SDK call sequence, here's the expected behavior, here's the actual behavior, here's the host system configuration"? Vague reports of "it doesn't work" are not actionable at the pre-production stage.
- Timeline alignment: A partner who needs production-ready silicon in six months will be unhappy with pre-production samples that require frequent SDK updates. We looked for partners who understood the timeline and had organizational tolerance for the iteration pace of early-stage silicon.
For teams evaluating a design partnership with any early-stage hardware vendor: the questions to ask are about their engineering bandwidth for support, their process for incorporating feedback into the product, and their experience doing pre-production integrations. A vendor who treats the design partner program as a marketing exercise rather than an engineering exercise will not be a useful partner regardless of how good the silicon specification looks on paper.
