# Fragmentation to framework: Spec-first development at Benchling

DevFeed: [Fragmentation to framework: Spec-first development at Benchling](<https://devfeed.tech/articles/fragmentation-to-framework-spec-first-development-at-benchling-20126.md>)

Original publisher: [Read original article](<https://benchling.engineering/fragmentation-to-framework-spec-first-development-at-benchling-9b97302bddcf?source=rss----3d4aa8fb07ea---4>)

Author: Eli Levine

Published: 2026-02-19T17:29:16Z

Content type: article

Language: en

Sources: [Benchling](<https://devfeed.tech/sources/benchling.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Framework](<https://devfeed.tech/topics/framework.md>), [data](<https://devfeed.tech/topics/data.md>), [API](<https://devfeed.tech/topics/api.md>), [Tech Debt](<https://devfeed.tech/topics/tech-debt.md>), [interoperability](<https://devfeed.tech/topics/interoperability.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [migration](<https://devfeed.tech/topics/migration.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [benchling](<https://devfeed.tech/tags/benchling.md>), [biotechnology](<https://devfeed.tech/tags/biotechnology.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [data](<https://devfeed.tech/tags/data.md>), [development](<https://devfeed.tech/tags/development.md>), [framework](<https://devfeed.tech/tags/framework.md>), [interoperability](<https://devfeed.tech/tags/interoperability.md>), [migration](<https://devfeed.tech/tags/migration.md>), [platform-engineering](<https://devfeed.tech/tags/platform-engineering.md>), [tech-debt](<https://devfeed.tech/tags/tech-debt.md>)

## AI overview

Benchling describes how manually integrating scientific data objects with APIs, analytics, search, configuration migration, and other platform capabilities created an MxN maintenance burden, technical debt, and behavioral drift. The article introduces a spec-first framework approach intended to make platform functionality more uniform and scalable.

## Source excerpt

Reaching the limit of manual platform development Benchling's platform handles diverse scientific data, such as DNA sequences, antibodies, notebook entries, inventory containers, workflow runs, and dozens more. Each object type carries unique domain logic: how it is validated, what relationships it holds, and what actions users can perform on it. As Benchling matured, capabilities were added that customers expected to work across all these objects including REST APIs for integration, a data warehouse for analytics, search indexing, and configuration migration tools for moving setups between tenants, among many others. Each product team is expected to expose their data in all platform surface areas. However, because this process is manual it can also be brittle and costly. With M object types and N platform capabilities, and each object requires custom integration with each capability, you're maintaining MxN integration points. Add a new object? You'll need to integrate it with every platform capability. Add a new capability? You'll need to integrate it with every object. In practice, this meant product and tech debt: some objects were available via API but missing from the warehouse, or a feature was exposed in the UI but not in other platform surface areas. It also meant behavioral drift. The same object would have slightly different field names or validation logic depending on which surface you accessed it through. As Benchling grew, so did its customers. Enterprise customers expect platforms that are designed for multi-modal integration that covers the full spectrum of Benchling's data and functionality. AI is quickly reshaping how knowledge work is done across all industries. But some fundamentals have not shifted. The same integration capabilities that make enterprise architectures more powerful are what makes agents more powerful too: both require data access and interoperability. Thus a different approach was needed. Ideally one where the cost of adding types