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

No industry is immune to burnout, including pharmacy. At many traditional retail pharmacies, individual pharmacists are often asked to do more than is possible on any given workday. Not only does this deprive talented and extensively trained health professionals of a manageable working environment, it deprives patients of the exceptional care they deserve.

pharmacists-spotlight-roni-hein

The better pharmacy model we’ve created at Alto makes life easier for everyone involved in the prescription process: patients, physicians, and pharmacists. And in restructuring how pharmacists work, we haven’t just separated fulfillment and patient care responsibilities into different roles — we’ve ensured that there’s ample support for each specialization, as there should be in any profession.

To wrap up our series of pharmacist profiles in celebration of American Pharmacist Month, we spoke to Roni Hein, a patient care pharmacist lead who takes care of her team so that they can in turn care for patients.

What motivated you to pursue a career in pharmacy?

It all began with my high school and college job at Target. I interacted a lot with the pharmacy team while working in the health and beauty section and eventually moved into that department.

I never expected it to be more than a college job, but it turned into the beginning of my professional path. As I worked there, I was able to see the impact pharmacists made in customers’ lives each day. It really struck me that in many communities, including mine, pharmacists were the most accessible healthcare providers. That accessibility is so impactful on a person’s well-being.

What challenges have you encountered as a pharmacist?

Limited time and isolation behind the counter, without question. In retail pharmacy, more and more responsibilities were added to my job description, with fewer resources to accomplish them.

All pharmacists value the personal connections we make with patients. I think many of us would say that making an impact through patient counseling is the best part of our day, but that is often what gets lost when pharmacists are asked to do more. Our primary driver for entering the profession is the first thing to go. I found a very refreshing change at Alto.

Everyone at Alto, no matter their department or role, has the same shared goal of improving patient lives by transforming the pharmacy model. As a patient care pharmacist lead, I do that by supporting my people. I create the space for our pharmacists to do their best work. They are able to have better interactions with patients because they are taken care of.

The pandemic has been a trying time for many companies and teams, including mine. I am constantly looking for new ways to ward off burnout and maintain a sense of camaraderie, not only for the pharmacists I manage, but for the benefit of our customers as well.

The individual locations of many retail pharmacies can feel very separate from each other. Each one often serves a single population.

The centralization of Alto’s patient care team is a contrast to that model. We have a cohesive, unified team serving all patients. That means there’s a depth of resources available to each pharmacist, which is also really important for retaining great talent.

Our pharmacists have a great support system in their colleagues. There’s other smart, driven pharmacists to bounce ideas off of. Unfortunately, you don’t always get that in our profession.

It also means that you don’t have to worry about anything falling through the cracks if something comes up outside of work. It's a game changer to be able to take time to grieve a loved one or to care for your child if they’re sick while knowing that your patients are still in expert hands. I never had that in retail pharmacy.

Finally, what is one thing people would be surprised to know about life as a pharmacist?

At a tech-oriented pharmacy like Alto where there’s so much innovation, you’re constantly thinking of new and creative ways to problem solve. It’s challenging in the best possible way. There isn’t a day when I don’t have to put my critical thinking skills to use.

This is part of a series of pharmacist profiles to recognize American Pharmacist Month 2022. Meet the other pharmacists featured in this series: patient care pharmacist Travis Allison, specialty patient care pharmacist Gabrielle Kaplan, and medication therapy management pharmacist Wei-Lin Chang.

National Pharmacists Month Spotlight: Roni Hein

The Alto product and engineering team has long been focused on initiatives that improve our unit profitability. Now that we’ve laid a strong foundation, we've started to think about our next big bets: How do we expand our services beyond delivering prescriptions? How do we test new value-add offerings quickly and iteratively? That’s where the incubation team comes in.

Meet the Innovation Team Building Alto's Next Big Bets

The Alto product and engineering team has long been focused on initiatives that improve our unit profitability. Now that we’ve laid a strong foundation, we've started to think about our next big bets: How do we expand our services beyond delivering prescriptions? How do we test new value-add offerings quickly and iteratively? That’s where the innovation team comes in.

Newly launched in 2022, the team is small and scrappy by design. We’re a product manager, two engineers, a part-time designer, and a part-time manager with a single mission: to launch at least two significant new business experiments per year. If an experiment is successful, we’ll scale it into a full workstream before handing it off to a stand-alone product team.

We started with over-the-counter (OTC) medications. OTCs, or medications you can buy without a prescription, like Advil, are high-margin products that users are accustomed to purchasing at traditional, brick-and-mortar pharmacies. The goal of this experiment was to assess how much interest users have in adding OTCs to their order while checking out in the Alto app. We set a target conversion rate and offered OTCs only from our San Jose pharmacy, which is less busy than our San Francisco pharmacy but close enough to engineers in San Francisco for in-person troubleshooting.

Our initial hypothesis: if we present users with a small selection of OTCs targeted to their needs (based on the prescriptions in their cart), they’ll be more likely to convert. With support from our pharmacy partners, we carefully curated a recommendation algorithm that would suggest nine OTCs based on the medications already in the user’s cart.

In the interest of lean experimentation, we wanted a scrappy technical solution that could be implemented quickly while meeting our high user experience standards and minimizing operational risk. We settled on the following architecture:

We prioritized creating a clean API for Alto’s customer-facing app and using as much of our current infrastructure as possible. Although OTCs are distinct from prescriptions, we decided to reuse our existing prescription model rather than build a new one from scratch. This allowed us to leverage existing systems and operational workflows, reducing engineering time and risk of regression.

Behind the API, we opted to store our OTC formulary and associated metadata in in-memory data structures:

ADVIL = SkuId.new(sku: '...', sku_type: '...').freeze
CLARITIN = SkuId.new(sku: '...', sku_type: '...').freeze
FISH_OIL = SkuId.new(sku: '...', sku_type: '...').freeze
...
METADATA_BY_SKU_ID = {
  ADVIL.hash_code => {
    image_url: '...',
    name: 'Advil Ibuprofen 200mg Coated Tablets',
    quantity_description: '100 tablets',
    product_description: 'Easy to swallow powerful pain reliever for headaches, joint and muscle pain.',
  },
  CLARITIN.hash_code => {
    image_url: '...',
    name: 'Claritin 24 Hour Allergy Tablets',
    quantity_description: '30 tablets',
    product_description: 'Non-drowsy, 24 hour relief of symptoms due to allergies: sneezing, runny nose, itchy and watery eyes.',
  },
  FISH_OIL.hash_code => {
    image_url: '...',
    name: 'Fish Oil 500mg Softgels',
    quantity_description: '130 softgels',
    product_description: 'Dietary supplement with EPA and DHA omega-3 fatty acids to support heart health and maintain normal triglyceride levels.',
  },
  ...
}.freeze

This gave us a nice balance of speed and flexibility. We knew that we could optimize once we had established our OTC offering and gained an understanding of how it would evolve within Alto.

The results of phase 1 were a bit disappointing, but very interesting: the conversion rate of users who checked out with an OTC was just under our target. However, nearly half of all users who saw the experience would scroll down to peruse all nine OTCs that were offered.

Based on this positive sign of engagement, we hypothesized that perhaps we just weren’t showing the right OTC products to the user. For phase 2, we decided to scrap the limited recommendations and allow users to explore an entire catalog of OTCs.

Phase 2 required categorizing our list of OTCs into buckets such as “Top Sellers,” “Covid Care,” and “Allergy & Asthma.” We built a new fetch_categorized endpoint to return our OTC catalog structured by category, adding search functionality into the client so that users could quickly filter for a specific product. This search field was also heavily tracked with analytics events to help us learn which products to add to our catalog in the future.

This new experience immediately outperformed phase 1. After a few performance improvements (speeding up our catalog and product image load times), we eventually hit our target conversion rate — even managing to surpass it on some weeks!

Our eventing did show that a significant number of users with multiple prescriptions or smaller screens were not even seeing the OTCs in Cart, as they were pushed below the fold. We tried experimenting with alternate spots to show our catalog:

1. An interstitial that shows after Cart and before Checkout - this didn’t perform any better than the control and was quickly scrapped.

2. A single carousel at the top of Cart - this out-performed the control but at the cost of our guardrail metric. With a decrease in the overall checkout rate, we decided to stick with the control for now.

This phase of UI experimentation validated that our users wanted an offering of categorized OTCs. However, our initial technical solution wouldn’t scale as we rolled out to more of our pharmacies. The following questions led us to this conclusion.

How might we support changes to our OTC catalog on a per-pharmacy basis?

Given factors such as inventory, geography-related price sensitivities, and experimentation, we wanted to make sure that we could tweak the OTC experience for users getting deliveries from a specific pharmacy.

In the status quo implementation, that would have likely meant adding an additional layer to our data structures like so:

SKUS_BY_PHARMACY_AND_CATEGORY = {
  SF_PHARMACY_ID => [
    AddOnOtcCategoryType::TopSellers => [
      IHEALTH,
      FLONASE,
      ASPIRIN,
      ...
    ],
    ...
  ],
  ...
}

We weren’t worried about memory space limits given our relatively small number of pharmacies and OTC catalog. We were concerned, however, that each modification would require an engineer to go in and make code changes, get PR approval, and wait for a full deploy for the update to go live. This would be a bad use of engineering time, and our CI/CD process would become a bottleneck to otherwise quick modifications.

How might we add and remove OTCs from our catalog?

Similarly, we knew that adding and removing OTCs from our catalog would also be a somewhat regular workflow. There are some other considerations when adding a new OTC (Is it in our product database? Do we need any new procurement/inventory workflows to make sure it gets stocked in our pharmacies? Do we have a nice image to render in the app?), but we wanted to automate the technical side as much as possible — or at least be able to automate it.

The natural next step was to move our OTC catalog into the database.

Alto’s OTC Database Schema. Some columns excluded for brevity.

Now, rather than grabbing from in-memory data structures, we are efficiently querying the database for the OTC catalog of a user’s specific pharmacy, preloading all of the associated models needed for our API response.

OtcCategory
  .includes(otc_category_products: { otc_product: :otc_product_metadata })
  .where(otc_category_products: { pharmacy_id: pharmacy_id })
  .where(otc_product_metadata: { pharmacy_id: pharmacy_id })


At the time of writing, an engineer is still required to go in and make the changes at the database level. However, we plan to build an admin dashboard so that designated pharmacy partners can tweak our OTC catalog without the help of an engineer.

We’re excited about our next iteration, which will allow users to add OTCs to their upcoming deliveries at any point, not only when checking out. It will likely be live by the time you read this.

Once that’s released, we will continue to learn, iterate, and pay down technical debt — more specifically, maturing the OTC data model in our backend and eliminating the need for them masquerade as prescriptions.

Looking even further ahead, the innovation team has more exciting and impactful projects on our roadmap. We can’t wait to share what’s in store!

When Jake Moffatt says he loves building things, he means it — sometimes literally. A construction project manager turned engineer, Jake has spent the past decade building software at mission-driven organizations. Today, as Engineering Manager of Alto Assistant, he leads the team that’s bringing wizard-like support to Alto’s customer-facing app.

Get to know Jake Moffatt, Engineering Manager on the Alto Assistant Team

When Jake Moffatt says he loves building things, he means it — sometimes literally. A construction project manager turned engineer, Jake has spent the past decade building software at mission-driven organizations. Today, as Engineering Manager of Alto Assistant, he leads the team that’s bringing wizard-like support to Alto’s customer-facing app.
Below, Jake chats with fellow engineering manager Mike Riess and recruiter Braden Hanlon about the work ahead for Alto Assistant.

I’d love to learn more about your background to get us started. How did you end up in software engineering?

When I was twelve, I started learning to code in QBASIC because I wanted to make video games. Once I wrote my first program, I was hooked! I loved computers and the creative power they gave to anyone willing to invest the time and energy to learn. Since then, I’ve built games, personal tools and projects, desktop software, and a number of apps and services — I love building things. My career has gone back and forth between construction and software engineering, but it’s been firmly in the software industry for the last ten years or so.

My favorite place to be in a company is working on something new that has a big impact or addresses an important problem. In a previous role, I built an app that helped people find roommates in a city where housing is prohibitively expensive. At that same company, I led the team responsible for creating a new vertical that eventually split off into its own company.

The goal of Alto Assistant is to help customers help themselves before reaching out to support. Our first project is introducing a wizard-like support “assistant” (hence the team name!) that guides the customer through a series of questions to narrow down the area of support. We’ve already identified a few tasks the assistant can help customers complete on their own, including making changes to upcoming deliveries or scheduling new orders.

In cases where we can’t help them just yet, our new tool generates data to help us to learn exactly what customers need help with. It’s a top priority to bake analytics into every new feature we build; even though we have years of experience supporting our customers — and we know intuitively which problems they frequently experience — we don’t have conclusive data to draw upon just yet.

We plan to start with a couple of frequent use cases and measure how often customers reach out to us for support. Then, we’ll chip away at the problem until we’ve seen a substantial improvement in the user experience. From there, we’ll move on to the next biggest problem and repeat the cycle. There’s a reason “Chip away it” is an Alto value: It’s the playbook that we’ve used to automate other critical parts of the pharmacy value stream like intake, billing, and fulfillment.

What opportunities are you most excited about?

Support drives much of the cost of every shipment today, so this is a high-impact area for our business. A year from now, it would be a stellar outcome if the Assistant team could reduce the number of issues that customers need support on by half.

We’re also thinking about the user experience beyond the app. We plan to improve the tooling that our care specialists use to provide support as well. We’ve already discussed some promising ideas like creating the concept of a conversation in support communications rather than an infinite stream of messages and building out enriched communications. We also intend to develop a custom tool that can expedite a customer’s prescription when they need their medication ASAP.

The possibilities are many, and it will take a team of determined, passionate, empathetic people to solve these challenging problems. I’m super excited to see what the Assistant team will do together.

Any lessons learned from previous experience that you’re applying to your role at Alto?

There’s always the temptation to tackle everything at once with new business initiatives. My experience leading new verticals at Apartment List and Snapdocs taught me the importance of being laser-focused on one or two key metrics instead of trying to build out a fully-realized product from the beginning. That’s exactly what we’re doing on the Alto Assistant Team with our clear focus on reducing communications per shipment — how often customers reach out for help because they could not find what they needed in our app.

It’s also important to recognize that we won’t have all the answers right out of the gate! I like to think of product development as a three-step sequence: learning, growth, and maintenance. Alto Assistant is so young that we’re very much still in the learning phase. We maintain a tight iteration loop with everything we ship: launch, measure the impact, and use the results to iterate and refine our hypotheses about what our users want. Our final product could be anything from a customer support wizard to an AI chatbot to a ticketing system — we have to rely on our key metric of communications per shipment, experimentation, and user feedback to shape the direction.

What got you excited to join Alto? What would you pass on to an engineer thinking about applying to the company?

I was impressed by the Altoids I met during the interview process. I knew I would be working with people from whom I could learn a lot, like Elnaz, who started as an individual contributor and went on to become Director of Engineering and, now, Alto’s first Head of Strategy & Operations. I was also impressed by the quality of the interview process itself — a good sign that the company was well-organized internally. Finally, the pitch for the role was extremely clear, with already-established key metrics that would directly contribute to the company’s bottom line and help Alto become more profitable.

For engineers, I think Alto is a great place for both technical challenges and career growth. We’re still small enough that every individual gets exposure to a broad portfolio of high-impact projects. It’s also a great environment for learning about how a business works — the Product & Technology organization does a great job of sharing information and presenting problems in a way that gets to the root business problem we’re trying to solve. There’s a clear line between any project a team is working on and a foundational business metric. Most importantly, we’re a company that makes a truly positive impact on our users’ lives.

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

Receiving feedback from your manager or coworkers can be scary. Giving them feedback can be even scarier. It’s why many companies lack a culture of regular feedback and rely instead on a stress-inducing biannual performance review cycle.

How We’re Making It Easier (and More Fun!) to Give Teammates Feedback

One of Alto’s company values is “communicate with candor.” To make sure we live by this value, we recently set out to make peer feedback more frequent, honest, and fun. Here’s how it went.

Earlier this year, Alto’s patient care team hosted its first Speedback session, inspired by a Thoughtworks idea of the same name.

Set aside a dedicated hour for team members to give feedback to one another.

Group participants into pairs and have multiple rounds. Each round lasts four minutes, giving both participants two minutes to speak.

Change pairs after each round, ensuring that each participant meets once with every other. 

Each round begins with highlighting what the feedback recipient is excelling at, then noting opportunities for improvement.

By creating a fun format for discussions and encouraging constructive criticism, we hoped to take the fear out of feedback and give every participant valuable and actionable insights.

Because Speedback rounds are, well, speedy, it was important that the team came prepared.

A week before the session, every team member identified specific areas they wanted to improve in, from communicating more effectively to keeping coworkers motivated. These were then posted in Lattice, an HR tool we use at Alto, for everyone else to see.

Over the next week, team members reviewed one another’s feedback requests and brainstormed suggestions to share on Speedback day. If a team member wanted tips for writing cleaner code, other Speedback participants could look through past code review sessions for examples.

Since Alto is a remote-first company, the team also had to plan for a virtual Speedback session. We used Zoom breakout rooms, which include helpful features such as countdown timers for the rounds.

After some initial finicking with Zoom, the team quickly got into a groove. Each participant received valuable feedback from every other, which they used to grow over the next few months.

Feedback was also cross-functional. Engineers received feedback from product managers, and product managers received feedback from engineers. Managers received feedback from their reports and vice versa.

“With the feedback I received, I realized that each person responds best to slightly different communication styles,” says Patient Care Engineering Manager Nick Helvig. “It’s helped me better understand and collaborate with the entire team.”

The team’s first Speedback session occurred two months before Alto’s annual performance review cycle. This gave participants valuable information to use for improvement, as well as documentation of their strengths, weaknesses, and growth.

As one team member put it, “What I appreciate most about Speedback is the opportunity to get super clear on where both you and your teammates are looking to improve. It’s also a great way to track your progress and see how far you’ve come in the past two months, the past year.”

Patient Care has since made Speedback a ritual every two months.

To make sure there is useful follow-up to prior feedback, the team has adjusted the timing of rounds from four minutes to six. The first two minutes are now dedicated to revisiting items from the last session, allowing participants to reflect on their progress as well as remaining opportunities for improvement.

Curious to give Speedback a try? Start by putting three blocks of time on your team’s calendar: the Speedback session, a reminder to request feedback for yourself, and a reminder to prepare feedback for others.

Ultimately, Speedback does a lot more than make feedback less scary — it integrates regular, honest discussions into a company’s culture. We hope you’ll find it as helpful as we have!

Redux is great for managing client state: it allows data to be synchronized across the whole app, reduces prop drilling, and makes it easier to understand when state changes occur.

Server state is a different story. Sure, it’s nice to have data available everywhere in our app, which is why we tend to fetch data from the server and dump it into our Redux store. But because our client application doesn't own that server data, it’s hard to know when it has become stale. And what if multiple components trigger calls to fetch the same data? How do you dedupe requests? How do you decide when to refetch?

Why We Switched to React Query for Managing Server State

Redux is great for managing client state: it allows data to be synchronized across the whole app, reduces prop drilling, and makes it easier to understand when state changes occur.

Server state is a different story. Sure, it’s nice to have data available everywhere in our app, which is why we tend to fetch data from the server and dump it into our Redux store. But because our client application doesn't own that server data, it’s hard to know when it has become stale. And what if multiple components trigger calls to fetch the same data? How do you dedupe requests? How do you decide when to refetch?

Below, we’ll dive into how we’re using React Query at Alto to solve these problems and achieve separation of client and server state.

The Old Way: Fetch Server Data and Store It in State

Historically, we would fetch data and set the response in our React component state.

fetchUser(params) {
 this.setState({ isLoading: true });
 
 return getUser(params)
   .then(({ data }) => {
     this.setState({
       isLoading: false,
       user: data.user,
     });
   })
   .catch(() => {
     toaster.toast({ title: 'Something went wrong...' });
     this.setState({ isLoading: false });
   });
}

To make that data accessible from other components, we’d set that data in the global Redux store. This works fine, except that you have to manage your own loading state, the logic for when and when not to make the request, updating the store when mutating data on the server, and knowing when data is stale.

The React Query Way: Fetch and Cache Server Data

With React Query, fetching data and using that data is more declarative.

const { data, error, isLoading } = useQuery(
 // This is our Query Key, which is unique per query so that React
 // Query can manage the cache for us.
 ['user', { userId }],
 
 // This is our Query Function that actually does the data fetching.
 // We can use anything we want: built-in fetch, axios, etc.
 fetchUser({ userId }),
 
 // This query will not execute until the userId exists.
 { enabled: !!userId },
);

Here, we define our query for a user with a Query Key and a Query Function. The Query Key is unique per query, so React Query can manage our cache for us, and if any part of the Query Key changes, the query will automatically fetch new data. In this example, if the user ID changes, the query will fetch new data for that specific user and store that data in the cache.

Naming is hard, but caching is harder. React Query gives us caching of server data out of the box with cache invalidation and request deduping. If we use this same query with the same Query Key in another component, it'll check the cache: if the data is already there, React Query will simply return it, avoiding extra network requests!

Additionally, useQuery runs wherever you use it — no more fetching data when a component mounts. You just use the query and display the data when it’s ready. The cherry on top? The query returns status updates by default, so we don’t need to store isLoading in component state all the time.

Three Optimizations We Get With React Query

When we rebuilt Alto Connect, our web app for healthcare providers, we found impactful benefits in using React Query to help us manage server state instead of using Redux. Alto Connect provides instant access to patient and prescription information and enables messaging with the pharmacy. Because healthcare providers need to quickly switch between patients and clinics, caching data is important to provide a delightfully fast experience. Apart from the cache, what other optimizations do we get by using React Query? Below are a few that helped us.

Once we’ve queried for some data, it gets entered into our cache, so we can utilize that cached data when using the same query in a different component or when fetching new data for a stale query in the background.

React Query is configured with aggressive but sane defaults and considers cached data as stale. Stale queries will always query for new data when the following criteria are met:

The query is optionally configured with a refetch interval

The fetching for new data when the browser window or tab is refocused is especially useful because the healthcare providers using Alto Connect often switch between multiple browser tabs. If there’s an update to a task, status, or message while they’re checking a patient’s medical chart, it will be immediately reflected in the UI when they come back to Alto Connect.

We also set a refetch interval for our queries involving messages. In the old app, we used WebSockets to enable real-time messaging. Although it’s possible to integrate WebSockets with React Query, we opted for a polling solution instead. Because our app isn’t a real-time messaging application, and we don’t need messages to show up immediately, we set a refetch interval on our messages query to poll for new messages every 30 seconds.

const { data, error, isLoading } = useQuery(
 ['user', { userId }, 'messages'],
 fetchMessages({ userId }),
 {
   // This query is disabled from automatically running if we don’t have a userId
   enabled: !!userId,
 
   // Refetch every 30 seconds
   refetchInterval: 30000,
 
   // Continue to refetch while the tab/window is in the background
   refetchIntervalInBackground: true,
 },
);

This is where the enabled option, which disables a query when it evaluates to false, is particularly powerful. We can pause polling for messages if we route to another page and we know that we won’t make any unnecessary requests if there isn’t a valid userId. We don’t have to worry about closing any socket connections or manually clearing an interval.

Most web apps have some sort of navigation menu, and if you already measure or understand your user behavior, you can prefetch data before users even navigate to a different page. Custom hooks makes it easy to expose a function to prefetch data:

export const usePrefetchUsers = () => {
 const queryClient = useQueryClient();
 const prefetchUsers = async () => {
   await queryClient.prefetchQuery(
     ['users'],
     fetchUsers,
   );
 };
 
 return { prefetchUsers };
};

We prefetch queries when users mouseover or hover over a navigation item so that when they navigate to the next page, the data is either actively being fetched or is already in the cache waiting.

We’ve been talking a lot about queries, but what about mutating data? Mutations, in contrast to queries, are imperative. While queries run automatically when we use them, we need to fire a mutation method in order to run mutations. And in order for our user experience to feel snappy, we can optimistically update the cache and then invalidate it after successfully executing the mutation. useMutation gives us some nice side-effect handlers to deal with every stage of the mutation lifecycle. Now when the user sends a message, that new message is immediately reflected in the UI and we keep the data in sync by invalidating the cache and refetching the messages.

With Redux, we needed to build out solutions to each challenge of managing server state. React Query, on the other hand, gives us those tools right out of the box. We no longer need to worry about when to invalidate or fetch new data, making the user experience more predictable — and the developer experience more enjoyable.

Traveling with any type of medication requires advanced planning. For those with diabetes, it’s even more imperative to prepare, as there are additional factors to consider like insulin temperature control and TSA screening of diabetes supplies and equipment. Use the suggestions below to make sure you have everything you need to manage your diabetes while away from home.
Consulting your doctor

Traveling With Diabetes: How to Prepare

Traveling with any type of medication requires advanced planning. For those with diabetes, it’s even more imperative to prepare, as there are additional factors to consider like insulin temperature control and TSA screening of diabetes supplies and equipment. Use the suggestions below to make sure you have everything you need to manage your diabetes while away from home.

Schedule an appointment with your diabetes care provider before your trip to make a plan for diabetes management during your travels. Be sure to cover the following:

How will planned activities impact your care needs?

What is the recommended frequency of blood sugar monitoring?

How might changing time zones impact the timing of your insulin dosage? 

Are there any recommended vaccines for your trip?

Keep in mind that eating and physical activity levels can shift during travel — sometimes unexpectedly — so it’s important to prepare for changes in your blood glucose levels.

Travel doesn’t always go as planned, so it’s important to have extra diabetes supplies and medication on hand. A good rule of thumb is to pack twice as many supplies as you think you’ll need and to bring additional paper prescriptions for insulin or other diabetes medications.

If traveling internationally, be mindful that prescription laws vary by country. It’s a good idea to contact the U.S. embassy of the country you’re visiting for more details. Some countries may only allow a 30-day supply for certain medications and/or require you to carry an official prescription or additional information from your doctor with you.

In addition, keep your health insurance card on you throughout the duration of your travels, and review your policy for travel-related details, including whether your destination is included in your provider network.

Here’s a list of potential diabetes medications and supplies to pack. Depending on your diabetes treatment plan, some may not be relevant for you. If you’re unsure what to bring — or how much to bring — ask your diabetes care team.

Enough insulin and syringes for your trip, plus extra

Enough oral medications for your trip, plus extra

Sources of glucose to restore blood glucose levels in the event of low blood sugar, or hypoglycemia, such as over-the-counter glucose tablets (Lift Glucose Chews, TRUEplus® Glucose Tablets, ReliOn™ Glucose Tablets), over-the-counter glucose gel (Dex4® Glucose Gel, Glutose™ 15/Glutose™ 45, Insta-Glucose®), or carbohydrate-rich snacks like dried fruits, trail mix, honey, or granola bars

For a detailed list of diabetes management essentials, read How to Prepare a Diabetes Emergency Kit.

If you are traveling on a longer flight with meal service, contact your airline and ask if it’s possible to request a meal tailored to your dietary needs, with low sugar, fat, and cholesterol values. Be sure to have other food on hand in case there are any issues with your meal.

Make sure others know that you have diabetes. If traveling with others, inform them of what to do in the event of a hypoglycemia emergency. If traveling alone, have a medical ID bracelet or another form of identification that communicates your diabetes diagnosis. You should also carry a list of your current medications and doses and provider contact information.

It’s always best to pack important medications in your carry-on rather than in a checked bag. Since you’ll be bringing additional supplies and medications as a back-up, make sure at least half of them are in your carry-on.

While the U.S. Transportation Security Administration (TSA)’s current limit on liquids, gels, and creams in a carry-on bag is 3.4 ounces (100 milliliters), there are exceptions for diabetes supplies and medications. Give yourself extra time to allow for additional screening of these items. If you use a diabetes device attached to your body, such as an insulin pump or glucose monitor, it will likely require additional screening as well.

Here are some tips that may help you get through security as efficiently as possible.

Inform the TSA officer that you are carrying more than 3.4 ounces of liquid medication before your screening process begins, if applicable.

Consider printing a TSA notification card describing your condition to hand to the TSA officer.

Bring a copy of your prescription(s) with you.

Keep all medications and supplies in their original packaging.

Put your medications and supplies in a separate, clear bag, as they will need to be separated from the rest of your belongings.

If you take insulin, make sure you have what you need to keep it refrigerated. Keep in mind that insulin should not be held at extreme temperatures and storing it in an ice pack can make it unusable. Many people with diabetes use insulated medication bags to hold insulin at an appropriate temperature when traveling.

Read Taking Care of Your Insulin to learn more about safe insulin storage.

It’s important to stay proactive about your diabetes management. There may be times when you have to check your blood sugar even more frequently, for example, if you are more active than usual, and adjust your meal plans accordingly. Keep in mind that hot weather can also impact your body’s insulin use and your blood sugar levels.

Continue to hold insulin at an appropriate temperature during your travels and avoid leaving it in a hot car — including the glove compartment or trunk — or anywhere with direct sunlight. The same applies to other diabetes supplies like your blood sugar monitor and insulin pump.

If you are going on a longer trip, with a full itinerary, try to take it easy for the first few days as your body adjusts. Remember to bring snacks with you on busy days with long activities.

A diabetes pharmacy partner you can rely on

At Alto, we make it as easy as possible to manage your diabetes when traveling. We offer free, same-day delivery of medication and supplies right to your doorstep, and our dedicated diabetes team is here to answer any questions you may have before your trip.

Reach out any time via in-app secure messaging or phone at 1-800-874-5881.

This content is not intended to be a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or another qualified health provider with any questions you may have regarding a medical condition.

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.

Millions of individuals with type 1 and type 2 diabetes need insulin every day to keep their blood sugar levels in a healthy range. In recent decades, it has grown increasingly difficult for many to access this life-saving medication, as insulin prices continue to rise.

Managing the Costs of Insulin

Millions of individuals with type 1 and type 2 diabetes need insulin every day to keep their blood sugar levels in a healthy range. In recent decades, it has grown increasingly difficult for many to access this life-saving medication, as insulin prices continue to rise. Take a look at these recent statistics:

The cost of insulin increased by an average of 14% every year from 2012 to 2018.

In 2017, insulin accounted for 20% of all diabetes-related healthcare spending before rebates and discounts and 6.3% after rebates and discounts.

In a 2018 survey on insulin affordability conducted by the American Diabetes Association, 39% of the respondents reported an increase in their insulin costs between 2017 and 2018.

Rising insulin costs can significantly impact an individual’s ability to manage their health. 27% of those surveyed by the ADA said that insulin prices affected how much of the medication they could buy or use. Missed insulin doses can lead to serious health complications including diabetic ketoacidosis.

While insulin access remains a critical issue for many Americans with diabetes, lawmakers have recognized the urgency of lowering insulin costs. In November 2021, the U.S. House of Representatives passed the Build Back Better Act, which caps out-of-pocket copays for insulin at $35 per month. The legislation has yet to pass in the U.S. Senate, but President Joe Biden recently reaffirmed his commitment to lowering insulin costs — and prescription medication costs more broadly — as part of his domestic agenda.

In the meantime, there are a variety of resources to help you manage the costs of insulin, including patient assistance programs and copay savings cards from insulin manufacturers. Here’s more on eligibility for these programs.

The Lilly Cares® Foundation Patient Assistance Program

The Lilly Cares Foundation Patient Assistance Program provides free insulin and glucagon products for individuals who have Medicare Part D or no health insurance coverage and meet certain income requirements.

Learn more about program terms and conditions and the application process.

The Novo Nordisk® Patient Assistance Program

The Novo Nordisk Patient Assistance Program provides insulin and other diabetes medications at no cost to individuals who have Medicare or no health insurance coverage and whose total household income is at or below 400% of the federal poverty level.

Sanofi Patient Connection provides Sanofi medications including insulin at no cost to individuals whose total household income is at or below 400% of the federal poverty level.

The Lilly Insulin Value Program offers all Lilly insulins at $35 per month to individuals with commercial health insurance or no health insurance coverage. Download the copay card here.

Sanofi offers a copay savings card for those with insurance as well as the Valyou Savings Program for those without insurance, which offers Sanofi insulin at $99 per month. Learn more about Sanofi savings opportunities.

Novo Nordisk offers savings cards that reduce copays for a variety of insulin products. Get more details here.

Your financial well-being is our priority

At Alto, we understand how stressful it can be to navigate insurance coverage benefits and savings opportunities. We prioritize your financial wellness, working with your doctor, your insurance (if applicable), and any third party savings programs that you may qualify for to make your insulin and other medications as affordable as possible. In addition to automatically applying any coupon savings, we’ll connect you with any outside programs that require you to apply directly.

We also offer free, same-day delivery to simplify your diabetes management, and our dedicated diabetes support team is here to answer any questions you may have. Get started or learn more about Alto, reach out any time through in-app secure messaging or by phone at 1-800-874-5881.

With more engineers contributing to Alto’s codebase than ever before, we needed to establish better boundaries: which team owns what? Here’s how we developed a tagging-based solution to code ownership and drove and measured adoption.

How We Established Better Boundaries and Clearer Code Ownership at Alto

Some problems are nice to have. Over the course of 2020 the engineering team at Alto saw explosive growth, expanding from about fifteen to more than seventy individual contributors. Growth at this pace required us to rethink our team structures and priorities more than once. This growth felt amazing: the new capacity enabled us to make progress on our backlogs like never before.

But still, there were challenges. We saw a steady rise in merge conflicts as more people contributed to the same code base. Build times increased as more and more code was contributed. A big influx of new perspectives and talent also meant new gaps in historical context and responsibility. New teams took big bites out of their new priorities — great! But what about the old ones? Who was going to fix that bug? Who needs to review this PR? Who is accountable for this performance problem?

Who, in short, owned what? By the end of 2020, it was clear to us that a good, practical, working answer to this question would be the critical first step to continuing smooth, rapid, distributed iteration on our product.

Up to this point, the large majority of product development at Alto had happened in the context of a Ruby on Rails monolith, which — over a half decade of intense development — had grown pretty large. We’d stuck more or less to the default Rails convention of organizing code by function rather than feature, which meant that our code was distributed across a few mostly flat and very broad subdirectories such as '/models' and '/controllers', making it difficult to learn much about the structure and ownership of our business domains by merely looking at how the code was laid out. We knew that this was not going to work for us over the long term.

Our long term vision started to coalesce around a notion of “better boundaries.” First, we would modularize the monolith along the lines suggested by Shopify’s packwerk utility. Then, we would carve some of those modules out into separate engines that could be built and tested separately. Finally, we’d deploy and operate some of those engines independently as their own services. Clear ownership was fundamental to this plan: on either side of an effective boundary, you need to know not just what it is but also who owns it. We lacked that clarity.

Blog

National Pharmacists Month Spotlight: Roni Hein

Meet the Innovation Team Building Alto's Next Big Bets

Get to know Jake Moffatt, Engineering Manager on the Alto Assistant Team

How We’re Making It Easier (and More Fun!) to Give Teammates Feedback

Why We Switched to React Query for Managing Server State

Traveling With Diabetes: How to Prepare

Managing the Costs of Insulin

How We Established Better Boundaries and Clearer Code Ownership at Alto

How We Used Kafka to Build an Event-Driven Automation Pipeline and Scale Our Pharmacy

Developing Robust Authentication Using Rails, Omniauth, and Okta

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

Celebrating National ERG Day at Alto

Switch to a better pharmacy.