Key Points

• Created a multiplatform app for a real-world group of volunteer organizations
• Negotiated project requirements with multiple conflicting stakeholders
• Contributed to research, site architecture, visual design, and front-end development
• Gained important experience in communication, software development, and B2B-SaaS operations

Intro & Overview

AxoLift is a multiplatform app produced by my team as part of our Senior Development Capstone Project. The objective of the class was to produce a fully-featured app based on the requirements of a real-world client group, which would then be deployed and used in the real world if selected. The clients were a group of volunteer organizations around Rochester who provide suburban transportation and rideshare services to the elderly population.

Throughout this year-long course sequence I helped negotiate a common set of requirements with multiple client orgs that often had different ways of doing things, conducted design research and ideated on a visual look-and-feel that defined the app’s personality, created task flow diagrams, helped produce prototypes of multiple fidelity levels, lead presentations to share our progress with the clients, and contributed significantly to the app’s front-end development.

In the end our app was not selected by the clients for real-world use, but the project still offered a wealth of lessons and experience in teamwork, communication, new software tools I wasn’t familiar with before, and end-to-end experience in a SaaS-like development flow.

Initial Research & Project Requirements

Before the project began, our team had a number of preconceived notions about what kind of app the client group would want. We had been briefed by our professor that we were making an app for volunteer senior transportation groups; we immediately assumed it would take the form of something like Uber or Lyft. We were immediately proven wrong.

We learned quite quickly that they did not want their riders to have to use our app in any way, instead opting for phone calls to schedule rides. The reason was that phone calls represented an important social connection for seniors in a way that I hadn’t considered as a young person. There is an element of human connection in a phone call, with idle chit-chat and small-talk, that isn’t there in an impersonal touch interface. I believe that this sort of empathetic thinking was important in creating a more effective interface for the actual user group, as opposed to one that I personally would use.

Throughout the first semester our group negotiated with the client group about design requirements. The different volunteer orgs had very different workflows, and criteria that often conflicted. The process of hammering out the details and gaining consensus was slow and sometimes frustrating, but it was an important experience in negotiating between different stakeholders in a productive manner.

Design & Prototyping

I did a lot of work on the design and prototyping of the app during the first leg of the project. As a means of getting proximate to the user group and centering empathy in our design thinking, I created personas for the different user roles the app would feature. Once we had our requirements locked in with the clients, I created task flow diagrams based on those requirements, and assisted another group member in creating a sitemap based on those task flows.

After planning the architecture of the UI, I assisted in creating the actual layout of the screens and interfaces with another group member. There was a large volume of screens, widgets, pop-ups and drop-downs compared to any class project I had done before, so we had to split up the different screens and states between multiple group members and coordinate to ensure they all shared the design language.

We presented multiple iterations of the site prototype to the clients for feedback, from a lo-fi wireframe with grey boxes and placeholders to a fully clickable Figma prototype for testing interactions. Each time, client feedback was taken into account for the next iteration.

Development & Deployment

We began development of the actual app in fall of 2025. This was the most challenging part of the project, the short timeline meant we were very busy at almost all times. We onboarded a new group member partway through, the backend architecture changed drastically during development in a way that put a lot of pressure on the team. It was stressful, but I also consider it to be an important experience that I learned a lot of lessons from.

Final deployment went well, and we were able to demo the app’s functionality live to the clients during our final presentation. Our app wasn’t selected for further use, but the project as a whole was a success and the experience I gained was invaluable.