Butterfly Labs (Techstars '21, YC accepted) | Software Engineer, All Levels + Operations, All Levels | Remote okay | Butterfly Labs enables telehealth companies to quickly and easily get started with at-home diagnostics. We integrate a complex diverse specialty lab market under a single operational and API interface to offer a replacement for Quest and Labcorp for the home.
We're hiring for operations (sales focused) and engineering at all levels. The founding team are both former Microsoft Engineering with backgrounds building infrastructure and analytics products in Azure.
If you or anyone you know is interested, please reach out directly to hello@butterflylabs.co.
Butterfly Labs (TS21, YC accepted) | Los Angeles | Onsite preferred or Remote | Full Time | https://butterflylabs.co
Tech stack includes Node (Typescript), Postgres
We are looking for our first full-time engineering lead. Butterfly Labs is an end-to-end platform diagnostics company powering the future of personalized medicine. Today we offer an API service
for digital health companies to easily add diagnostics through at-home blood testing. By better understanding how our bodies operate, we gain better insight into our health and wellness.
We power companies who want to do at-home testing (telemedicine providers, digital wellness, CGM companies) to help them better help their patients.
Honestly for us (https://butterflylabs.gitlab.io/api-documentation) we just cold emailed a large number of folks we thought were our target demographic. Basically LinkedIn, look for product managers who are mid-level, and reach out. We got our first two customers from there on our MVP. The thing to keep in mind is if your MVP would solve a real problem, usually folks will be willing to try your solution because it's something they really need. Otherwise your product is just a nice to have and you're probably close to but not quite hitting the right problem spot.
Fair enough. In regards to point number 3, do you believe that sandbox APIs that persist objects like what Stripe does a must-have or a nice-to-have or somewhere in between?
For me it depends on what the API does, and how much testing costs.
If it's something like Stripe (payments), Plaid (collects bank credentials), or Lob (sends physical mail), you definitely need a sandbox beyond the MVP stage. At one point we had a pre-launch payments API at Square and we provided partners with prepaid debit cards to test with, but that approach obviously doesn't scale well.
Another huge benefit of sandbox APIs is that people can use them for CI when testing their own integrations.
Still, when the cost of creating and manipulating objects in the production API is negligible I would say a sandbox is unnecessary.
As for how much persistence is needed in the sandbox, start with what is easiest to implement and gather feedback from your developers.
Be aware that developers often throw out ideas of API features that would be nice to have without much though about priority of effort involved. Sometimes they ask for something and then don't get around to updating their integration to take advantage of it.
ya that's a fair point. Right now we just give canned responses but our API does have real world implications like Lob. Actual test kits get sent out. It's hard to balance essentially duplicating your prod environment for the sake of simulating things vs canned responses which just give you the different responses you'd expect. I guess the big downside is you don't get to test asynchronous changes to objects.
Sure. I'll check it out. I saw a similar product that would output OpenAPI to slate docs actually so that would be what I would lean towards just out of familiarity.
So there is an intuitive aspect that brings comfort? I think that's super important. Especially in healthcare where most APIs/dev experience is terrible, making someone feel at home seems really important.
Not so much “intuitive“, much closer to “familiar”. I don’t expect an API doc tool (or any useful/powerful dev tool) to be zero learning curve, but I don’t want my team climbing 2 or 3 different learning curves unnecessarily.
But yeah, totally right on the “feeling at home” idea.
Do you recommend OpenAPI based docs? I used SlateDocs for mine: https://butterflylabs.gitlab.io/api-documentation because I found that generating OpenAPI with NestJS to be kind of a pain as part of a build process.
We're hiring for operations (sales focused) and engineering at all levels. The founding team are both former Microsoft Engineering with backgrounds building infrastructure and analytics products in Azure.
If you or anyone you know is interested, please reach out directly to hello@butterflylabs.co.