eBay Stores Platform Migration

Setting the stage

This is a blog post that follows up on my writing about migrating eBay’s Top Level Category Pages.

The tl;dr is that eBay was moving to unify all the ways a user could browse inventory on the site into a consistent shopping experience.  The way to do this was put all the different “browsable” experiences onto one platform, which internally was called Lexington. My post linked above dives into the reasons for moving these different experiences onto Lexington and the business value that would come from this.  My original post linked above details one of my projects which was to migrate top level category pages to Lexington and what I learned from that experience. While I was executing on that project I simultaneously was tasked with migrating eBay Stores to Lexington.

What are eBay Stores?

eBay Stores were pages that featured a seller’s inventory. A seller can pay eBay a monthly fee for this type of page that in theory would get them more traffic.  A seller technically will have a Seller Profile page that will feature his or her inventory, but an eBay Store was supposed to be an elevated version of this experience.

The value add for a seller to pay for an eBay Store was to get more traffic through SEO, to get more traffic through organic promotion throughout eBay’s site, to have cheaper listing fees, and to have a way to represent his or her brand.  More information can be found on eBay’s information page: Why Get an eBay Store.


There were 3 target customers for eBay Stores:

  1. The buyer browsing on eBay

  2. Sellers that were paying an additional fee to have a storefront

  3. eBay’s SEO (Search Engine Optimization) Presence

Customer problems

As the end user browsing eBay:

  • I need to be able to find relevant inventory that I want to browse from this seller

  • I need to be able to find a seller whose inventory I want to browse

  • I should be able to access an eBay Store on all devices

  • I need to understand what an eBay Store is and the value it provides

As an eBay Seller:

  • I need buyers to be able to navigate my inventory properly

  • I need to be able to represent my brand on eBay

  • I need to be able to showcase any promotions/coupons that I am offering through eBay

  • I need to have shoppers find and discover my eBay Store

As eBay’s SEO Presence:

  • I need links into eBay Stores to maintain and build SEO visibility

  • I need eBay Stores to use the correct links to listings and other eBay pages

  • I need eBay Stores URLs to follow SEO best practices


There were a TON of hurdles in order to do this project.  

Multiple owners

The first major hurdle was that eBay Stores were not just a storefront or page for buyers to browse, it also was an entire Content Management System (CMS) within eBay’s Selling platform.  

This meant that this single product was owned partially by eBay’s Buyer Experience and partially by eBay’s Seller Experience.  This meant a lot of negotiation and alignment on timelines which ultimately has led to this product’s inability to move forward. (I will detail this more later in the post.)

Incomplete migrations

The second hurdle for this project was that there had been a previous project to migrate eBay Stores to an updated codebase and platform, and it was not completed due to shifting priorities.  This left eBay Stores buyer experience on 3 platforms:

  1. An archaic version from the mid 2000s (referred to as Legacy Stores)

  2. A version from the mid 2000s that allowed custom HTML/CSS/JavaScript on the storefront (referred to as Custom Stores)

  3. The 80% complete version from the early 2010s (referred to as NextGen Stores)

It also left the eBay Stores Seller Experience on 2 platforms:

  1. An archaic version from the mid 2000s that powered the Legacy Stores and Custom Stores (referred to as Legacy Stores tool)

  2. The 80% complete version from the early 2010s that powered the NextGen Stores (referred to as NextGen Stores tool)

This migration had to take into account 3 storefronts and 2 CMS’s and build a solution that could move all of them into a single storefront and a single CMS.

Lack of resources

When I originally took this project, I was supposed to have 7 engineers working on this for the storefront, and the seller tools were supposed to have a dedicated product manager and 5 engineers working on it.

Due to attrition, my team shrank to 4 engineers.

Additionally, due to priority shifts from the Seller Experience team, stores tools were down to 1 engineer and 0 product managers.

A project that was scoped to take an entire year with 12 engineers and 2 PMs shrank to 5 engineers and 1 PM.  This is largely attributed to organizational dysfunction discussed below.

Organizational dysfunction

For some context, when eBay does planning, they come up with timelines to do a project based on how many engineers are needed and how long it will take them. The projects are then “funded” with a funny-money that is internally referred to as “product developer (PD) months” or “engineering heads”.

In order to get projects done at eBay, you must be “funded” with enough engineering heads and time to do the project.  For eBay Stores to see meaningful progress, it meant that both the Buyer Experience and Seller Experience teams had to commit enough PD months to their respective pieces of the product.  Neither side could make meaningful progress without the other.

The year that I took this project, both organizations had committed the proper resources to get this done...until a month into the year, the Seller Experience team shuffled priorities and “delayed” its headcount into the project until later in the year (and the date kept rolling later and later).  The engineers allocated for the project were also folks that were to be hired, so that did not account for not only making a hire, but also getting the engineer on-boarded.

(Ultimately, the Seller Experience team never got the resources to hold its end of the bargain.)

Aside from the Seller Experience team removing resources from the project, the Buyer Experience team lost 2 months from its own organizational dysfunction.  For a total of 3 months of the year, the leads of the eBay Stores team and 2 other partner teams (the Browse team and the Events team) met regularly for architecture discussions, and at the end of 2 months, leadership blew up the architecture plans and proposed a new one, which meant 2 months of wasted time.

The Plan

Despite the hurdles ahead, the team and I moved forward with the goal of delivering the best possible product for our users. We went through several prioritization exercises to figure out how we could deliver meaningful results with fewer resources and less time.

We had a north star for what we wanted to deliver for the experience.  We compromised several times and settled on delivering a 1:1 feature parity with the latest NextGen Stores with some fixes that addressed top customer pain points collected from customer support.  We did this because with limited Seller Experience resources, we could only access data that already existed in the selling experience services because we did not have support to build out the service support for additional features.  The goal was that when Seller Experience eventually staffed-up, we would achieve our north-star.

The slimmed-down migration plan aimed to build feature parity from eBay Stores NextGen, address SEO problems with linking, fix top seller-reported issues, and finally release the previously desktop-only product onto mobile web and eBay's native applications.

What happened

As the year progressed and the team worked, ultimately our progress to deliver this new version of Stores was very slow.  There were a number of reasons for this aside from the hurdles described above.

One of these reasons is the team lost both its lead engineer and its engineering manager early in the project. This left a gap in leadership.

Another reason progress was slow is because normally as the product manager, I would have stepped in to fill some of the leadership void; however, I recognize in retrospect that I was spread too thin across 3 projects and 3 engineering teams, so I was not able to dive in and dedicate the attention needed to one particular team and project because I was constantly having to bounce around the 3 teams and projects.

A third reason progress was slow was due to the constant rotation of frontend engineers due to lack of resources. This meant repeatedly ramping an engineer up on the codebase and product, which is time consuming.

Lastly, progress was slow because of several miscommunications internally in the team and externally between partner teams that led to wasted effort and missed requirements. This was a fundamental breakdown for myself, the team, and our partners.

Ultimately at the end of the year, we had a new Storefront that delivered on the plan detailed above with the exception of a native application.  The team was gunning to wrap up progress and deliver the product in time for our annual moratorium for holiday shopping, but as our deadline approached and I took a step back to look at the product we were delivering, I realized that the product was not at the quality that we should deliver for our customers, and I had to make a hard call with the team.

We decided to not launch our product at the end of the year, and wait until the beginning of the next year.  There were many reasons for this that include the following:

First, parts of the UI were a little bit wonky. We were iterating to fix them, but ultimately they needed time, which we lacked due to the impending moratorium.  Launching the product with these UI issues would show a lack of attention to detail and lack of quality for our customers.

Second, a last minute requirement from legal in Europe required eBay Stores to show an Impressum, and there was not a service in place to display this properly. Legacy and Custom storefronts allowed custom HTML from sellers who could manually add this information. This feature miss meant that we would not be able to migrate many Storefronts in the EU.

Lastly, the driving force for this migration was not just addressing the customer problems detailed above, but also to simplify the underlying tech and curation tools.

Some history is needed to explain this problem: Due to the incomplete migration of Legacy and Custom stores to NextGen Stores, sellers would have to switch between the version of stores they were using in order to access certain features. If a seller wanted to adjust their categories or URL, they had to use the Legacy store, but if they wanted to change their photo, they had to use the NextGen store. Ultimately customer support would have to guide sellers in this ass-backwards process of upgrading and downgrading their storefronts in order to access certain features.  

When I took a step back and looked at what we were delivering for sellers, I realized that the product we were about to roll-out actually made the existing problem of working between store tools worse.  Some sellers would be migrated and others wouldn’t. 2 different store tools would access the same storefront, but they could not access all of the features they needed.

In the end, it was a very tough decision, because the team had worked so hard to wrap the product up for an initial launch, but ultimately when I sat everyone down and explained the issues, we all agreed that we needed to delay the launch until we would work these problems out.  

Ultimately, I ended up switching teams (for reasons unrelated to this project’s success) and another PM wrapped up the work and launched the product once it was in a better place.

What I learned

I alluded to many of my learnings throughout this post, but this section will detail them explicitly.

Immovable forces

There were certain immovable forces such as the lack of resources and alignment for the selling experience team that severely limited our ability to execute. These were signs my manager and I saw very early on, but we decided to pursue this project anyways. In retrospect, we probably should have cut bait and reprioritized our own resources into a project where we could deliver more value without being blocked.

I have learned to better assess hurdles ahead of me. For something like what I experienced for eBay Stores (where we had a dependent team that reneged its support and resources and we could not fix this), it would have been a better use of our time and resources to pivot and deliver on something where we were not blocked.  (I leveraged my learning on this for a later project of mine that I will write about in my next post.)

Time commitments

I was extremely excited and passionate to build and work on many products at eBay that had high visibility and a lot of love from customers. I kept asking for more work and more ownership, but I later learned that my eyes were bigger than my stomach.  I had originally asked to have more responsibility than my 1 team and product. I had imagined I would get 2 teams and 2 products, but I was instead given 3 teams and 3 products. I liked each of the teams and products and did not want to give anything up, but by the end of the year I realized that although I touched a lot of pieces of eBay and worked with a lot of great people, I was spread too thin and could not dive in as much as needed.

My previous year when I had 1 team and 1 product, I was able to dive in and help steer the team when there was a lack of leadership and resources.  When I had 3 teams and 3 products, I was not able to dive in and steer when one of my teams was struggling. I detailed this with the eBay Stores team in this post, and one of my other teams also needed more guidance during the year as well.

I learned that although it’s great to do a lot of things and do them well, it’s actually better to do fewer things and excel at them.  It helps me to focus and deliver more value and learnings, and it allows my team(s) to move faster and stronger.

Product quality

I learned the value of spending the right amount of time to ensure a quality product launch.

Delivering a lot of things is great, it’s shiny and easy to talk about, but in the end the number one priority of a product manager is not the number of notches on your belt from product and feature launches.  In fact, the number one priority of a product manager should be the users and delivering the best customer experience.

Product management entails a lot of assessing trade-offs and figuring out the best way to deliver a product in a resource-constrained environment on a time-crunch.  In situations when these barriers and limitations do exist, it is still not worth launching a half-baked product for the sake of saying you did it. A broken product and bad user experience is worse than maintaining something that is not ideal.

Moreover, it takes a lot of time and energy for a product manager to work with the team to deliver quality products. There are design iterations, engineering iterations, data exploration, and much more in order to deliver quality products.  Working on tons of products takes away time and energy from working with any one individual product or team.

Product managers have to find the balance of quality and scale when working on products.  During my time at eBay, I personally could deliver much higher quality with one team and product, but my scale was much lower.  I was also able to deliver much higher scale with three teams and three products, but my quality was sacrificed.

The mix of scale and quality varies between PMs and companies.  I now have a much better idea of my capacity to scale based on my experience with eBay Stores.

Vision and Strategy

The last major learning from this project was the importance of buy-in from leadership for the vision and strategy for a product.  

eBay Stores was a great idea and product when it first launched because the concept of a seller having his or her own page and storefront was unheard of.

In today’s world, Shopify, Wordpress, Etsy, TicTail and countless other competitors offer a seller his or her own storefront.  The value of eBay Stores is diminished when you compare what it was back in the day and what it is today with the onslaught of competitors.

I developed a plan and strategy that aimed to marry the offerings of eBay’s past, eBay’s present, and what competitors offered for similar product offerings into a long-term roadmap for eBay Stores.  In its current format, it could not compete with the likes of Shopify or Wordpress in customizations. Shopify and Wordpress could not compete at an individual level with the scale of eBay’s marketplace (without intense investment in SEO and traffic).

Leadership liked my vision and strategy, but their priority was migrating Stores off of the old software stack so that it would cost less to maintain.  They were not focused on building it into a cutting-edge product offering relative to the numerous competitors on the market.

Since leadership was not invested in my vision and strategy, they were not going to invest as much in funding the number of engineers necessary to achieve this.  For previous projects, I had been able to push my vision and strategy with fewer resources and with less leadership buy-in; however, in this instance, I was not able to.

I have learned to place higher value on getting leadership’s buy-in on the vision and strategy for the product, because when it comes time to make trade-offs in where they invest, they are going to move resources away from projects with less buy-ins and more into projects where there is higher buy-in.  I took this lesson to heart and applied it to my next project that I will write about in my next post.


Large corporations can have a lot of moving pieces that are unbelievably tough to get moving.

My biggest insights from this project were:

  1. Getting a better sense of which projects will deliver value and which are not setup for success

  2. The value of how to focus your time in order to get the most bang for your buck

  3. Learning how to balance scale of deliverables with quality of products

  4. Emphasizing leadership buy-in for a vision and strategy early in the project

Remembering daapr

The week of July 17, 2017, my co-founder Aaron Schifrin and I shut down what was left of the very first startup I worked on, daapr.  Although we stopped working on daapr at the end of 2014, we had kept the site up an running because some of our users still played with the platform, and we also kept it as a memorable portfolio piece.

Daapr was a social media platform exclusively for sharing article and video content with your friends.  The idea behind daapr surrounded focus-based social media platforms; the way that Twitter emphasized statuses, and the way that Instagram focused on mobile uploads, daapr's goal was to showcase article and video content with your friends without the clutter that was associated with Facebook.  Daapr provided a clean, stylish user interface that aimed to promote discovery and engagement with user curated content.


As I took the time to shut down the platform, it gave me pause to sit and reflect on the experience as a whole.

My Role

My time working on daapr spanned across my last 2 years of college at Cornell University.  I was originally recruited to work on daapr as a frontend engineer by two of my friends who were already working on the team.  As the product and company grew, my role rose to Chief Technology Officer and a manager of the company.  I had to grow from a role of simply writing frontend code, to one of defining the product vision with the leadership team, working on growing the size of the team, executing on the product vision, and also managing the members of the engineering, design and marketing teams.

I had to evolve my role in daapr from that of an individual contributor to one as a leader of the company.

My daapr Story - Technological Learnings and Personal Growth

tl;dr This section covers my daapr saga and what led to specific technological learnings I had.  I break out exactly what I learned from this company and experience in the MY LEARNINGS section following this one.

When I joined daapr, I had basic programming knowledge in Object-Oriented Programming with Java, and Web Development in HTML, CSS, PHP and some JavaScript.

The original team built the first version of daapr in PHP using CodeIgniter and Masonry to build the Pinterest-like grid.  We chose PHP partially because we were familiar with the language and did not want to spend time learning a new programming language, but in retrospect it was more because we were nervous to go learn a new programming language that we did not understand.

My first technological learning was getting the first version of daapr to kind-of work.  This was my first project that I had worked on outside of school-based curriculum, and it forced me to expand my understanding of HTML, CSS, and hacking together JavaScript.  Shortly after we had a kind-of working Minimum Viable Product (MVP), the code broke, and my development partner left the company.

From here, Aaron and I had to decide what we were going to do.  We went from our original four partners down to two, and we had a broken product with half the knowledge of it gone. (Simultaneously, I was also very concussed from a soccer injury at this point in time, so I was not firing on all cylinders.)  We decided that despite the situation, we wanted to continue moving forward with our vision.  We went on a hunt on around our college campus to find a backend engineer that was smart enough to build an app outside of a class project, who also happened to be daring enough to work with us.

This led us to Connor Strynkowski, who ultimately helped bring us back on track for building daapr.  Upon further research, I decided to take my second step into growing my technological knowledge, and step outside of my comfort zone with PHP, and move in the direction of building daapr with Ruby on Rails.  The team chose this based on feedback from our peers in the co-working space THE POPSHOP with supporting evidence that the original version of Twitter was also built Rails.

The first attempt at building daapr with Rails went very poorly.  I left Connor to build the backend on his own, and planned on coming together to hook it up to my frontend code that we had used for the PHP version of daapr.  When Connor and I met to piece it all together, I looked at Connor's code and saw that he had written a lot of Ruby, but had not used the Rails framework at all...we had nothing that was usable.

This was when I had my third major technological and leadership learning, and that was that I needed to be knowledgable in every piece of the application we were building.  I did not need to be an expert, but I needed to know enough to make sure that everything worked together properly.  It was at this point that Connor and I embarked on Michael Hartl's Rails Tutorial, which has been the most pivotal learning experience in my education and career thus far.

Simultaneously with development, Aaron had applied the team for Cornell's eLab program to help the company grow its business acumen and give it credibility.  During the fall of 2013, the daapr team attended an additional weekly class sponsored by eLab on how to grow one's company.  We spent the weekends doing customer discovery interviews in random spots on Cornell's campus to better understand potential users that we wanted on the platform.

In December of 2013, Connor and I finished building the second version of daapr, and we launched the first alpha of daapr built on Ruby on Rails (hosted on Heroku).  During our winter break, Aaron, Connor and I signed users up for the alpha and started gathering feedback on the experience.  Now that we finally had a working product, many students on campus were very interested in joining the team.  We went from not being able to recruit anyone, to having too many people that were interested in the company.  We ended up expanding the team to include more engineers and a business development team to help with marketing and user reach out.

As the team grew, my role grew.  I conducted the interviews for the engineering team, and would train them on the technology stack and product.  Aaron would train and manage the marketing team.

Through 2014, more people joined the company, our user base grew, and the product continued to develop.  We originally launched with only being able to add posts, view posts, follow users, and view profiles.  Through 2014, we expanded to add discovering users to follow, liking posts, resharing a post (sharing another user's post on your profile while giving credit to the original user), commenting on posts, and notifications.  Daapr was built from the ground up with responsive design in mind for an optimal experience on all devices, but we did not start developing native mobile apps until 2015.

During 2014, I was splitting my time between managing our Heroku deployment, building the frontend code, helping debug the backend code with Connor, on-boarding our new engineers, and still managing school and internship interviews.  Towards the end of the 2014 school year, we were fortunate to add Anton Gilgur to the team, which allowed me to focus more on the leadership aspect and allow Anton to take over frontend development.  Anton worked to overhaul the frontend code that I had written to run faster, and expand upon the initial React.js components that I built to have the whole site built on React. This allowed for transferring state between components and a more uniform architecture. (React was very new when I wrote the initial components, and Anton wrote daapr entirely in React was before even Facebook used it for their site.)

Aside from Anton and Connor, the team had other engineers who I was working on training in order to contribute at the same rate as Anton and Connor, but for the most part they were working on smaller pieces until they had ramped up on the necessary skillsets.  Meanwhile Aaron was managing two teammates working on business development, which encapsulated customer reach-out, in-person marketing, and email marketing.

During the summer of 2014, the team went to different destinations for internships, which forced us to work and meet remotely.  The platform was costing us too much money to run on Heroku at scale, so this led to my fourth major technical learning.  I spent the summer learning how to deploy Ruby on Rails applications in a scalable architecture on Amazon Web Services (AWS), which by no means was a trivial feat, because despite AWS's prevalence, their documentation (especially for beginners) was lackluster at best.  This led to me writing my own guide for deploying Ruby on Rails applications in a scalable infrastructure on AWS.  It is titled Deploying a Ruby on Rails Application with Amazon Web Services OpsWorks The Idiot’s Guide to Migrating a full stack Rails Application from Heroku to AWS: A Guide made by an Idiot, for Idiots.  That summer was a test of fortitude for myself and the team.  I had to keep pressing on after repeat failures deploying daapr to AWS successfully.  The team also had to learn to self-motivate in order to continue working and meeting while remote.  This period of time ultimately showed who on the team would put in the time and energy to get things done.

As development expanded from 2 people to 3+, I started to understand the importance of writing requirements for oneself and for partners in order to ensure that everyone understands what needs to be built, and to ensure that everyone works on the correct tasks.  The team encountered significant growing pains on this; the engineers would casually chat about what each person would build and the service-level contract, but without an organized planning session and written requirements, individuals would frequently come together having different deliverables than what was expected.  After my summer internship, I started running sprint planning and adopting elements of Agile Development for daapr to help cut down on the wasted time from miscommunication on deliverables.

Development on daapr continued, and customer outreach grew.  Over 20 people worked on daapr throughout its lifespan.  Aaron did pitch competitions that gained us recognition and small amounts of cash, while the marketing team did fraternity and sorority outreach on Cornell's campus and started a campus ambassador program that spanned across the country.

Ultimately, growth and engagement hit a stall.  Aaron and I realized that we had made a fatal mistake.  Our original idea was that users would want to browse daapr on their laptop while they were at the library taking a break from studying; however, while we were interviewing and pitching users post-launch, we learned that everyone wanted a native app on their phone.  Although the site was completely responsive and worked remarkably well in one's mobile browser, native app usage for social media was skyrocketing, and our users wanted to browse daapr while they were bored on-the-go (like on the bus, or eating food at the dining hall).

In a last-ditch effort to restart daapr's growth, we hired an iOS engineer who went to Cornell to build out a native app for daapr.  Development continued and customer outreach persisted, but at the 2-year mark, Aaron and I started to burn out.  Managing the product and team was taxing.  We also had our personal lives, school, and job hunting.  

Moreover, Facebook had become the dominant player in news, videos, and media around the 2-year mark of daapr (2015).  Previously, Facebook had been predominantly filled with statuses, photos, and social games, with some links, but there had not been a focus on media in the content or user experience. As daapr was getting started, we could see that Facebook was making changes to place focus on the news, video and media content, but we figured that Facebook's users would never see it as a source for that type of content; we were very wrong on this notion.

Ultimately, after 2.5 years or working on daapr, user growth was declining, engagement dropping, and the team and leadership were frustrated and exhausted.  Aaron and I decided that it was time to call it quits, and stop working on daapr.  Unfortunately, we never ended up launching the native iOS app.

The company folded amicably.  Everyone understood that the product was not progressing the way that it needed to in order to prove itself as a viable full-time job, and there were no hard feelings.  It was a sad ending, but everyone felt like they were ready to move onto something new.

My Learnings

I learned a ton from daapr, arguably more than any of my college courses.

I learned:

  1. How to be a leader for a team
  2. How to manage people
  3. How to build a product from scratch
  4. How to make product-oriented decisions and prioritize features, tasks, and risks for the product and the company
  5. About customer discovery
  6. How to form customer problems and go after them
  7. A lot of new technical skills that made me extremely more qualified for the workforce than I had been before working on daapr
  8. How to develop technical architecture
  9. How to have partners and how to balance differing visions, goals, and priorities in order to form them into a coherent team vision, set of goals, and set of priorities
  10. How to pitch an idea and sell the vision to friends, family and complete strangers
  11. How to speak confidently and authoritatively on a subject

Although daapr ultimately did not turn into a wildly successful hit, I had so many invaluable learnings that it was totally worth the time and energy.

My overall conceptual learnings:

  1. Every technical product has to be thought of from a mobile-first perspective.  Mobile usage is continually increasing, and desktop usage is on the decline.  Building without prioritizing mobile first is an extremely costly mistake.  A mobile app may not have made daapr a wild success, but it would have taken the company further and made it more popular.
  2. Really understand the customer problem that you are trying to solve.  If we had understood our users better earlier on, we might have seen the need to develop a native application earlier.
  3. Keep the team small.  The largest the team was at any given point in time was 14 people (over 20 worked on it throughout, but some folks came and left).  It was fun to say that we had such a large team; however, when I look back, my time would have been better spent focusing on the product and a few highly productive teammates.  What ended up happening was that my time was spread thin managing people that were not putting forth the same contributions that I could have made if I was doing my own work on the product.  Everyone who worked on daapr was great, and I loved every minute I spent working with the team, but ultimately when the company is young and the product needs significant work, time spent on a large team can be costly.
  4. Know every part of the product.  I originally tried to stick to what I was comfortable with, which was the frontend code.  I learned the hard way that I had to have knowledge on the full stack.  This helps with managing the team, auditing progress, and overall being a successful and knowledgable contributor.   I did not need to be an expert in each aspect of the product, but I needed to know each part proficiently.
  5. Hands down, the most important thing that I learned from daapr, is that it's OK to not know what the hell you are doing.  As long as you are determined, just go after it; plunge into the problem that you are trying to solve, and figure it out.

The Product

The Infrastructure

The Memories

Thanks to everyone involved.  Below is a list of folks that I worked directly with at Cornell, but the people involved extends past these names below (listed in no particular order):

Aaron Schifirn, Connor Strynkowski, Anton Gilgur, Austin Gage, Nicole Hamilton, David Wiesenfeld, Peter Simon, Alice Meng, Maggie Yunjie Bi, Sean McNeil, Hong Jeon, Kevin Chen, Gwen Petro, Brendan Miller, Eric Appel, Tyler Nebel, Mateo Acebedo, Jesús Tacho Elizondo