Shop Alto Essentials to add pharmacy products to any prescription delivery!

Your partner in navigating the ins and outs of prescriptions — at no extra cost.

Alto Pharmacy Technician

Alto Pharmacist

It’s official: Alto Pharmacy is a great place to work! We’re honored to join the community of Great Place to Work-Certified™ companies based on team member feedback and a rigorous assessment of our company’s culture and benefits.

Join us in delivering our industry-leading pharmacy care to millions of people across the country. As a member of the team, you’ll play an integral role in improving our customers’ quality of life and redefining what’s possible in pharmacy. 

Be Part of a Great Place to Work — Join Our Team

Hear first-hand from members of the Alto technology teams.

Read the latest Alto blog posts covering healthcare, family health, managing diseases, and other Alto highlights.

Blog | Alto Pharmacy

Justin Moy, Senior Software Engineer at Alto, explains how the engineering team developed a staging environment strategy that could keep up with our growing organization.

Creating Sandboxes: How to Make It Easy for Your Engineering and Product Teams

When we formed our Infrastructure team in 2020, our charter centered on scale, reliability, and the developer experience. Our first priority? Developing a staging environment strategy that could keep up with our growing organization.

Initially, we had a set of command-line tools for staging environments that could be run from an engineer’s workstation. However, this approach required significant manual effort to create and manage an environment which led to inconsistencies like outdated data and lack of full application coverage and integration. The required workstation dependencies and maintenance added to the overhead. These tools were also different from the ones used to create a production environment, causing drift between the two.

To address these issues, we focused on improving our tooling to create consistent and reproducible results for both our staging and production environments. Here are the five steps we took to get there:

Luckily, we were already here. Our deployment process involved creating and deploying Docker containers and using a Procfile to run specific parts of our applications (think separating out web and workers). Packaging our applications as immutable Docker images allowed us to ship consistent and portable code. These images are run as containers which can be executed on separate hosts and scaled independently of each other.

We wanted to increase our observability, mature our internal monitoring, and maintain our infrastructure in a more consistent and reproducible manner. Kubernetes, and its automated container orchestration (deployment, scaling, and management), allowed us to accomplish all of the above goals.

It was easy for us to get started in Kubernetes thanks to Kind, which allowed us to run clusters locally. This increased development speed and reduced the friction of learning a new external provider.

Helm makes it easy to manage packaged applications in Kubernetes. Some community-provided applications include: NGINX for load balancing and reverse proxying HTTP and other traffic; Prometheus and Cortex for metrics, monitoring, alerting, and dashboarding, Loki for logs; and Sentry for exceptions.

In order to ease the integration with other infrastructure components, enable rapid deployment, and, most importantly, provide us with the consistency and reproducibility we wanted, we created and deployed Helm charts for our applications.

From here, we could stamp out our applications for developer use in sandbox environments: complete end-to-end environments, separate from production, that enable engineers to rapidly develop and test their code. And if an engineer is working on multiple features, they can spin up multiple sandbox environments and manage their applications and data independently of each other. Victory!

We had already created pipelines in Concourse to automatically deploy and upgrade our infrastructure Helm charts. To eliminate the manual toil of spinning up new environments and to reduce the friction around sandbox adoption for our engineers, we extended these automated pipelines by building a Git-driven continuous deployment pipeline. When an engineer created a commit to a repo defining the state of a sandbox, our Concourse job would apply these changes.

At this point, we could deploy environments that resembled production but were separate from production and other sandbox environments. They connected to the rest of our observability stack, including metrics, logs, traces, and exceptions.

As we prepared to scale to the rest of the product and engineering organization, we focused on the following ideas: further reducing manual toil, removing barriers to entry, reducing cost, and optimizing the development workflow. The diagram below shows our sandbox architecture.

In Kubernetes, an operator acts on custom resources in order to automate a task or set of tasks. The custom resource allows us to create a well-defined entity and extend configurability options to users. The operator allows us to customize individual sandbox environments based on changes to the custom resource.

We utilized Kubebuilder to create our operator and CRD (custom resource definition). Kubebuilder was a great starting point and provides tools to ease rapid development of a new operator.

Using this pattern, we could easily perform CRUD operations (create, read, update, delete) on a custom resource using standard tools like kubectl, and the operator would handle updating our deployments in Kubernetes. These updates could include: updates to application configuration, deploying a new Docker container, injecting different secrets, etc. This flexibility allows for testing of many different scenarios like: developing a new feature, reproducing a bug, upgrading frameworks, and security and load testing.

Increase adoption by removing barriers to entry (admin web UI)

We built a web UI so users would be able to deploy sandboxes intuitively and easily without extensive knowledge of the underlying tools. The web UI interacts with our custom resource and lets the operator handle updates. It allows our teammates—both engineers and non-engineers—to easily spin up their own environments for development, demo, or training purposes without modifying production data.

In addition, we show helpful information about a sandbox to a user. This includes links to each of our applications; pre-filtered logs, metrics, tracing, and exceptions; and commands to connect to specific applications to ease debugging.

Because the sandbox environments are integrated with our monitoring stack, we have the full metrics and logging that we expect from our applications. We created an autoscaler service that performs queries against this information and scales our sandbox environments up and down. We’re able to decrease our costs by over 90% when these environments are not in use and are able to quickly scale them back up when they are being used.

Optimize the development workflow (image updater)

An additional feature we built into our sandbox environment is the ability to follow a feature branch in our applications. When an engineer pushes a commit to a pull request in Github, a corresponding sandbox will automatically update to this commit. This reduces several manual steps in the development workflow and allows engineers to test their code in near-to real time.

Sandbox environments have made an impact on the engineering organization and beyond.

Engineers can quickly desk check new code in a production-like environment during code reviews.

Shared sandboxes reduce the blast radius of bug bashes.

Non-engineers can spin up sandboxes to demo or provide training on features without impacting production data via the Admin UI. This has proven particularly useful for Product Managers and Designers on the team to be able to play with product features and better understand how they work in order to suggest improvements.

Teams have built use case scenarios into their applications. This allows easy reproducibility of critical paths and functionality.

With these five steps—Containerize, Kubernetes-ize, Helm-ify, Automate, Optimize—we’ve laid the foundation for deploying all of our environments in an automated and consistent manner. In addition to applying many of our learnings to improve our production environment, we successfully built core infrastructure that our engineers, product managers, and designers use each month to test their changes and reduce production downtime.

Interested in learning more about engineering at Alto? Follow us on LinkedIn. 

In this post, we'll share how we identified the problem of failing cypress seeds, what the culprit was, and three ways to make seeding test data more robust.

How to Debug Slow and Failing Cypress Seeds

End-to-end test failing before it even begins? Here’s how we timed, debugged, and sped up our seed data.

At Alto, we use Cypress to test our Rails application end-to-end. As our application grows, so does our end-to-end test suite — along with the seed data it requires. This led us recently to a perplexing problem:  when run in CircleCI, our end-to-end tests would mysteriously time out during the seed step, causing them to fail and block deploys.

Seeds can be painful to debug. They’re typically set up through a single request and, depending on how thorough the tests are, call upon most of the models involved in the application. If a model throws, say, a validation error because of bad seed data, you'll see it in your Cypress logs. If a model hangs, the request often doesn't show up in the logs at all. There's no status code, no error message—all you know is that somewhere, somehow, some process is failing to finish.

In this post, I’ll share how we identified the problem, what the culprit was, and three ways to make seeding test data more robust.

To Identify the Problem, Focus on Your Logs

We started by comparing logs from our failing CircleCI runs with those from local test runs. Turns out, our CircleCI logs in failed runs stopped after a specific log message. 

For example, when our test runs succeeded, the logs looked something like this:

...
LOG: creating model
WARN: foo with id=123 not found
WARN: foo with id=456 not found
WARN: bar with id=789 not found
ERROR: Invalid parameter to function `foobar`
LOG: model created
... rest of logs

But when they failed, they instead looked like this:

. . .
LOG: creating model
WARN: foo with id=123 not found
WARN: foo with id=456 not found
[end of logs]

This let us know where to focus: after the function that looks for foo, but before or during the one that looks for bar. Of course, this only works if you have enough log statements scattered around in the first place. I’d recommend logging the time it takes to create each model in seeds, which has the added benefit of telling you where to start if your seeds are becoming annoyingly slow. 

At the top of our file in db/seeds, we declare the following function to add timings to our CI logs:

@last_time = Time.now
def log_time(label)
    Rails.logger.info("Time [#{label}]: #{(Time.now - @last_time)}")
    @last_time = Time.now
end

We then call the function after each create statement in our seeds:

Product.create!({...params})
log_time(“Product Create”)

This prints logs in the following format:

...log metadata message=Time [Product Create]: 12345
...log metadata message=Time [User Create]: 1102
...log metadata message=Time [Address Create]: 105
...

These logs will help you figure out problematic model create calls, but each model may have a lot going on in its callbacks (before_save, before_commit, after_save, etc). You can follow a similar approach to time those callbacks:

# in the model file
Class Model < ApplicationRecord
	
...

before_save :foo

...

def foo()
   start_time = Time.now
   [ ... things that happen inside the function ]
   Rails.logger.info("Time [foo]: #{(Time.now - start_time)}")
   [ function return statement, if applicable ]
end

It’s important to note that the most time-consuming statements in your seeds often cause the most trouble, but that’s not always the case. If your seeds are hanging due to external API calls, it’s entirely possible for those calls to usually take a short time to complete. If you have hanging tests, I would recommend logging test runs in CircleCI, since you may not be able to find the problem locally. 

Through timing our seeds, we narrowed down our search to five of our most time-intensive models. We were then able to time the individual callbacks within those models. One callback  in particular—containing a call to an external database—raised the most suspicion. It took up most of the time it took to create the model, didn’t return any information needed in our test, and was not mocked or stubbed out. 

Requests to this test database would usually work, however, since we call on it multiple times on every CI run, with concurrent CI runs, these requests would sometimes take a long time to complete, leading to a test timeout. 

In our case, since we were making calls to a hosted database in our tests, we changed our test environment to create and refer to an isolated instance of the database. While this was the best approach for our specific issue, we also explored some other ways of stubbing out API calls and skipping callbacks from your seeds file, which we describe below. Use these approaches with caution, as the more you stub, the less true-to-life your tests will be. 

Ideally, you would have already stubbed out third-party API calls in your code using environment variables. An example approach:	

def do_the_thing()
    if Rails.env.production?
    	[ ...do the thing ]
    else
	[ ...do some fake thing if needed ]
       Rails.logger.info("We theoretically would have done the thing.")
end

However, you can also use Typhoeus to mock third-party api calls in seeds, similar to how you might in a test. Imagine that your Product model makes a call to "https://slack.com/api/foo”. We can then mock that call out as follows:

mock_response = Typhoeus::Response.new({code:’500’, body: {
    “ok”: false,
    “error”: ‘not_authed’
}.to_json})
Typhoeus.stub("https://slack.com/api/foo”).and_return(mock_response)
Product.create!({...params})

Again, I would advise you to stub check for environment variables in your code rather than stub out individual API calls in your seeds and tests. But if for some reason you need to do the latter, it’s possible!

Similarly, you might want to stub out a function you’ve written if it takes a long time to run and doesn’t affect the outcome of your tests. This can’t be stubbed out in the ways we mentioned above since (1) you might need it  for — and hopefully are testing it in  — other tests and (2) it doesn’t have a url. minitest has a tool for this. Imagine you’re trying to stub out some functions from a Photograph model.

require ‘minitest/autorun’

Photograph.stub :fetch_product_photo_url, ‘’ do
   Product.create!({...params})
end

This will return an empty string when Photograph.fetch_product_photo_url is called within the Product model’s callbacks. You can also replace the empty string with anything else you might want the function to return.

Last but not least, it’s possible to skip entire callbacks and validation. I wouldn’t recommend skipping all of them, as that can cause models in your tests to stray very far from how your models actually work, but you may find it useful to skip specific callbacks.

While all the methods that I’ve suggested above are possible and can be useful, remember that stubbing and skipping from your seeds may just be band-aids for issues you have elsewhere. In our case, we could have stubbed out a model function or created an isolated database for testing. While both methods would have been functionally the same, doing the latter allows us to have to worry less about that database in the future—if, for example, we write more functions that depend on it, or update the mocked functions to do more than they currently do. Keeping tests in line with how the product works also keeps it more in line with the actual user experience: if it’s taking a long time to create a model in your seeds, it probably takes a long time for your users, too. 

Since adding timing logs and creating an isolated database to our end-to-end tests, we have a regular source of truth for the efficiency of our models, are able to develop more smoothly with fewer spontaneous test failures, and have more confidence in our ability to quickly pinpoint and resolve seed timeouts in the future. 

Last year, we built a feature to show patients all of their medication pricing options, including when paying cash might be cheaper. Here are two surprising trends we've discovered since.

Two Engineers Crunch the Numbers: When Is It Cheaper to Pay Cash for Your Medication?

Tom Cahill and Ashley Qian, Sr. Software Engineers

In 2019, we launched a streamlined flow in our patient app to handle a surprising scenario: when the out-of-pocket price for a medication is less than the insurance copay.

Since launching our price selection feature last year, we've saved thousands of patients money by bringing this disparity to their attention. On average, patients save 30% off their total copay when their out-of-pocket price for a medication is cheaper than the insurance copay. The average savings per prescription is $23.30. 

While several factors impact how drug pricing works, here are two trends we’ve seen in the data so far.

These Two Therapeutic Classes Are Most Likely to Be Cheaper Out of Pocket

A therapeutic class is a method of categorization that groups medications based on the conditions that they are intended to treat. Here's what we found when we aggregated prescriptions by therapeutic class:

Across the 394,367 prescriptions we examined, roughly 0.5% had lower out-of-pocket costs. Comparing different therapeutic classes, anti-parasitic drugs (example: permethrin) appear most likely to have a cheaper out-of-pocket price by a fairly wide margin at 2.94% of cases. Cardiac/cardiovascular drugs (example: rosuvastatin calcium aka Crestor) and blood medications (example: tranexamic acid) stand out as well with over 1% of cases.

Looking at the results in terms of median percentage savings, a few classes stand out as having a fairly high disparity between prices: anti-histamines, contraceptives, anti-neoplastics and anti-infectives. 

Brand Medications Are Less Likely to Be Cheaper Out of Pocket

You're up on Family Feud, and Steve Harvey asks you to name some differences between brand-name and generic medications. The first thing that probably comes to mind is cost: In general, one expects generic medications to be cheaper than their brand-name alternatives. We might expect brand name medications to incur higher copays and thus a larger opportunity for Alto to provide savings. However, we see a surprising trend in our data:

In fact, only .01% of brand name medications we've delivered since shipping this feature had lower out-of-pocket prices (compared to .6% for generics).

So what gives? The cash price we’re able to offer for a medication is mostly determined by the cost we paid a wholesaler or manufacturer to buy it. The copay set by insurance plans, however, is often impacted by behind-the-scenes negotiations between the drug manufacturer and the pharmacy benefit manager, or PBM. As a result, the cash price isn't always strongly correlated with the insurance copay:

Among a set of equivalent products, the one with the cheapest cash price might not be the one with the lowest insurance copay, and that difference can be significant enough to make it worthwhile to forego using insurance.

As engineers who are tasked from time to time with investigating issues with our billing system, we've experienced our fair share of bewilderment at the surprising outcomes we sometimes see. The complexity of pricing is why we've invested so heavily in making sure both our internal tools and patient-facing applications present users with the information they need to understand their options and make well-informed decisions.

We have countless opportunities to help our patients achieve better health outcomes, save money, and be more informed about their choices when it comes to their medication. There’s a lot of exciting work to do, and if this sounds interesting to you, please reach out to us on LinkedIn. We’d love to hear from you!

Mike McClay has spent the better part of two decades working in Silicon Valley. Here, he chats with software engineer Akash Gupta about the road from Software Engineer to VP, what it’s like to work in digital health, and his best advice to both independent contributors (ICs) and managers. 

Get to Know Alto’s VP of Engineering, Mike McClay

I'd love to first understand a bit about you personally. What do you like to do in your off time? What’s something most people don't know about you?

I grew up in Orange County, which is pretty suburban, so that afforded us a lot of time outdoors as a family. A life goal of mine is to do a solo hike of the John Muir Trail. The route starts in Yosemite Valley and heads south to Mt. Whitney. It’s about 225 miles and typically takes a few weeks to complete.

Currently though, I have a two-year-old and a four-year-old, and we have another baby on the way, so my outdoor activities tend to be much shorter and closer to home. I got into road biking about 10 years ago and transitioned to mountain biking a few years back when my family moved to Marin. Being able to get out onto the local trails a couple times per week is an amazing opportunity to get a great workout in, and unplugging does wonders.

Finally, a ton of family time with my partner and kids. A big reason I decided to join Alto is because it provides a great balance of simultaneously being a high growth startup but it’s also a company that has an eye on culture and achieving work-life balance. At Alto, we're playing to win, and we’ve got a lot of things to get done, but there's a lot of support and representation for people with families with kids. It's nice to be able to work hard towards an incredible mission but also not have to sacrifice too much on the family front; so outside of work, I’m mostly focused on spending quality time with my family getting outdoors, getting to the beach, and things like that.

That's very exciting, having another child on the way. How has COVID-19 impacted your responsibilities of being a VP Engineering and a father?

Life is a lot harder during COVID, though I say that with a fair amount of awareness of the privilege my family and I have. On the home front, we are constantly trying to find that balance of keeping the kids entertained and learning but also doing it in a safe way that protects everyone. My wife and I are pretty fastidious about keeping the house organized and clean but that’s relaxed quite a bit during this time; there’s a lot of resetting of expectations, and I try to do as much as I can to support my wife.

Professionally, probably about half of our engineering team has interviewed and onboarded since the shift to remote work in March, and I’d say we are still iterating and adapting each month to work better in a fully remote environment. It’s been incredible to see our teams adapt to this new style of work, and while it’s not quite the same as our in-person environment was, it’s been really cool to see the team grow and have our organization make a bigger and bigger impact for our patients each month.

I'd love to talk about some of your past experiences. You went to the University of California, Berkeley (Go Bears!), then Expedia, then Uber, and now you're at Alto. What prompted each of those transitions?

Yeah, I’m kind of an outlier in the tech world in that I’ve only worked at 3 companies since graduating undergrad in 2004. I think I’ve been fortunate to find myself at companies that have had no shortage of growth opportunities and that led me to stay for considerable amounts of time at both Expedia and Uber. 

Towards the tail end of my tenure at Expedia, I was managing the engineering team of a start-up that Expedia had acquired, and I knew in my heart that I wanted to move to a much smaller company. I spent a few months talking to a bunch of early stage start-ups but hadn’t found anything that felt right yet.

At the urging of my recruiter, I took a call with a company called Uber, which had seemed way too “big” for what I was looking for in that the engineering team was about forty people. Despite the role feeling different from what I was expecting, I was excited by the mission and the team, so I made the leap. Fast forward six years or so and it was an amazing ride, full of a lot of ups and definitely some learnings, but it was a truly formative experience for me.

Uber ultimately got to a point where I struggled a bit to pinpoint the impact I was making, and things overall at the company just felt slow. I wanted to work on something that was even more mission-driven, and one of my colleagues insisted that I chat with Alto. I was introduced to Jamie (Alto’s CTO). We talked over a number of months and found Alto’s needs and the challenges I was looking to solve aligned in a great way. So that's why I ended up joining.

Each of the companies that you’ve worked at have had large operational components. What are some of the key pieces to creating a strong partnership in a tech-enabled company?

What I would definitely say is that the tooling and the product that we built for ops at Uber was, at the time, world-class; it was just beautiful. Design was a first class citizen in our operational tooling because the workflow of our ops team was so critical to our company’s success. 

This is something that Jamie and I bonded over about Alto; our internal platform (called Wunderbar) powers the functionality that allows us to process our patient’s prescriptions in an efficient and effective way. Getting this right is critical for our patients, and the fact that we put so much time and energy into getting the technology platform right goes a long way to build a great working relationship with our operations team. 

Additionally, I’m passionate in general about operations since it’s often an area of the business that creates strategic advantages over competitors. And what I love about building software with operations is that it can’t be copied easily by competitors since there is no public surface area to observe. I view our task as an engineering team as getting to where we're crushing it as a business because we have nailed supporting operations with our product engineering work.

On that note, would you say Alto is an operations company, a pharmacy, or a tech company?

We aspire to a model of cross-functional leadership, whether it's between Engineering, Product, Ops, Growth, Marketing—whatever it is, the leads of areas and even the team members of each area need to be empowered to achieve the mission that they're setting out to do. If that's to enable, say, the flow of prescriptions coming through our system, maybe you could call that Ops-led, but at the end of the day, multiple functions have to come together to solve the problem. I almost want to call it vision-led.

There’s a time and a place where we need to be creating a faster horse, and there's a time and a place where we need to be thinking one to two years out about what the step up is from the faster horse: bringing the car into the situation, so to speak. Ultimately we need to be thinking on multiple time horizons at the company, and depending on the time and place and the strategy, you might see one function spiking up in terms of what we're rallying around versus another.

The engineering team at Alto has grown from eleven engineers and four managers when you started a year ago to more than fifty-five engineers with nine managers, directors, senior managers, and managers. What would you say has enabled that dramatic growth, and how do you plan on ensuring that that growth is well-managed?

For engineers, there are a lot of choices out there, and a big part of our hiring process is spent not only assessing technical skills, but also looking for signals that candidates align well with our patient-focused mission. From the beginning, we created an interview process that is fair and equitable, and that resonates strongly with our candidates. From there, we set out some really big goals that energized the team to push to make it happen.

I'm really proud that we've grown while maintaining a solid level-mix in terms of junior, mid-level, and senior engineers. Our engineering team is ~25% female, and while we only have single digit percentage points of representation of other underrepresented groups, representation is improving every quarter. Our goal over the next several years is for the team to achieve 50% gender representation and 30% from other underrepresented groups, so that our engineering team is representative of those we ultimately serve: our patients.

In order to make sure this growth is well managed, my philosophy is to hire or grow Engineering Managers well in advance of the acute need. On the manager side—and this was a big learning for everyone at Uber—we’d grow a team of fifteen to twenty engineers under a manager and not really have a great plan in place for how to bring in additional leadership and get the teams down to a right size of ten. When we approached that number, we'd battlefield promote someone and everything just felt strained. So I'm really proud of the fact that even at nearly seventy people now, we have a management team of nine that could actually support one hundred people pretty well. As the team continues to grow we’ll be making sure to stay ahead of the growth on the management side.

On that note, Uber has been reported to have an unhealthy culture. What have you learned from it to engender a more positive, inclusive culture at Alto?

Yeah, I’ve had a lot of reflection on this and a lot of learnings from my time at Uber. First, it’s that as a leadership team, we need to be vigilant about creating a team environment where team members feel they can do their best work. We need to always have great managers leading teams that are right-sized, and we need to have people-focused cultural values that help guide our behaviors and how we interact with one another. 

At Alto, half of our cultural values are focused on skills that foster an environment where folks can do their best work. Yes, we're thinking constantly about impact, but we make sure to hold ourselves to a high interpersonal bar. This type of behavior has also been institutionalized at Alto in our engineering career ladder. Culture amplification is one of the five skills engineers are evaluated against, and I think it’s a very strong signal into what we hold dear and how we want to roll here.

Finally, I’ve put a strong emphasis on making sure that interviews at Alto assess behavioral skills in addition to technical ones. We didn’t do this well at Uber for too many years, and I believe it led to some of the cultural negatives that you’ve likely read about in the news. To me, it’s critical that we hire really talented folks who can work seamlessly with one another. Getting signal on this during our interview process is a big part of growing a healthy engineering organization.

You've gone from being a Software Engineer to Tech Lead, Engineering Manager, Director, and now, VP. What advice would you give someone at each of those stages? What advice do you wish you had back then?

The main piece of advice I’d relay is to make sure that you spend enough time in each role to get solid proficiency. I’ve come across a number of folks in my career who look to move through roles as quickly as possible, and I think that doesn't allow for solid bases of knowledge to be built up. The foundation I built up in my experience as an engineer I believe resonates with engineers; I’m not just a people manager that helps coordinate minutiae. Additionally, a lot of the skill-building in these roles happens as you encounter various real life situations; the only way to accumulate experience is over time. So my advice is to be patient.

I would definitely encourage everyone to work at a company where there are clear career paths for both ICs and managers. You should never feel like you need to move into management to “grow in your career.” One of the first things we put in place after I joined Alto was a career ladder so that folks could reason about how they wanted to grow over time and come up with a growth plan with their managers.

Finally, don’t go too long in a role or at a company where you don’t feel challenged and don’t feel like you are growing. To me, growth and challenge are proxies for job satisfaction. I would say I've achieved it about 80 to 90% of the time in my career. If you're not in a place where you're feeling like you're growing, you should go somewhere else.

What would you say to someone considering working in digital health? What are some challenges and benefits in this space?

It's not so fraught with red tape that you can’t get anything done. There is a process to work through with HIPAA (Health Insurance Portability and Accountability Act) to ensure patient privacy; there is a massive set of opportunities that support all of the activity in the space; and there are seams where startups can begin disrupting entrenched players.

There’s also a massive opportunity to solve hard technical problems while achieving these amazing, mission-driven ends. I think sometimes it seems that those can be separated to where it’s almost mutually exclusive. While we don't yet have the volume nor traffic that you might receive at companies like Uber or Google, there are still meaty technical challenges that haven’t been solved before.

What disruption is good in healthcare and what may not be?

The good disruption comes in places where companies can plug into an existing experience that patients go through to solve a problem and figure out new ways to address that problem. In the pharmacy space, we are disrupting the brick and mortar pharmacy experience that is effectively in the business of selling you Coca-Cola while you wait for your medication. 

Bad disruption would be anything that goes against protecting a patient or their privacy. At Alto the engineering and security teams are tightly coupled so that we can best solve for the needs and privacy of our patients.

You mentioned technical challenges. What would engineers and other technical people get excited about in this space?

We don't yet have our architecture mapped out for scaling 100x on our business over the next couple of years, and it’s been really exciting to start to discuss our technical plans to enable that. At Uber, we went from a monolith to a full micro SOA (Service-Oriented Architecture)—both extremes that had quite a few problems as implemented. At Alto, we aim to find a better middle ground. 

Additionally, we need to think about what the pharmacy experience will look like five to ten years from now and start building some of the pieces that will work us toward that future. Safety and accuracy are incredibly important to us now, but at one hundred times our scale, we’ll need to be constantly innovating our technology so that we can minimize / eliminate errors in our operational process. 

We’re also bringing data silos together that have never been joined before. For example, as many as 50% of prescriptions are not picked up for retail pharmacies. Doctors have no idea which of their patients pick up medications or not. Insurers don't know what happens to patients after they take their medication. We are the interconnect between all of these customers.

As we grow, that data is going to grow inside of our systems. The information and the insights that we can derive from it is going to be incredibly powerful. But we're going to need a ton of awesome data analysis, products that allow us to collect the data while respecting patient privacy, etc. I'm really excited about that.

What are you most proud of from your time at Alto so far, and what are you most excited about in the next year?

What I'm most proud of is the team that's been hired. They are just amazing. Last year, we had a team of eleven engineers with such a large surface area: fulfillment, operations, customer app, customer website, our provider portal, etc. With so much to do across a team of that size, we were constantly making really hard prioritization decisions and were not able to tap into what we saw as our full potential.

Fast forward to today, we're now in a world where we have dedicated teams for surface areas, and we’re solidly parallelizing efforts. Seeing the bandwidth, the throughput that's going to be rolling out each quarter, is really cool. We're going to have orders of magnitude more output each quarter than we did a year ago. That's what I'm most proud of now.

What am I most excited about? There's the business aspect, expansion. We've really only covered six markets and are now looking at covering many, many more lives. The next couple of years are going to be a lot of fun.

Last question. Someone's considering working at Alto: Why should or shouldn't they join?

Alto’s at a stage where things are changing constantly. Folks who like dynamic environments will thrive here, as the work is challenging, and we are trying to solve problems that have not been solved before. Given that Alto operates within a multi-sided network, we have a lot of opportunity to create value, but it also means there are multiple players to think about when building a product. There's a richness to our patient, provider, and insurer base that makes it both challenging and exciting to make sure that we're finding the opportunities that deliver value to broad strokes of folks without leaving others behind.

Finally, engineers should join if they want to be part of a mission-driven company, enjoy working in an inclusive environment and diverse team, and like to be at the intersection of technology and the physical world, whether that's operations, delivery of things to humans, etc. If we succeed,  the way society thinks about health, prescriptions, etc, ten to twenty years from now will look very different because of the work we’re doing here. If that's inspiring to you, and you want to be part of that, you should join.

Interested in joining the team? Reach out to us on LinkedIn.

At Alto, we believe your medications should come to you—at the best price, on time, and with the ongoing support you need.

How Alto Delivers More, at No Additional Cost

At Alto, we believe your medications should come to you—at the best price, on time, and with the ongoing support you need. However, when we explain to people that we can save them money while providing free home delivery and easy access to expert care, we often encounter disbelief. In a world where we usually pay a premium for special care, how can Alto’s services really be free?

Traditional retail pharmacies often build hundreds of storefronts in a single metro area in an effort to lure customers through proximity. We, however, are taking a totally different approach. We’ve redesigned the pharmacy experience by building a single distribution center in each metro area. By reducing our overhead costs, we’re able to hire teams of patient care pharmacists who are always on-call to offer guidance and local couriers who will deliver your medications straight to your doorstep.  

What’s more, because we’re not using our resources to stock and equip a fleet of locations, we can invest in innovations that elevate your prescription experience. We built our own pharmacy software platform that enables our pharmacists and patient advocates to effortlessly perform price investigations and coordinate between doctors and insurance companies. We also developed the Alto app, which puts pharmacy care at your fingertips—from ordering refills to chatting with a pharmacist. 

In a traditional pharmacy setting, pharmacists are often required to fill prescriptions, work the register, answer phones, counsel patients, administer flu shots, and call doctors and insurance companies—all on a strictly timed schedule. We don’t believe that sets pharmacists up to provide the best care. At Alto, pharmacists work in two teams with close collaboration. Our production pharmacists can focus on the important task of medication preparation while our patient care pharmacists get to focus on you. Whether you’re concerned about a side effect or wondering if you should take your medication with a meal, you can talk through any issue with an expert who cares. 

By bringing our pharmacy to you, we’re able to offer you a better experience at no additional cost. From uninterrupted, one-on-one consultations with pharmacists to timely hand-delivery of your medications, we think “above and beyond” is simply what you should expect from your pharmacy. 

Need a Refresher? These Alto Benefits are Completely Free

Have you ever meticulously crafted an online dinner order only to cancel once you saw how all the delivery and service fees added up? We’re never going to put you through that type of frustration. When we say “free delivery,” we mean absolutely, completely, 100% free. There won’t be any additional fees sneaking up on you. Ever.

Send us your prescription and a member of our team will hand-deliver your medication directly to your home or office. Pick a date and delivery window that works for you—most medications are available the very same day—then track your courier as they make their way to your doorstep. 

Opportunities to save money are out there, but they can be confusing to identify. When we set out to revolutionize the pharmacy experience, we knew that we needed to help make these resources more accessible. So, we created our own database of discounts, coupons, and pricing options that we could match against every single prescription. By automating the process, we’re able to exhaust all the options and find you the lowest price—at no extra cost. 

If you currently have a prescription at another pharmacy, we’ll take care of the transfer for you. It’s the least we can do to welcome you into our care. For more on how the free transfer process works (spoiler: it’s incredibly easy), see How Do I Transfer a Prescription to Alto?

One of the most important aspects of pharmacy care is the ability to chat with a pharmacist whenever questions come up. Whether you’re starting a new medication for the first time or unsure if a certain supplement could interfere with your regimen, you can call or message an Alto pharmacist at any time—even evenings and weekends. You’ll never have to wait in line or feel like you’re being rushed along, and your messages will be private and secure. Our patient care pharmacists focus solely on consultations, which means you’ll always have their undivided attention. 

Whether you’re facing a full day of meetings, navigating a complex schedule of pickups and errands, or dealing with an unexpected challenge, it’s easy to let your daily dose fall through the cracks. So we created a few helpful features within the Alto app that can help you stick to your schedule. The Reminders feature lets you set up medication alerts so you’ll never miss your next dose, and you can turn on Auto Refills to get your future refills delivered automatically. We’ll even reach out to remind you when your next fill is on its way so you can make updates to the delivery if needed.

Streamlined Medications for You and Your Family

Imagine if everything you needed to know about your and your family’s prescriptions was all in one place? We thought that would be pretty great too. With the Alto app, you can set up a family account to see and manage medications for your whole family from a single account. View all your current and past prescriptions, along with detailed medication information, and even coordinate your medications into one delivery. 

We set out to make the traditional pharmacy experience better by bringing the medications you need—along with exceptional care—straight to your doorstep. Some might find it unbelievable that we offer our services for free; we simply believe that we’re providing pharmacy care as it should be. 

Experience a better pharmacy. Our team is available to answer your questions from 9 am – 12 midnight ET Monday – Friday, and 10 am – 9 pm ET on weekends; reach out via phone at 1-800-874-5881, or download the app to securely message with a pharmacist.

At Alto, we value effective communication across all teams. In our latest blog post software engineer Eric Leite shares how he set out to make it easier to understand how our repositories change over time while minimizing disruption to engineers’ existing workflows.

How (and Why) We’re Standardizing our Commit Messages

Have you ever tried to debug a production issue by looking at your commit history, only to find a bunch of commits that don’t seem to be connected to any specific feature? Or maybe you've pulled the latest version of a dependency and noticed a bug that wasn’t there before?

It’s hard to pinpoint where a problem might have begun if your project (or its dependencies) don’t rely on standards to commit and release code. This was a problem I set out to tackle in my organization: How can we make it easier to understand how our repositories change over time while minimizing disruption to engineers’ existing workflows?

At Alto, we value effective communication. We keep our pharmacists and operations team in the loop about every new feature we release to production on a daily basis. We also announce changes to our codebase in a dedicated Slack channel to keep our engineers informed. But that raises the question: How do we ensure that someone doesn’t forget to make an announcement? And can we reduce the time we spend writing one up? Introducing a commit standard would enable us to use automated tooling that makes communication about code changes effortless.

Consider an open-source repository with hundreds of contributors. Project owners often adopt standards and industry best practices because it makes the project easier to maintain as the number of contributors increases. Eventually, our engineering team will grow to this point—and, just like in an open-source project, we can’t expect engineers to retain all of our conventions in their heads when they contribute. Standardizing commit messages eliminates one of the many variables around how we commit code. It can give engineers more confidence in their releases, build trust in our codebase, and increase productivity.

Many engineers have a distinct working style. If you propose a change to their everyday workflow, you will likely encounter some resistance. That’s why identifying and working with key stakeholders before you introduce a new process can help ensure its success. One way to do this is to chart stakeholders on two axes—influence in the organization and interest in the project:

I used this chart to decide how I would direct my communication with the team. Folks who fell into the “low influence” and “low interest” quadrants didn’t need to be involved in the whole process. Instead, I kept them informed by using project-specific slack channels and documentation in Notion to communicate status updates and summarize meetings. Topics that required a team decision were discussed verbally rather than using Slack to avoid potential miscommunications.

The more likely someone was to push back on the project or give me valuable feedback, the more involved they were. I included those who fell into the “high influence” and “high interest” quadrants in almost every meeting. These folks served as a kind of litmus test for my ideas. They typically had high standards and expectations and needed to be convinced that a change was worthwhile if they were going to get behind it. Keeping people like this involved in the discussion is a great way to ensure that your initiative will produce value for your organization.

In a perfect world, we’d have standardized commits in every repository. However, given that Alto is a fast-moving startup, foundational changes need to be rolled out incrementally to minimize churn, validate impact, and allow us space to learn and iterate. There’s often not enough time or resources to do everything, and going all-in on something may require more effort than it’s worth.

We began by identifying the knowledge gaps we currently have about commit standardization and how we could iteratively validate the required process changes. We initially considered beta testing with the production app that runs our day to day operations because it had the most contributors and the most to gain from standardization. However, we didn’t want to risk blocking the majority of our team or experimenting with a project that was critical to business operations. The next best option was our internal component library—it had fewer contributors, so fewer engineers would be blocked if something went wrong, and more projects depended on it, so the potential impact would still be significant.

Given that one of our company values is to Focus On Impact, and that internal changes like this are difficult to measure, we quantified our level of success or failure using a team survey. We sent out a series of questions at the start of the project asking the team to rate their satisfaction with our current commit, review, and release processes. We plan to compare these results with a follow-up survey to measure changes in ease of committing code, confidence in releasing, and our developer NPS.

After closing our knowledge gaps and getting a baseline understanding of how the team felt about our release processes, we decided to adjust the scope to include the following changes:

Commit Standardization (i.e., formatting and enforcement of commit titles)

Versioned Release Automation (i.e., automatic version cuts, changelogs, and notifications)

We looked toward existing open source solutions to make these changes because we were on a tight schedule. There were many options to choose from, so narrowing them down to a shortlist before presenting them to the team helped speed up the decision-making process. The best tools for the job will depend on your engineering organization, of course, but we prioritized maturity, flexibility, and compatibility with our existing workflows during our evaluation.

We landed on the Conventional Commits standard because it has been vetted and used extensively in other projects, and a whole ecosystem of release tooling has been built around it. It also has a short learning curve, is flexible enough to work with all our repositories, and only enforces the bare minimum necessary to generate semantic versions based on commit titles.

We chose Commitizen to help engineers get familiar with the new standard, Commitlint to warn about (but not block) contributions with invalid commits, and Semantic Pull Requests to serve as the final gate for validating commit titles. This way, non-standardized commits are only stopped from being merged when a pull request is made, and it can be easily corrected using the GitHub UI.

The open-source tooling for release automation was sparse and highly specialized, but we found Semantic Release to be the exception as it offered the most mature, flexible solution. It manages everything from cutting a release to generating a changelog to publishing packages and notifications. It also isn’t limited to only publishing NPM packages, making it an excellent fit for our multi-language codebase.

While we have a ways to go before versioned releases are automated in all of Alto’s repositories, we’ve made a significant first step with commit standardization. Some engineers have already proactively adopted the new standard without any tooling, and I’ve personally found that it has helped my commits stay focused and become more granular.

So far, we’ve standardized our component library. The commit history in this repository used to look like this:

Commits now have more context in them that’s visible at a glance (e.g., feature vs. fix), and breaking changes are explicitly noted in the commit message using an exclamation point (e.g., refactor!). These commit titles are used to automatically generate a changelog any time we cut a release. We can even automatically cut and version-bump a release for every new commit because we follow a commit standard.

The next phase of this project will be to review and act on the feedback from the follow-up survey. We will continue to build on top of these standards with release automation tooling and discuss what process changes make sense for the rest of our codebase. We are confident that through these changes, we will be able to de-risk code contributions, reduce the burden of cutting a release, and better prepare for our engineering team’s future growth.

If you have any questions about Alto, or are interested in joining our team, please reach out via LinkedIn.

How (and Why) We’re Standardizing Our Commit Messages

Erik Gregorio Cruz, Micaela Moss, and Jordane Thomas joined Alto this summer as the company’s first engineering interns! Here they share their learnings, accomplishments, and their advice for future Alto interns.

How to Make the Most of Your Engineering Internship — Advice From Alto's First Interns

Erik Gregorio Cruz, Micaela Moss, and Jordane Thomas joined Alto this summer as the company’s first engineering interns! In their three months with us they blazed the trail for future Alto interns while adjusting to a new norm of fully remote work during the global pandemic. Here they share their learnings, accomplishments, and advice for future Alto interns.

Coming out of a bootcamp program rather than a traditional Computer Science degree program, Micaela hoped to find a company open to non-traditional educational paths. “I know that a company that is welcoming of bootcamp grads values diversity, inclusivity, and mentorship.” 

For Erik, it came down to his interview experience: “Everyone seemed to really enjoy their experience and really believed in the mission they were working on.” Micaela agreed, adding that it also ultimately came down to the people for her. “You can tell a lot about a company’s culture based on what the people who interview you are like,” she said. “From the recruiter to the engineers, everyone was incredibly friendly and a joy to interact with.”

What was the most fun moment of your internship? (That is, assuming you had fun!)

Virtual team lunches were a highlight for all 3 interns. However, one special moment during Micaela’s internship actually came from resolving a ticket that involved writing an end-to-end (E2E) test—something she was not looking forward to. “I was dreading it for two reasons: First, I do not particularly enjoy writing tests—I’d rather write the code that passes them—and second, I had never worked with Cypress before. Several hours later, after reading lots of documentation, studying previously written E2E tests, and getting stumped by a hidden selector, I managed to write the test. When I finally ran it and got to watch the video as it clicked on buttons and filled out inputs, I became instantly enchanted. I may have run it several more times just to watch it, smiling like a goofball, knowing that this test that I had created would be run every time code was pushed and merged.” 

In addition to their respective engineering managers, whom the interns had weekly 1:1s with, each intern was also assigned a dedicated mentor, who committed at least 5 hours a week of dedicated support to their interns over Slack and Zoom. Mentors were able to provide historical and business context, help interns get ramped up on Alto’s tech stack, codebase, and tools, and pair program as needed. “Working with my mentor definitely made me more productive,” said Jordane.

The mentors added that working with the interns actually helped them improve their ability to articulate technical concepts, as well as their ability to talk through technical challenges with others more effectively in their day to day work.

What was it like interning during the pandemic and being fully remote?

“I found myself setting up ‘Hey, there’s a pandemic, and this is crazy, so let’s get introduced virtually, maybe?’ meetings,” said Micaela. “Although, as someone who is horrible with names, it is worth noting that a silver lining to being entirely remote is having everyone’s name in the corner of their zoom video. That, and sweatpants everyday!” 

Erik and Jordane agreed that being remote required a little extra effort. Alto’s engineering office is based in SF, and since they weren’t required to be physically in-office this summer due to the pandemic, both Erik and Jordane were based in other time zones. “In the beginning I was starting my day at 9am EST/6am PST, but if I got stuck I would have to wait until West Coast working hours before I could reach out,” explained Jordane. With time, “I picked up a different working rhythm that worked better for everyone.”

While Jordane was surprised by just “how friendly and accessible everyone was,” Erik was surprised by how quickly he was able to actually deploy code. 

Blog

Creating Sandboxes: How to Make It Easy for Your Engineering and Product Teams

How to Debug Slow and Failing Cypress Seeds

Two Engineers Crunch the Numbers: When Is It Cheaper to Pay Cash for Your Medication?

Get to Know Alto’s VP of Engineering, Mike McClay

How Alto Delivers More, at No Additional Cost

How (and Why) We’re Standardizing Our Commit Messages

How to Make the Most of Your Engineering Internship — Advice From Alto's First Interns

What to Expect When You Interview as a Software Engineer at Alto

Building an Engineering Career at Alto

Breaking Open the Black Box of Medication Pricing

Are You Right for Alto?

"Work With People Who Share Your Passion"

Switch to a better pharmacy.