Mimulus
Planning Mimulus’s first DNA-storage service
Co-founder & Fractional CTO · 2025–2026
A film or music master may need to be kept for decades and retrieved only occasionally. I explored these archives as early uses for Mimulus, then worked with the team to decide what a first DNA-storage service actually needed to do—and what we should leave for later.
I defined requirements across the storage card, reader, and software, developed our multi-file addressing approach, and organized the outside supplier work. Because a customer’s long-term storage costs, our engineering effort, and the company’s fundraising plan all had to agree, I built the financial and operating plans right alongside the technical architecture.
Enlarge imageEnlarge: Concept imagery on the 2026 Mimulus website introducing the proposed DNA-storage service.Designing around an archive’s needs
In our first planned commercial card, copying a file back out would consume a small fraction of the DNA stored in that well—making archives opened only occasionally a much better fit than frequently accessed files. I spoke with archivists and enterprise IT advisers about how long they kept material, how often they pulled files back, what retrieval turnaround they could live with, and what they could afford.
Our initial service model kept the reading equipment and laboratory handling at Mimulus so customers could upload and retrieve files without buying hardware or running a wet lab. Outside partners would fabricate the cards and build reader hardware, while Mimulus owned the system architecture, software, and integration IP.
I separated the card’s development stages from the reader’s so the team had clear targets for each. When an early pilot proposal included reading files on a customer’s own premises, I pushed to keep that capability in a later generation—since on-site readers and surface-anchored cards that could be read repeatedly required harder hardware and chemistry work.
Putting the development work into the plan
Working with another member of the team, I sequenced the roadmap to prove value before building custom automation: start with a manual beta proof of concept storing and recovering data with standard lab steps, follow with a first multi-well card supporting individual file retrieval, and advance to a later card built for repeated reads while developing reader prototypes and software in parallel.
Starting from an inherited financial template that had zero cost of goods, I built our quarterly operating and unit-cost model around the real engineering work—outside hardware development, DNA synthesis, staffing, and realistic time to launch. When an early schedule assumed commercial sales right after funding closed, I reset the launch timeline around how long the card and surface-chemistry engineering would actually take. Once the team signed off on that financial model as our master record, I reconciled our development plan, hiring plan, and investor materials so every document told the same story.
When fundraising timing grew uncertain, I built a 10-month reduced-budget fallback plan that kept critical card, reader-breadboard, surface-chemistry, and encoding-software milestones moving for roughly a tenth of the funded budget while deferring full-time hires and a dedicated facility—and flagged an unfunded technical project-management role we would still need to integrate our suppliers’ work.
Early on, I also scoped a long-term concept for a self-contained data-center appliance combining DNA writing, storage, and reading—simplifying it around replaceable reagent cartridges and backward compatibility with our cards to keep the engineering credible before tabling it altogether so our budget and attention stayed on the nearer-term managed service.
Enlarge imageEnlarge: Three-Stage DNA-Storage Hardware RoadmapTurning the plan into work suppliers could deliver
The storage card, synthetic DNA, and reader all had to fit one another. With teammates working on the molecular biology, I evaluated competing DNA-synthesis technologies by what our service actually needed—how many unique sequences a chip could make at once, whether each spot yielded enough usable DNA to work with, and the cost per strand—showing why high spot density alone didn’t help if individual wells came up short on material.
Because dedicating an entire tiny storage well on a card to one small file would ruin the unit economics, I developed a multi-file addressing approach that let many files share a single well while still copying back only the requested file. I drafted and filed Mimulus’s first provisional patent application around the storage architecture and laid out a layered IP strategy separating our system-integration inventions from our partners’ chemistry and fabrication know-how.
For the beta cards, I split dry card manufacturing—where our microfluidics partner handled lamination design, fabrication, and well-recovery testing—from DNA loading, gating fabrication payments on design sign-off and tying later milestones to DNA receipt and loading.
Managing partners also meant owning bottlenecks on our side of the table. I shipped DNA test plates, flagged candidly when our own unconfirmed synthesis handoff spec had held up the partner’s loading test across three meetings, and caught where the partner’s proposed beta card storage workflow had drifted from our development plan before more investor materials went out. Our partners ran the physical bench work; I owned the requirements and interfaces needed to bring their work into one coherent system.
Enlarge imageEnlarge physical Glacier Data Storage Card prototype in its protective sleeveExploring the long-term cost of an archive
Tape and hard drives look cheap on day one, while five-year hardware replacements, data migrations, power, and administration quietly compound over decades. Working with scientific and commercial colleagues, I built our long-horizon cost analysis to test pricing against that multi-decade ownership cost rather than simply marking up our own production cost.
When I audited earlier internal spreadsheets that only worked at a single fixed archive size, I rebuilt the comparison on a normalized per-terabyte basis so it scaled cleanly across archive sizes—scrutinizing annual read charges, redundancy levels, and the gap between initial launch pricing and long-term target pricing. Keeping that distinction clear mattered: a compelling long-run cost curve didn’t by itself prove what a first commercial customer would pay at launch.
To help archive owners feel that multi-decade dynamic in two minutes, I turned the normalized cost engine into an interactive visual story built for entertainment and enterprise executives rather than spreadsheet analysts. Visitors can adjust archive size and retention horizon to watch hardware refreshes, migrations, power, and administration accumulate. The historical screen below reflects long-run target pricing assumptions to illustrate the economic thesis rather than predicting measured customer savings.
What the model compares
Initial storage, replacement hardware, migrations, power, maintenance, and staffing accumulate across the chosen period. The tool changes archive size and time horizon; its result also depends on the underlying cost and retrieval assumptions.
Historical screen · 2026
View original model screenEnlarge original 2026 cost-model screen — hypothetical 100 TB, 30-year scenarioExperience used here
Product strategy · Storage economics · Financial modeling · Development planning · Engineering coordination · Intellectual-property development