New Developments: Soroush Pour (Vow)

Introduce yourself and your team!

My name is Soroush and I'm the head of engineering here at Vow. Vow is based here in Sydney, Australia, and we are a cultured meat company. We're trying to produce meat without having to raise and kill an animal for a whole host of environmental, culinary, health, and ethical reasons. And specifically for us here at Vow, we're trying to really find the world's best meat. To put it simply, to find the best cells that perform the best as food, whether that's from a culinary perspective or nutritionally. So we're really trying to go out there and create meat that's better and more delicious and more nutritional than anything that's existed before.

How do internal tools help your company grow?

It's actually interesting at Vow – we're not externally, as a product, a software company. We're a food company. So as an engineer here, and as an engineering team, everything is focused on internal innovation. The external product is just food. So we use internal tools to give our food scientists and operations people the tools they need to be able to work as productively as possible.

To put it even a little bit more strongly, our whole focus as an engineering team is to make every single one of our team members the most leveraged they can be. We're talking 10 or 100 or 1000 X more productive than they would be without these tools. So it's a huge focus for engineering.

What kinds of internal tools does your team build and maintain?

We build both hardware and software, so I'll put them into three big buckets and I'll focus on the concrete ones, the ones that exist today, that people are really using.

We in science, especially in cell biology, have a big emphasis on microscope imaging. So we have a big imaging pipeline where we provide hardware and software to make it real easy for people to capture images on a microscope and then process and analyze those things at scale. So that's really important. Another is our liquid handling. So lots and lots of cell biology is moving liquids around, and there's liquid handling robotics, like the Opentrons, and we provide tools and apps around that. So whether that be protocols for these robotics or apps for scientists to interact with them.

And then finally,underlying all of it is data systems, whether it's our inventory, or our cell samples, or going through cleanup in the lab, because lots and lots of tools help us track those things, track those assets, and keep track of what's happening with them. And then we connect them up to systems like business intelligence (dashboards and reporting) to make use of that fodder as well.

So imaging, liquid handling, and and data systems are three big areas of concrete, internal tools that we use on the team.

What does your internal tool stack look like?

Our stack is a little deeper than most because it starts with biology. So we've got cells that we have to really understand, and we work with mammalian cells and so all kinds of animals cells from cow to alpaca, to buffalo, all these different things. And so we've got that cell biology.

Then we have IOT systems – things like the Raspberry PI and Arduinos. And then we've got some logic computers. So we've got knocks and other lab computers here in here in the lab and across the office as well. And then our backend systems are backed by Postgres and TypeScript. That's our core API. We've also got some Python in there as well, especially for things like data science and image processing.

For our frontend, we have some custom React apps. We also have some Retool frontend apps. And we also use some no-code tools beyond, such as Airtable. And that's been a transition from smaller systems that we use for prototyping, transitioning into larger scale systems and Postgres and TypeScript.

What's the most frustrating part of building and maintaining internal tools?

That's a big one. Maybe frustrating is the wrong word, but the most challenging thing for us has been that science is, compared to many other industries, highly under-automated or under-utilized with regards to software, especially custom software in your organizations.

So there's no playbook for us – there's not "here is the amazing Google SRE book." Of course those we can learn from those areas, and there's lots that we apply, but there's no book for "here is a lab, and here's science, and here's cell biology, here is how you automate that." Even as a brand new young organization that would prefer to spend its resources discovering other things on the core our product.

So there's been a lot of learning about how to automate a lab. And then obviously on the fly, actually turning those into the tools and products that we need for success.

When should you build an internal tool vs. buy it?

This is a really hard question. It's a topic that we constantly think about. I think it's probably not even the right question because to me it's more of a question of what layer of abstraction do you work at? Short of you mining your own silicon, you're always working at some level of abstraction that somebody else gave you. Do you work at a product layer?

So let's say for example, you, you pick up Zero for accounting. You're like, I'm an accountant. I'm going to use zero. That's a product made specifically for you. Zero has a bit of customizability, but it's very high level. Then you can go one layer deeper, lower, and use a no-code tool like Airtable. It's still point and click, but I'm building my own workflows. Then even deeper, you can use open source tools or other existing developer tools to build it. So you keep going down and then you go fully custom and no open source, et cetera, et cetera, et cetera.

So that's really what we think about – how deep do we want to go for any particular use case or particular area of our business. And there's a different set of answers for different use cases. The areas where we need the most flexibility and scalability, and also where the use cases are the most well-proven, we look to go lower because that gives us more fit for purpose results. We can scale it better and we can continue to adapt it and integrate it as we need.

For the areas which are really not that core or not that well-proven out, we don't need a lot of scale, just basic operations, maybe for things like financial operations for a small company, we'll happily pick up a Zero, or the areas which we think we're not going to be able to innovate on sooner or quickly enough, like electronic lab notebooks. We're not going to build our electronic lab notebook tool, so we pick up a tool like LabArchives to do that sort of work. So it's more about how deep you go. And we focus on things where we need flexibility and scalability and are core to our business.

How do you measure your success and improve your internal tools?

I'd say it's not so different to maybe compared to a high-value B2B product. We don't have millions of users, we have one. And even if at a bigger scale, it would be thousands, not millions (short of us). So if you compare it to like a B2B business, what do you do?

You go talk to your customers, you do regular account management, you do NPS [surveys], you ask them questions. You look at their usage patterns, like on a case by case basis, because there are few enough of them that you can actually do that. So I think most of those rules apply here.

There are two other differences that are worth calling out.

One is that you have to hold yourself to a higher standard, because external customers take their business away. Your internal customers can't take that business away. So hold yourself to a higher standard. Be willing to be more critical because your users may not walk away or be able to be as critical as they otherwise would be because they're your team members.

The other is that you have higher access. Instead of a once a month NPS survey, you can walk around and ask each and every single one of your users. For example, I have a one on one with our Chief Scientific Officer and one of the questions I ask every single time is "what's the biggest pain point that you have on the science team. What's the biggest thing that's slowing you down in terms of your goals." Etc. So I just use the fact that we have this higher access to its fullest degree because that feedback is incredibly important to us doing our job well.

Vow is hiring!

One last thing to share is that we are hiring for software engineers here at Vow. So people who love food, love to work anywhere in the stack from backend systems all the way through your frontend, and hardware as well – we'd love to hear from you! Vow has got a really amazing engineering team and we're looking to add some incredible high caliber engineers.

So if you're interested, please check out vowfood.com/careers and check out the software engineering role there 🙂