Our survey shows many New Yorkers are open to or already pick up free items off sidewalks when passing by. These individuals indicated upcycling goods would be a more common occurrence if it was convenient to do so.

FreeUp aims to enable this behaviour by streamlining: 1) the process of finding goods; 2) decisions surrounding a good’s condition; and 3) logistics to acquire goods. Individuals indicated this would help them save money for various reasons and tap into the resell markets more efficiently.

If these goods are otherwise left as is, they will end up contributing to the 12,000 tons of waste NYC produces every day, most of which will be dumped in a landfill or burned and recycled into a lower quality product.

By using FreeUp, New Yorkers will be able to upcycle goods to reduce landfill trash and slowly convince more individuals to make changes that will lead to positive environmental changes.

‍

Research Insights & User Pain Points

Our preliminary user survey to validate this problem of enabling New Yorkers to upcycle used goods found that individuals would be more inclined to take items from sidewalks if they have access to relevant information. T

his stems from a lack of advertising when goods are available with key information on the location and condition of goods. There was also a need for a means to ensure goods would be available for when users can make the time to pick them up.

After completing over 5 user interviews, we found that a website is a meaningful way for users to conveniently upcycle used goods.

In addition to addressing the pain points above, the website should allow users to access and explore all available goods and even add any items they would like to give away.

‍

Solution Explanation

Based on our target users’ pain points as well as market research, we knew we wanted to work on the following features: location proximity, discoverability with filtering and categories, communication through a chat system, safety and urgency by visually highlighting the availability of an item.

‍

Lofi & Hifi Mockups

‍

Iterative Design Learnings

After synthesising the usability testing results we found some common insights with users. We learned that the filtering option needed to be more detailed with the addition of having categories and pickup type enabled.

To meet those needs the filtering was updated as well as more functional with a reset button added. Users also cited that the review stars highlighted next to a poster's name didn’t give enough context on what that meant.

To keep in line with the issue of trust and safety member information highlighting their membership date was implemented while taking off the star rating icons.

‍

Implementation Details

Technical implementation

FreeUp is a web application, built on the PERN stack. The backend is hosted on Heroku and the frontend is hosted on Netlify.

We utilised Node.js and Express as a backend server and PostgreSQL as our database. Additionally, we used Knex.js to simplify schema design and seed the database with data to test with. Our frontend is powered by React along with the Material UI library for components.

We were proud to have accomplished many features in our current iteration of the application. Currently, users can: create new accounts and log in, create a listing, view all listings, view specific listing details, comment on a listing, and message another user.

Technical Tradeoffs

Both developers had more experience building web applications even though this idea may be better suited as a mobile app.
Using Sass and Mui to try and style components and not always being able to match up exactly to the Figma design mock-ups.
Deciding which database (SQL/noSQL) would be better suited for FreeUp. A noSQL database could help store larger images and could result in faster lookup from our database. FreeUp relies heavily on user information therefore we needed to make sure data was fully secure. A relational database allows us to encrypt data, limit access with authorization and prevent against other types of malicious behaviour. Due to the amount of sensitive data in FreeUp we prioritised maintaining accurate records and protecting sensitive information, therefore we went with PostgreSQL as our (Relational/SQL) database.

What was the hardest part of development?

Gauging how long tasks would take to complete, some tasks would be easier than expected and others would take much longer.

Key Takeaways

Communicate often on what tasks and components you are working on to avoid merge conflicts.
Code doesn’t have to look perfect in the initial attempts, you can always good back, refactor, and build upon your progress.
Two sets of eyes are better than one when it comes to debugging and solving issues.

‍

Future Steps

We will be continuing the project to iterate upon our MVP and grow FreeUp into a more advanced product. We will continue to clean and polish the website while also implementing more user stories (i.e. user credibility, map features, creating a mobile app, etc.). We hope our product will be able to partner with thrift stores, non-profits, scrappers, and other organisations to further increase upcycling/resell movements in NYC.

Learnings

Product Manager Learnings:

Rishi Shah

Attentive listening: Instead of engaging in conversation for the sake of participating, I decided to listen carefully and understand what my teammates were trying to communicate to better empathise with them. This allowed for meaningful conversations and ultimately a better product.
Prioritisation and negotiation: Whilst talking with my teammates, asking more questions to cover all aspects of a problem helps paint the bigger picture and ultimately decide on which features to build and how to prioritise them in the best order.
Test early and often: User feedback is priceless! They can point out bugs we are already aware of, but also provide ideas we never even thought about. Getting their constant input ensures the product will be meaningful.

Designer Learnings:

Lavina Green

Collaboration: It is very crucial building in a collaborative team environment when trying to achieve a common goal.
Communication: Different perspectives and knowledge is crucial to crafting design solutions. Reaching out for input and critique has helped me see things in a different perspective.

Designer Learnings:

Jo Sturdivant

Adapting to an Established Team: Joining the team in week 6 of 8 was challenging, as I had to quickly adapt to existing workflows, dynamics, and goals. This mirrors real-world situations where you often integrate into teams mid-project, and flexibility is essential.
Work-Blocking for Efficiency: With only two weeks to complete the project, I learned the importance of a structured work-blocking system. This approach allowed me to manage my time effectively and meet deadlines under pressure.
Making Data-Driven Design Decisions: Unlike my past projects, I had to rely on research conducted by others. This was a valuable experience in using pre-existing data to guide design decisions, helping me focus on the core insights without starting from scratch.

Developer Learnings:

Jacob Nathanson

Functional vs pixel perfect: It is better to focus on functional aspects of a product first rather than trying to get pixel-perfect UI when trying to get to MVP.
Find compromises: It is okay to accept limitations and find compromises when creating new features.
Praise each other often: Praise each other’s time, ideas, and hard work no matter how small. Bit by bit the product grows into something amazing!

Developer Learnings:

Vanady Beard

&

As the back-end developer, I learned how important it is to create efficient and reliable systems that support the entire application. This experience also taught me the importance of optimising the database and ensuring the backend is scalable and easy to maintain.

Developer Learnings:

Stephen Asiedu

&

As a back-end developer, I've come to understand the importance of being familiar with various database systems and modules. This knowledge enables me to build diverse applications and maintain versatility in my work. I've also learned that the responsibility for making the right choices rests on my shoulders, guided by my best judgement.

Developer Learnings:

Zohaib Manzoor

&

Communicate feasibility: The importance of scoping MVP features and communicating feature feasibility to non technical members of a team
Check-in often: Providing updates with daily stand down sessions helps track the stage of the app and how team members are doing.
Encourage new ideas: Making time to agree on core values helps team members feel more comfortable sharing ideas and/or comments. Throwing out ideas is a great way for others to gain inspiration and build on them.

Developer Learnings:

Maurquise Williams

&

Process of Creating an MVP: Developing a Minimum Viable Product (MVP) taught me how to focus on delivering core functionalities balancing between essential features and avoiding scope creep.
Collaboration in a Real-World Tech Setting: This experience taught me how to collaborate efficiently in a fast-paced tech environment, keeping the team aligned and productive, even while working remotely across time zones.
Sharpening Critical Thinking and Problem-Solving Skills: This experience honed my ability to think critically and solve problems efficiently. By tackling challenges and finding quick solutions, I sharpened my decision-making and troubleshooting skills in a dynamic, real-world setting.

Developer Learnings:

Jeremiah Williams

&

All in all this experience was very awesome I learned that in coding with others being transparent is key

Developers Learnings:

Justin Farley

&

I learned how important communication is when working with a team. Communication provides understanding, advice, ideas, and much more. While working with the product team, I’ve found that communication keeps everything flowing smoothly. Working with a team also showed me that every member brings something different to the table and we all have to work together in order to align and meet our end goal.

Full Team Learning

Communication fuels success: Building an MVP requires constant negotiations and prioritizations between cross-functional teams to identify what is or is not in project scope. It is okay for this to change as long as reasonable justification is provided and all stakeholders are in agreement.
Include users early on: User testing can be done before a single line of code has been written! There is no need to have a perfect solution before getting some user feedback. Their involvement should not be a final evaluation, but more so an iterative feedback loop to steer the project in a meaningful direction.