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

Last year, we set out to tackle this technical debt by splitting the User model into separate concerns and refactoring the entire system into this new paradigm.

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

At Alto, we have three types of users: customers, healthcare providers (nurses, doctors, etc), and operations users who run the pharmacy. For each type of user, we maintain a separate application (though they share a monolithic backend for now): our customer app; our Alto Connect app for providers; and our internal pharmacy management tool called Wunderbar, which powers the pharmacy experience from prescription intake to fulfillment.

Early on, we made the pragmatic choice to represent both customers and operations users with a single User model, distinguishing them with a “roles” attribute. This required repetitive checks that, over time, slowed down our engineering teams, presented substantial privacy risk, and posed difficult scaling challenges as we evolved our monolith into different microservices. 

The challenges of relying on a single User model for different types of users

The notion of a User is core to our concept of identity from which authentication and authorization proceeds. From a security perspective, it’s difficult to build an extensible and clean authentication and authorization system when you’re overloading one model for two very different populations of users. From a privacy perspective, this muddied customer records (which are subject to more restrictions because they’re healthcare records) with workforce records, hamstringing many analytics efforts.

Authentication: Alto employees who were also Alto customers were required to use their work emails for their customer accounts. Not only was this restriction frustrating for Alto employees, but it also posed a security risk: employees should only be able to access Wunderbar via corporate SSO, not their personal account passwords. 

Authorization: Engineering new authorization capabilities required intricate knowledge of the idiosyncrasies of our user structure. This both slowed down development and created tremendous risk that any mistake could easily escalate user permissions.

Privacy: Because they existed in the same table, both customer records and Alto operations user records were classified as Protected Health Information, or PHI, which severely limited what we were able to do with them.

Attribution: Our robust audit logs were significantly less useful when a user ID in the transaction log might refer to either an ops user or a customer.

State management: Some updates pertaining to admin identity lived on the customer model, some lived on the employee model, and others lived in other various models.

Architecture: Tight coupling would have prevented us from decoupling our monolithic system into smaller services.

Our backend is primarily a monorepo Rails application that shares a tremendous amount of functionality between our customer, provider, and ops user-specific domains. Generally we use JWTs to secure customer and ops user sessions. These JWTs are issued only once valid credentials have been present.

Ops users are required to log in via Okta SSO, enforcing both valid username/password as well as a two-factor authentication (2FA) prompt. We use Devise and Omniauth to wire up the OIDC flow with our upstream identity provider, and we use CanCan to expand a set of roles per-user into a set of capabilities that restrict what resources they can access/modify.

Ops users primarily work in our internal pharmacy management app. However, the state of these users was shared between several different tables: Users, which otherwise refer to customers, and Employees, which share some ops user-specific state tied to Users.

Large change sets of code being deployed at once are harder to code review, harder to unwind if something goes wrong, and are more likely to be more disruptive. For this project, we knew that such a large architectural change had to be broken up into many more-digestible pieces if we were to be successful. The plan:

1. Create a new dedicated model for our ops users

# == Schema Information
#
# Table name: wunderbar_users
#
#  id                        :bigint(8)        not null, primary key
#  user_id                   :bigint(8)        indexed
#  email                     :string           not null, indexed
#  first_name                :string           not null
#  last_name                 :string           not null
#  token_last_invalidated_at :datetime
#  roles_mask                :integer          default(0), not null
#  title                     :string           not null
#  team                      :string           not null, indexed
#  is_active                 :boolean          default(TRUE), not null
#  slack_user_id             :string
#  pod                       :string

This was the easy part: create the database structure for a properly isolated admin user type, which we called a WunderbarUser.

We now had our admin user state split between Employees and Users, with a new table that engineers and analysts wanted to use that was not yet populated, and we had to make progress while allowing new hires and new customers alike to onboard to our platform.

2. Synchronize state between the old tables and new table

Next, we created a WunderbarUser for any User who was, or ever had been, a Wunderbar user. This required some historical digging —we had a lot of people who were onboarded, and even some offboarded, before we even had the intermediate Employee record!

Two major choices at this stage really helped the project succeed. First, we ensured that the WunderbarUser records all had IDs matching the corresponding User records. This is because a lot of our legacy audit records (that we’re required to preserve and keep useful as a Covered Entity under HIPAA) referenced an `admin_user_id` column populated with the ID of the User. If we just created all new entries for WunderbarUsers, these old logs would require at least one level of indirection (e.g. querying back to User) to make useful.

     # Create with the same ID as the user that we're creating this from.
     wunderbar_user_attributes = {
       id: user.id,
       user_id: user.id,
       email: user.email,
       roles_mask: user.roles_mask,
       date_of_birth: user.date_of_birth,
       token_last_invalidated_at: user.token_last_invalidated_at,
       first_name: user.first_name,
       last_name: user.last_name,
       preferred_first_name: user.preferred_first_name,
       is_active: false,
     }

Second, we created a new WunderbarUser any time we created a new Employee record (e.g. when we onboarded a new employee) and synchronized any changes between Users, Employees, and WunderbarUsers tables. As a side note: we knew we’d have to protect this syncing logic to ensure that we only copied each change once — otherwise, our callbacks would fire forever!

3. Migrate functionality slowly to use the new ops user model

We migrated logic to reference WunderbarUsers where previously we’d referenced Users and/or Employees. Authentication, authorization, audit logs, and pharmacist licenses were all updated here — albeit painstakingly!

We then migrated all of the foreign keys our various Postgres database tables held to either the Users or Employees tables to instead reference the WunderbarUsers. This ended up being around a hundred foreign keys, but a constraint-only migration that fortunately didn’t involve any data changes.

In short: our goal was to do this change slowly and steadily enough that nobody would notice until, one day, we could announce to the team, “Hey, we did a big security-pertinent project, and now you can change your customer email to be anything.”

Authentication: While we use the same JWT format for each, our customer and operations user authentication systems are now totally separated.

Authorization: With separate user types, we have separate capabilities and domain-specific authorization checks for each area, enforced in code.

Experience: Onboarding as a new Altoid (somebody who works here; come join us!) is totally separate from the customer experience, and you no longer need to link your accounts together.

Privacy: Our ops users who choose to be customers enjoy the full privacy afforded to our customers without tying their account to their work identity in any way.

Attribution: Legacy audit logs are still index-able and query-able with the same IDs, just in a slightly different table.

State management: Customer state lives on the User table, and ops user state lives on the new WunderbarUsers table. Our callbacks on each have been dramatically pared down, and our intermediary Employee table is entirely gone, along with a number of other now-ancillary tables.

Architecture: We have a clear path to federate RBAC checks without shipping our entire customer database between services.

Bonus: Performance and code readability generally improved by removing complex joins and join tables and isolating concerns between the customer and ops user domains.

Another Bonus: Significant refactorings and increased test coverage along the way while we cleaned up some very old, very stale code.

Large architectural changes of legacy systems with heavy use are rarely 100% smooth. Here are a few learnings to keep in mind the next time you tackle a hefty piece of technical debt. 

1. Always validate your assumptions (e.g. the data your constraints are against) when foreign keys are concerned. Multiple times we assumed, “Hey, we’ve migrated a bunch of really big tables that are really old (insurance claims, prescriptions, and more), so there’s no way we could have another admin user that we haven’t created a commensurate WunderbarUser for, right?” Wrong! Your data can always have inconsistencies, but a simple SQL query (e.g. validate that all values of the column you’re migrating the foreign key to have a matching WunderbarUser) can save a lot of time and headaches.

2. When migrating foreign key constraints on tables with active reads in Postgres, ensure you break it into two steps. Migrate your foreign key with `{ validate: false }`

 def up
   remove_foreign_key :inventory_orders, to_table: :users, column: :created_by_id
   add_foreign_key :inventory_orders, :wunderbar_users, column: :created_by_id, validate: false
 
   validate_constraint
 end

Validate the named constraint of your foreign key separately

 def validate_constraint
   validate_constraint_statement = 'ALTER TABLE "inventory_orders" VALIDATE CONSTRAINT "fk_rails_abcd1234";'
   ActiveRecord::Base.connection.execute(validate_constraint_statement)
 end

3. When working with legacy tables, be mindful of legacy systems. Our Billing service used a very outdated golang ORM that panicked if a column specified by the `struct` in source no longer existed; this caused a late-night outage that made auto billing requests back up the next day.

4. Scoping projects is hard! This was a larger project than our team had ever scoped and delivered before. Once all the dust settled, this project took several months longer than our initial scoping estimates.This project was worth doing, but better estimates allow us to prioritize better. If we’d had a great scope of this immense project upfront, would we have chosen to do it first? Also, this was a tremendously difficult project to separate into material stages; all the benefit was really backloaded.

In the end, this was a very satisfying and important project to complete. We wouldn’t have been able to accomplish it without a lot of help from our colleagues on the Platform team, the Security team, and across many other functions atAlto. Very large projects that involve a lot of moving pieces and impact other teams are always scary — but we can’t let that fear prevent us from making the changes we know we need to do in order to be successful long-term.

The Engineering Team is hiring! Learn more about open positions here.

In our previous post, we discussed how we designed our biometric authentication system with both privacy and a better user experience in mind. In this post, we'll show you exactly how we did it.

Considerations and Approaches for Implementing Biometric Login: Part 2

In Part 1, we discussed how we designed our biometric authentication system with both privacy and a better user experience in mind. In this post, we'll show you exactly how we did it.

To build a new authentication mechanism, we opted to use the react-native-biometrics library. This library interfaces with the device's biometrics, generates a keypair, and stores the private key within the device's keystore. When logging in with biometrics, the library creates a signature using the stored private key, and the signature is then sent to the server for validation. (Note: this library is now unmaintained. At the time of writing, this implementation can instead be accomplished with the following maintained libraries: expo-local-authentication to access device biometrics, keypair to generate a keypair, react-native-keychain to access the device keystore.)

Check if biometrics are supported and configured by the user for this device.

const { available } = await ReactNativeBiometrics.isSensorAvailable();

If yes, prompt the user for a biometric scan.

const { success } = await ReactNativeBiometrics.simplePrompt({ promptMessage: 'Confirm ID' });

If the scan succeeds, generate a keypair. The react-native-biometrics library's createKeys method will automatically save the private key to the device's keystore, and return the public key counterpart. Send the public key to your server.

const { publicKey } = ReactNativeBiometrics.createKeys('Confirm biometrics');

// Save the public key to your database
post('/save_biometric_key', { key: publicKey, device_id: 'xyz' })

When the user tries to login with biometrics, scan their biometrics. This time, if the scan succeeds, create a signature using the stored private key. The react-native-biometrics library's createSignature method handles all of this.

// Prompts for scan
// On scan success, accesses private key and uses it to generate a signature, which is then returned
const signatureResponse = ReactNativeBiometrics.createSignature({
  promptMessage: 'Face or fingerprint ID for Alto Pharmacy',
  payload: BIOMETRIC_SIGNATURE_PAYLOAD,
});

Send the signature to the server to validate against the public key. If validation succeeds, the user has successfully authenticated with biometrics and can proceed into the app.

// Call your server API to validate the signature against the public key that you've stored in the database
const validationSuccess = await post(
  `/validate_biometric_signature`,
  {
    signature: signatureResponse.signature,
    payload: BIOMETRIC_SIGNATURE_PAYLOAD,
		device_id: 'xyz',
  },
);

if (validationSuccess) {
  // Login Success
} else {
  // Login failure
}

import ReactNativeBiometrics from 'react-native-biometrics';

const setUpBiometricLogin = async () => {
  // Check if biometrics are supported and configured on this device
  const { available } = await ReactNativeBiometrics.isSensorAvailable();

  if (available) {
    // Prompt user to scan biometrics
    const { success } = await ReactNativeBiometrics.simplePrompt({ promptMessage: 'Confirm ID' });
      
    if (success) {
      // If scan is successful, generate a keypair, then save the public key to the server
      const { publicKey } = await ReactNativeBiometrics.createKeys('Confirm biometrics');

      post('/save_biometric_key', { key: publicKey, device_id: 'xyz' })
    }
  }
}

const loginWithBiometrics = async () => {
  // Scan user's biometrics. On scan success, generate a signature
  const signatureResponse = await ReactNativeBiometrics.createSignature({
    promptMessage: 'Face or fingerprint ID for Alto Pharmacy',
    payload: BIOMETRIC_SIGNATURE_PAYLOAD,
  });

  // Validate the signature against the public key saved on the server
  const validationSuccess = await post(
    `/validate_biometric_signature`, 
    {
      signature: signatureResponse.signature,
      payload: BIOMETRIC_SIGNATURE_PAYLOAD,
      device_id: 'xyz',
    },
  );

  if (validationSuccess) {
    // Login Success
  } else {
    // Login failure
  }
}

1. build a way to store a public key associated with a device

2. write a method to validate a signature against a public key

3. expose endpoints to save a public key, and validate a signature

Once biometric authentication is built, there are additional decisions to make. The right decisions for your app will depend on your goals; the approach we took here at Alto may not align with what is best for your app.

How should biometric sessions interact with our existing email and password sessions?

We opted to treat email and password sessions as longer-lived primary sessions, with biometrics as a shorter-lived secondary session on top of that primary session. This means that a user must first login with email and password in order to use biometrics on subsequent app opens. If the user logs out for any reason, they will need to log in again with email and password before they can use biometrics again.

How often should we prompt the user for biometrics vs. email and password?

We opted to prompt the user for biometrics far more frequently than email and password, but made this configurable in case we want to adjust.

We use tokens and cookies for session management.

There are plenty of edge cases to consider as you're developing biometric capabilities for your app, including: what should happen when the biometric scan fails, or when the signature validation fails? What should happen if a user disables biometric permissions from their device? What should happen when two users share a device? What should happen if 'risky' activity is flagged for this account? How can we disable biometric login if needed?

Face and fingerprint ID login has clear benefits for both the end-user and the application itself, but it comes with a host of implementation decisions. If you're considering building biometric login for your app, I hope this article gives you clarity on what biometrics is, the different ways you can integrate it into your app, and the tradeoffs and edge cases to consider.

At Alto, the Patients Engineering team worked closely with our Security Engineering and Product teams to align on our goals and build the best solution for our needs. Our Security team offered deep expertise on the authentication strategies to adopt and avoid, and our Product team kept us tethered to building the best experience for our users.

Working as a team is one of the best parts about developing at Alto. If you want to meet the awesome team I'm talking about, come join us - we're hiring!

When engineering incidents happen, typical deployment pipelines are just too slow—especially if customers’ medications are on the line. Here’s the speedier rollback process we use at Alto Pharmacy to ship fixes in 3 minutes, flat.

How Alto Reduced Time to Resolution for Production Incidents

Production incidents caused by newly-merged code happen to us all. When they do, most engineering organizations discuss the root cause and how to prevent similar incidents in the future. At Alto, we evaluate two additional metrics:

Time to detection: How quickly did we know something was wrong?

Time to resolution: How quickly did we restore service?

Time to resolution is especially critical for us as a pharmacy, where a long-running incident could block a user from getting their medication on time.

Over 30 times a day, an engineer at Alto hits the merge button, deploying a new build to production. Our well-automated CI/CD pipeline, built by our Infrastructure team, handles the 3-step deployment process:

1. Build: install Ruby & JavaScript dependencies

The average runtime for our standard deployment pipeline is 30 minutes—reasonable for a CI/CD pipeline, but too long when shipping a fix for a production incident.

We introduced a “hotfix” workflow as a first pass at an expedited deployment pipeline for incident response. A hotfix is a commit that introduces new code to address the incident by either removing or reverting the buggy code that introduced the issue in the first place or by shipping new code that fixes the initial issue. 

The hotfix deployment pipeline reduces incident time to resolution by triggering a specific CI job that removes the test step from our standard pipeline, reducing the workflow to just the Build and Deploy steps.

Implementing a hotfix pipeline on top of our standard pipeline in CircleCI was relatively simple—in our `.circleci/config.yml`, any part of our CI workflow that should be skipped in case of a hotfix runs a job called “early_exit_if_hotfix” that will skip the current step if the last commit message of the code being built includes the keyword “[hotfix]”.

early_exit_if_hotfix:
    steps:
      - run:
          name: Early exit if hotfix
          command: |
            git_commit_message=$(git log --format=%B -n 1)
            if [[ $git_commit_message =~ "Merge pull request #" ]]; then
              echo "This is a merge commit. Checking if this is a hotfix deploy"
              git_commit_sha=$(git log --format=%H -n 1)
              git_commit_message=$(git log --format=%B $git_commit_sha^-)
            fi
            if [[ $git_commit_message =~ "[hotfix]" ]]; then
              echo "exiting early for hotfix deploy"
              circleci-agent step halt
            fi
            echo "not a hotfix deploy, continuing"

run_ruby_tests:
  steps:
early_exit_if_hotfix
run_tests

The hotfix workflow reduces time to ship a resolution, once we identify the fix, from 30 minutes to ~18 minutes. It’s faster than our standard pipeline but still requires considerable hands-on work from the engineer performing the hotfix.

To further speed up deployment and reduce manual work, we introduced a workflow that simply rolls back to a previously-built healthy deployment image. In this workflow, the entire pipeline is reduced to just the Deploy step.

To invoke a rollback, an engineer commits a message with the keyword “[rollback]”, followed by the SHA of the commit to rollback to. Similar to the hotfix approach, any build step that should be skipped during a rollback checks the commit message for the “[rollback]” keyword before running:

early_exit_if_rollback:
    steps:
      - run:
          name: Early exit if rollback
          command: |
            git_commit_message=$(git log --format=%B -n 1)
            if [[ $git_commit_message =~ "Merge pull request #" ]]; then
              echo "This is a merge commit. Checking for rollback sha..."
              git_commit_sha=$(git log --format=%H -n 1)
              git_commit_message=$(git log --format=%B $git_commit_sha^-)
            fi
            if [[ $git_commit_message =~ "[rollback]" ]]; then
              echo "exiting early for rollback deploy"
              circleci-agent step halt
            fi
            echo "not a rollback deploy, continuing"

run_ruby_tests:
  steps:
early_exit_if_hotfix
early_exit_if_rollback
run_tests

The rollback workflow looks for a build matching the specified SHA and posts a confirmation message for the engineer, then deploys that build to production. The rollback approach dropped our time to resolution even further, from 30 minutes to ~3 minutes.

There are three edge cases that we’ve also baked into our rollback workflow: potentially stale images, database migrations, and blocking new merges and deployments.

Our script has a special block warning the engineer if a target image is older than an hour. The older the image, the riskier the rollback, as the delta between the image and the latest commit on main is larger.

time_rollback=$(git show -s --format=%ct ${rollback_revision})
time_now=$(date '+%s')
if [ $(($time_now - $time_rollback)) -gt 3600 ]; then
    message="${message}\n\n:warning:The rollback commit is more than an hour old."
    message="${message}\nThe [hotfix workflow](https://www.notion.so/alto/Deploying-a-Hotfix-Rolling-Forward-bb8e9cea05b44c67a64e23ae652653b6) might be a better candidate for this deployment."
fi

We also want to warn engineers if any database migrations have occurred between the current image and the target by checking the diff of the db/migrate directory. Rolling back application code without applying changes to the database can result in the database and application code becoming out of sync, resulting in further problems. Our script will warn engineers if a migration has been detected between the current and target image and provide instructions on how to rollback migrations if required.

Because a rollback deploys an image that’s older than our latest build, we also need to block continuous deployment until we’ve restored the main branch to a safe state — typically by deploying a hotfix as soon as we can identify an appropriate fix. We accomplish this using a Github issue with a specific tag that, when open, triggers a job causing any active CI job to fail. After the incident is resolved, the incident manager closes the issue, which will retrigger the blocked jobs and resume the normal build and deploy workflow.

The expedited rollback process has reduced our overall time to ship a resolution for incidents down to a speedy 3 minutes—a valuable improvement for our internal operations users, as well as for our customers and healthcare providers who rely on Alto’s service to get prescriptions filled. Branching these incident response workflows off of our existing standard deploy pipeline keeps the maintenance cost low for our infrastructure team, and robust automation reduces the risk of manual error for our product engineers when they need to invoke these workflows.

The Providers Team at Alto is charged with building the tools and service components necessary to deliver an exceptional pharmacy experience for healthcare providers. Read on to learn more.

Get to Know the Team That Has Doctors Calling Alto “The Pharmacy of The Future”

Editor's Note: The post was updated on November 8, 2021 to reflect the rebrand of AltoMD to Alto Connect.

Alto Pharmacy’s mission is to fulfill medicine’s true purpose — to improve quality of life — for everyone who needs it. The healthcare professionals who prescribe medications to Alto and the clinical teams that support them are critical partners in making our mission successful. To this end, the Providers Team at Alto is charged with building the tools and service components necessary to deliver an exceptional pharmacy experience for healthcare providers.

Every day, clinical teams -  including prescribers and other clinical staff like nurses, practice coordinators, and billing specialists - spend hours tracking down insurance information, coordinating approvals and appeals, discussing options with their patients, and playing phone tag with pharmacies. The Providers Team enables these healthcare providers to spend more time on patient care and less time on back office tasks. 

Alto’s provider communications platform, Alto Connect, and related services, including insurance benefits coordination and prior authorization management, remove clinical blockers that traditionally slow down or prevent an individual’s access to treatment. Practices that share Alto with a majority of their patients can save three or more hours per day on pharmacy and insurance administration tasks, with less time spent waiting on hold, fewer faxes and improved employee satisfaction (not to mention happier patients!). 

Anu Kashyap, a Product Manager on the team says, “I joined Alto to make a contribution to people’s health using technology, and the Providers Team is working on specific, painful healthcare problems that are critical to solve. These challenges have been incredibly fulfilling to work on.”

How does the Providers Team play into the overall growth of Alto Pharmacy?

The Providers Team is fairly new, as they were originally part of a larger Growth team within Alto. Kjersten Elias, Engineering Manager, explains: “Alto's growth model is driven by conversations about pharmacy choice in the doctor’s office, and in the fall of 2020, we dedicated an engineering team to optimizing our product offerings and improving the experience for the healthcare providers having those conversations.”

Anu adds, “The key for our business’ continued growth is having healthcare providers trust that we are the best pharmacy for their patients and leverage us as their pharmacy of choice. This type of growth channel is much more powerful than anything direct to the consumer. We can only do this however, if our providers have an excellent experience with us, and we’ve only scratched the surface here.” 

Being part of a newer team has distinct advantages. Software Engineer Dereck Quock notes, “We have unique opportunities to modernize how we build apps and define our infrastructure and technical needs. With the freedom to utilize cutting edge tech and new frameworks, there is so much room for innovation.”

What is the culture of the Providers Team like?

The engineers each raved about a small-but-important recurring calendar invite each Friday: Team Time. This protected time is a space to catch up, banter about anything other than work, and, if folks are feeling brave, face off with Anu, former Teen Tournament champion, in a rousing game of Jeopardy.

It's not hard to see why Kjersten and her team light up when they talk about team culture. Amy Chen, a Software Engineer on the team, shared that  “Kjersten is an incredible manager. Everyone is empowered to ask for and share feedback, fine-tune our processes, and check in with each other.”

“When I joined, I could tell right away this team really lifted each other up and had each other’s backs,” said Dereck. “It’s one of the greatest teams I’ve worked on.”

The Providers Team is hiring! Learn more about open positions here.

Get an inside look at the patients team at Alto Pharmacy to learn what it's like to work on Alto's customer-facing apps, which projects are on the horizon, and who makes the best barbecue short ribs.

Get to Know the Team That Builds Alto's Customer-Facing Apps

Imagine an app that allows you to buy things and have them delivered to you the same day, for free. Now take that app and put it in a highly regulated space like pharmacy. You face the challenge not only of building an e-commerce platform from scratch, but also of navigating medication pricing, federal and state regulations, and patient safety—and that's just the way the Patients Team likes it.

"It's a really exciting and fun problem to solve," says Mike Riess, the team's Engineering Manager. Software Engineer Angelique Nehmzow agrees: "There's a really strong product and design aspect, like more traditional startups, but then everything gets a little bit more interesting because it's healthcare."

Below, we chat with the team to learn what it's like to work on Alto's customer-facing apps, which projects are on the horizon, and who makes the best barbecue short ribs.

What does the Patients Team do at Alto? 

Ask anyone on the team why they joined, and chances are, they'll tell you they wanted to be on the product team closest to Alto's customers: "We really try to own the customer experience," says Peter Zeng, the latest Software Engineer to join the team. "If a customer is coming to the web app, or they're coming to our mobile app, we want to make sure that they're able to onboard with us as easily and conveniently as possible."

The team is also responsible for the customer experience beyond onboarding, from the moment a customer schedules a medication for delivery to the time that it shows up on their doorstep. "We already offer great services like free, same-day delivery and cost savings. The Patients Team empowers customers to make the most of our offering," Nehmzow explains. "You can see what prescriptions you have, check on the status of your order, and schedule automatic refills. In a more traditional pharmacy, you don't get that kind of visibility. You have to call them up or even wait in line in person. At Alto, it's a different experience."

What was it like in the team's early days?

Today, there are eleven engineers on the team working to build that better end-to-end experience—but it wasn't always that way. When the team first formed in 2019, it consisted of just three members: Riess, Brian McRae, and Andy Lau, all of whom are still on the team.

"The first priority for us was just stabilizing the foundations," Riess says of the team's early days. Every other week, the three team members, along with Alto co-founders Matt Gamache-Asselin and Jamie Karraker, would meet to audit the app's core flows. "For the first three months we probably didn't make it through some flow at least 50% of the time," Riess recalls. "There would be a ton of bugs in the onboarding experience, things that weren't working with the flows or navigation or deep linking."

Among the team's first projects was a redesign of the checkout flow. "There was a lot of work to be done to streamline the checkout flow, which is pretty much the main function of the app," says McRae, who initially joined the team as a software engineer and later transitioned into product management. "We had to make it easier to add a payment, add your addresses, everything you need to do to schedule your prescription for delivery."

"The growth of the team, in terms of both size and stability of the platform, has allowed us to swing at more interesting bets for the company," Riess says. In particular, the Patients Team has turned their attention toward experiences personalized for specific medical conditions.

"Different customers have different needs. A customer who wishes to start a family will have a different experience than a customer who needs to order their routine heart medications that they've been taking for the last eight years,” McRae says. “The challenge for us is how we serve all these customers well through the app."

"I think that's where Alto can be such a differentiator," Riess adds. "A world-class pharmacy experience is about so much more than just dispensing medications. We want to build tools for customers that help them get the most out of their medications—everything from simple videos teaching them how to perform injections safely at home to the ability to synchronize deliveries for multiple prescriptions for managing complex health conditions."

With these new projects on the horizon, engineers have ample opportunity to focus on the areas that excite them most. "We're full-stack and mobile and web," Nehmzow says. "Part of the team focuses more on experimentation, iterating quickly, and using data to make decisions. Part of the team focuses more on platform work, tooling, and improving the developer experience. There are a lot of areas to explore and contribute to."

One spring night, the Patients Team gathered in a back yard in San Francisco’s Mission District for short ribs and an impressive spread of side dishes. "Kudos to Robbi, who's the grill master. I just provide the grill!" Nehmzow says, laughing. While the team barbecue was the first time some members had met in person, Zeng notes that the team has been supportive of one another even while working remotely during the pandemic.

"The first real project that I was assigned to was working with the communications system. Before writing my first piece of code, I spent two weeks exploring what already exists and understanding the different parts of the system," Zeng says. "I've been really impressed with how understanding my teammates have been. They make the space for you to learn all the different pieces of code we own."

That culture of support is by design, reflected in the six principles—complete with matching emojis—at the top of the #patients-team Slack channel: "Empower each other," "be an owner," "find the path," "learn by doing," "embrace complexity," and "foster trust." 

While these principles echo Alto's company-wide values, they are unique to the Patients Team. "For a long time, we were the only external-facing product team at Alto," Riess says. "These principles were intended to be this motivation around how we win. It's a combination of how we treat each other, how we reason about decision making, and how we approach solving a problem that's never existed before."

As the team looks toward the future, those principles have never been more relevant: "We have a goal and an area we want to focus on, but in terms of which projects we're going to do, it's not a top-down thing," Nehmzow says. "It's very much, 'We're going to figure out how to solve this problem together, even when it's difficult.' That's my favorite part about the team."

The Patients Team is hiring! Learn more about open positions here.

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.

Alto Pharmacy Named Great Place to Work®

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. This important recognition is a testament to the dedication of the entire Alto team and the vision of our founders to create a healthcare company truly anchored on the needs and experiences of the customer.

80% of our team says that Alto is a great place of work, compared to just 59% of employees at  other companies that participated in this year’s assessment. Here are other key takeaways from our team’s’ responses:

93% of our team members say that you are made to feel welcome when you join Alto.

88% say that people care about each other here.

86% say that they are able to take time off from work when needed.

Every company has its own unique culture, but there are two things that all great workplaces share: trust in company leadership and a strong sense of pride in the work. For many Alto team members, being part of a mission-driven company is one of the best parts of working here. 

Our mission — to improve the quality of life for everyone who needs medicine — guides us in every business decision, every day. From fostering an inclusive culture that invests in talent from the same communities as our patients, to building a pharmacy model that meets individuals where they are in their health journey, everything we do at Alto is anchored on delivering meaningful change. 

When asked what makes Alto a great place to work, our team members emphasized our guiding company values — including our commitment to putting patients first and leading with empathy — and getting to spend each workday with colleagues who are also inspired and motivated by those values.

“Our bold, patient-centered mission creates a powerful level of empathy across the entire team,” shared Rob Anderson, Alto’s Head of Talent . “The people who work here are one of the best parts of coming into work, and one of the top reasons our workplace is so rewarding.”

And taking care of our team members is just as important as ensuring we leave no patient behind. In response to the past year’s unprecedented challenges, we introduced Alto Recharge Week, which includes expanded time off for all team members. This reset period allows team members to unplug and recharge, and it’s also a small show of  appreciation for how they supported our patients and healthcare providers throughout these challenging times.  

It’s an exciting moment to be part of Alto’s mission. Since our founding in 2015, we’ve been focused on delivering a totally new model of pharmacy care. Our community-based, courier-first pharmacy model simplifies the entire prescription process and is tailored to each patient’s unique needs, leading to better  outcomes, healthier lives, and happier customers. And with every year, Alto’s impact continues to grow:

More than 36 million individuals now live within Alto’s free same-day courier service zones. 

In the past twelve months, we opened new locations in New York City, Houston, Dallas, and San Jose and expanded our coverage areas in Seattle, Las Vegas, and Denver. 

We've expanded our specialized resources for patients living with diabetes and managing heart and lung conditions .

We’ve accomplished so much over the past six years, and we’re still just getting started.

“I don’t know a single person who hasn’t needed something from a pharmacy at some point, and there’s still so many people across the country who have yet to experience our unique community pharmacy experience,” Alto’s Recruiting Manager Lauren Binet said. “That potential for impact is incredibly motivating.”

As our geographic footprint has grown, so has our team. In the past two years alone, we’ve quadruped our team to more than 1,000 Altoids!

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.

View open roles in design, engineering, IT, sales, patient care, and more.

About Great Place to Work Certification™

Great Place to Work® Certification™ is the most definitive “employer-of-choice” recognition that companies aspire to achieve. It is the only recognition based entirely on what employees report about their workplace experience – specifically, how consistently they experience a high-trust workplace. Great Place to Work Certification is recognized worldwide by employees and employers alike and is the global benchmark for identifying and recognizing outstanding employee experience. Every year, more than 10,000 companies across 60 countries apply to get Great Place to Work-Certified.

All third party trademarks (including logos and icons) referenced by Alto Pharmacy remain the property of their respective owners. Unless specifically identified as such, Alto’s use of third party trademarks does not indicate any relationship, sponsorship or endorsement between Alto and the owners of these trademarks.

In recognition of Women’s History Month, we highlight four women at Alto shaping the future of pharmacy. These leaders share their advice for women in the workplace, their unique super powers, and what they appreciate most about Alto's culture.

Celebrating Women at Alto Pharmacy

Liz Kelly, Sr. Director Sales, Fertility 

I'm responsible for hiring, coaching and supporting the needs of the national fertility sales team. I also work closely with fertility business and operations teams to deliver on our clinic and customer promises.

Before joining Alto, I was finishing up a sabbatical where I spent my time volunteering on the board of a non-profit called ServeHAITI. Prior to that, I was the West Coast Area Business Director at EMD Serono and worked with Matt and Jaime [Alto’s co-founders] to secure a contract to distribute fertility meds when they were still working out of AG Pharmacy!

What do you appreciate the most about Alto's culture? 

Hands down my favorite part of being on the Alto team is that the patient is truly at the center of every decision we make. I value that we make business decisions with our mission in mind.

What do you like doing outside of work?  

Of late, my favorite pastime is heading to the dog beach with my rescue, Bodhi, who has been the best medicine to ease some of the COVID-19 isolation I experienced over the past year. Before the pandemic, I made sure to travel to at least one new international spot a year. I love the experience of getting exposed to all things about another culture: cuisine, culture, belief systems, language.

I like to think that my super power is seeing the greatness in others, sometimes before they see it in themselves.

I aspire to live by the motto "be the change you wish to see in the world." I encourage women to speak up for what they believe is right, even if nobody else agrees. That includes planning for your own career path and making it a priority to develop your skill sets so that you are prepared to climb the ladder that serves your own greatness.

I graduated from pharmacy school in May of 1979 and started working at AG Pharmacy after passing my boards later that year. I bought AG in 1998 when the previous owner wanted to retire - he had been with AG since it first opened in the early 60's.

My family moved to San Francisco from Hong Kong when I was five years old. Our story is one similar to those of many immigrant families who came to America looking for a better life in search of the American dream: own a home, have a car, raise children safely and give them the opportunity of a good education and a chance to have a better life. My parents raised their children here, emphasizing family, hard work and education. They lived their American dream, and I have them to thank for all that I am today.

What’s your favorite thing to do outside of work? 

I love to travel. There are so many unique places to visit in this world. With the different cultures, the food, and the amazing sceneries/landscapes, there are endless things to see and experience! 

The thing I appreciate most about Alto's culture is that everyone works so hard together to bring about the best pharmacy experience for all our customers. You can feel the energy and the motivation of all the Altoids. I cannot emphasize how amazing it is to be a part of this team and to watch Alto grow and evolve into the pharmacy of the future and the pharmacy of our dreams!

What’s your favorite memory thus far at Alto? 

In the very early days, when Alto was still Scriptdash Pharmacy, a customer needed to get her trigger shot [as part of a fertility protocol] within the next few hours. It was close to rush hour, and we had no couriers available to deliver to the South Bay. Our CEO Matt came to the rescue on his motorcycle, and off he went to make the delivery. It was such a wonderful and warm feeling to watch and cheer him on together. That is truly what Alto love is all about!

I manage our amazing IT Support team, helping all Altoids get the technology support they need, when they need it. 

For the better part of the last decade I have been managing IT Support teams. From Facebook and Twitter to Lyft and Uber, I’ve seen it all (or at least most of it!).

Our incredible dedication to our mission. In my short time here, I truly see us putting patients first, and it’s moving to see. 

What do you like doing outside of work? 

I’m a big traveler, but since COVID-19 has put a damper on that, I enjoy flying around Colorado with my partner in our vintage Beechcraft Bonanza. I also love hopping on my motorcycle and just exploring! 

I’m in love with Central and Eastern Europe. Some of my favorite places are Prague, Vienna and Budapest. 

I’m originally from Iran but moved a lot growing up, including Oklahoma, Australia, Qatar, Kuwait, and Chicago. I have been in San Francisco for the last six years. I stumbled across software engineering in college and found a passion for building products and teams. I joined Alto as the third engineer and this is now the largest company I’ve ever worked at. 

I lead a group of 20 engineers across three teams. Two teams are focused on getting prescriptions ready to schedule quickly and accurately, and one is focused on enabling faster, higher quality, and more enjoyable product development across the broader product and technology organization. My work involves a lot of collaboration, creativity, transparency, and flexibility. 

I was an early software engineer at a small startup; before that I was a hybrid software engineer and product manager at a design and development studio. 

I like how passionate everyone is about what they do. 

I’m at my best managing a crisis or finding a path through conflicting strong opinions. 

I want to start with some advice for our allies: get more curious about the experience of the women you work with and learn about ways you can support and amplify the work of the women around you. Diversity, equality and inclusion is a team sport and, even if we win a game or two, it’s about the continuous pursuit of excellence. 

For my fellow women at Alto, I wish I knew earlier to focus more on improving my craft and impact so I can get a seat at the table, rather than trying to juggle advocacy and my own work. Once you’re at the table, you can really advocate for hiring, growing, and retaining women. 

To learn more about the work of our six employee resource groups (ERG’s) focused on building community - including Umoja (Black), Auténtico (LatinX/Hispanic), Women (WOAA), Proud (LGBTQIA+), Asian/Pacific Islander, and Working Parents - read our 2020 Diversity, Equality and Inclusion Report. 

Blog

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

Considerations and Approaches for Implementing Biometric Login: Part 2

How Alto Reduced Time to Resolution for Production Incidents

Get to Know the Team That Has Doctors Calling Alto “The Pharmacy of The Future”

Get to Know the Team That Builds Alto's Customer-Facing Apps

Alto Pharmacy Named Great Place to Work®

Celebrating Women at Alto Pharmacy

2020 Diversity, Equity & Inclusion Report

Diversity At Alto: Building an Inclusive Healthcare Company and Culture

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

How Alto Delivers More, at No Additional Cost

Airbnb’s Former Head of Business Technology Joins Alto

Switch to a better pharmacy.