There's been quite a few efforts in this. See Transcriptic and Emerald Therapeutics (http://www.emeraldcloudlab.com/), while there's the more traditional suppliers for things like short oligos or expression vectors (https://www.dna20.com/ and http://www.idt.com/).

I think there's also been a lot of independent academic attempts at this (see: http://klavinslab.org/ which is CS/BioE at UWash), but all kind of waded around in the shallow water.

The reason why I think this is compelling because I think almost every synthetic biologist has an existing workflow. It's basically design using some sort of CAD software, order from IDT, receive materials next day, run test by hand, ship to Genewiz for sequencing, etc. That's just one example of a workflow involving 4-5 specialized 'steps'. As the steps get cheaper/faster/better, consolidating and automating this is just a no brainer.

Emerald doesn't really exist yet, and I believe they misrepresent their automation. They've posted a very pretty site with a bunch of mockups. They have a set of workflows that work for their internal antiviral research, but "Heroku for Science" is a completely different game.

Transcriptic, on the other hand, started taking orders six months ago and has customers at Stanford, Caltech, Harvard, and more.

There are probably others much more familiar with cloud infrastructure who can chime in, but the AWS of science and the Heroku of science are two very different challenges, and I feel the analogies probably cross over pretty well.

Definitely having the infrastructure 'warehouse' layer that Transcriptic is building (with a real API! wow!) will be valuable. And like you hint at, power users won't need hand-holding, but 99% of the market of users will. That's where packaging, ease of use, and limited configuration seem to be the difference maker (Heroku starting exclusively with Rails).

I'm a biomedical engineering graduate student at a research university. While I haven't investigated Transcriptic's pricing in depth, based on a conversation with one of their employees about collecting some basic growth curves (https://www.transcriptic.com/guides/3-growth-curves.html), their prices were simply far too high (even with the steep discount they offered) for repetitively collecting a large amount of data - precisely the situation in which you'd want to use something like Transcriptic. This is especially true for labs (such as mine) that have already made the upfront capital investment for the equipment used to take these measurements. As for the repetitive labor, you can usually find undergrads to do that for far less (often completely free) than what Transcriptic charges.

However, a service like Transcriptic may make sense if (a) you're in a company (no free undergrad labor, though summer interns may be a suitable alternative) or (b) you don't already have the equipment and just want to do a one-off collection of a large amount of data. Also, maybe prices will significantly drop as Transcriptic scales up and streamlines their operations. I'll definitely be checking back in the coming years to see if they ever reach the point where it makes sense to use their services.

Hey! Founder of Transcriptic here. This is exactly what we are. We're growing quickly and have customers at over a dozen academic institutions now. One of our key issues right now is that biologists aren't programmers and so we're doing a lot of hand-holding - we'd get really excited about someone building higher level tools (Heroku to our AWS) on top of us for specific domains that you know better than we do.

If anyone in this thread thinks this is an interesting topic I'm easy to reach at max@transcriptic.com.

Hi Max, I took a look at your jobs page and my heart sank at this: https://jobs.lever.co/transcriptic/e1cfcb93-05d8-4026-8f70-3...

The first two bullet points there are like the two biggest red flags possible in an ops job post. It reads as a development team that has built a fragile and unreliable system and is looking for a superman to dump it on.

It will matter much more if your VP of Engineering position can capacity plan than it will matter if your operations position can code. No amount of ops rockstars can fight a (larger) dev team that won't design with real world workload capacity and reliability as not just a concern but a focus.

Hey, sorry that it came across that way. The ops position is definitely not about looking for a superman to dump a buggy system on. Issues are root-caused and it's a point of culture that we don't see the same bug twice.

Another Transcriptic just Slacked everyone your comment here which has prompted a discussion about what we're really looking for in an "ops" person. The "exceptional coding skills" bullet is in almost all of our engineering job posting, and we thought such skills would apply to really good "devops" people, too; maybe this is wrong and asking for the wrong skill set. (The SREs I know at Google are all really good developers.)

Being an "on-call position" is a side effect of our volume and the fact that cells don't stop dividing at 8pm. Depending on when projects get started we often end up running reactions all the time, and so yes there is a (metaphorical) pager involved. Even minor failures here are very time sensitive due to the biological nature, and lost samples can be extremely costly (and devastating to our reputation with customers). I think this ops role is more about setting up the processes rather than being the only person (people) to respond to issues.

We'll be reflecting on that job description and update the posting.

Cool thanks for taking the feedback. And careful with the "because google" line of reasoning, whats right for them is very often not right for non-drowning-in-cash/monopoly-holders.