Advocate Community Service

Advocate Community Service

Operational from 2013 – 2015

I founded Advocate in 2013 with the goal of making community service fun, easy, and accessible by giving non-profits and volunteers a simple way to post and share service experiences. Alex Hadik joined in early 2014. I managed the business and UX design of the website and app, while Alex helmed the technical development and maintenace of the platform. We discontinued the platform in 2015.


The Pitch

When you wake up on a Saturday and have some time to do good in your community, where do you turn? While you can check Facebook for upcoming social events, or GroupOn for cool weekend outings, there's nowhere to turn to find community service opportunities.

Advocate aims to change that. Non-profits post their events on our marketplace, giving volunteers quick access to events they can participate in. Meanwhile, non-profits have access to our tools that help them organize and execute events faster and more effectively. Finally, administrators for schools, fraternities or other organizations can see the service activities of their members to make sure they're on track to meet their requirements.


The Business Model

In our last iteration, the business model depended on schools and exports of hours. Though signing up for events was free, the system would charge a fee in order to export and send a receipt of validated service hours. Schools could pay an annual subscription fee to access a range of adminustrative tools to help them manage and have insight into their students and community service requirements.


The Journey

Aiming for the start of the 2014 school year, Alex and I worked together through the summer, interning at IBM Design during the day and building Advocate by night.

We entered and won a number of pitch competitions, securing funds from the Brown Swearer Center Explore Grant, a working area in RISD's E-ship In-Residence Program, and a seat on Social Enterprise Greenhouse's Incubator Program.

To source our events, we partnered with ServeRI, the City of Providence, New Urban Farms, the Providence Parks Department, Rhode Island Department of Children, Youth, and Families. 

We built our platform on Heroku and AWS in order to run cheap but flexible. By spooling up dynos as needed we could quickly scale to meet demand as new batches of users joined or media was uploaded by our partners, all while keeping overhead as low as possible.

Our first customer was Juanita Sanchez Educational Complex, a high school in Providence, RI. In exchange for a semester-long contract we would pilot a program to give 20 students access to the beta and check in with them every Wednesday afterschool to troubleshoot and conduct user research. Through our site analytics, we could also see how many users were committing to events and which events were the most popular. We launched our alpha later that year at a large service opportunity, managing check-in and hour validation for dozens of volunteers coming into three different check-in locations.

Running the weekly check-in at the high school.

Running the weekly check-in at the high school.


Unique Features

  • Non-profits could set minimum and maximum amounts of volunteers for their events, and time slots that would show as full and recommend alternative times.

  • A new check-in interaction [pictures/gif] that allowed event coordinators to easily track and manage volunteers on-site while validating their hours.

  • Users could see which of their friends had committed to which events. This came from an insight where we would find some students would not attend an event unless they knew someone already committed to going.

  • Schools had an adminstrative panel to track the service hours of students. This was especially useful to schools or universities with a community service requirement for graduation or acceptance.

  • Validated service hours would be sent directly to the school or university. This prevented tampering or forging of hours, a common occurrence.



Throughout our beta we continued to learn from our users and refine the platform. We ran into our fair share of unexpected obstacles to navigate, ranging from specific user issues to structural business concerns.

To name a few:

  • Many of the volunteers were under driving age, which meant getting to some events was prohibitively time-consuming (organizing carpooling!)

  • Without a way to disincentivize no-shows, our volunteer count for event managers was shaky at best. (email reminders and confirmations!)

  • Since we were paid for by schools, we had to abide by strict minor protection statutes, which made sharing friends attendence more complicated and difficult. Meanwhile, Facebook Events was free, and being voluntary had no responcibility for liability. Sharing awareness of your friend’s planned activities was core to their value proposition, and in fact soon started recommending events to you based on what your friends liked.

  • In a similar way, Eventbrite’s event management tools were becoming more robust, giving non-profits the ability to manage scores of volunteers and perhaps more importantly, their payments.

 After our first year of operation, we carefully evaluated our performance and ways forward. Given the challenges of the market and evolutionary pace of competitive services, we made the difficult decision to discontinue the service. After 1.5 years, 3 versions of the UI, numerous after-school meetings and community service events, we thakned our valued partners and users and notified them that we would no longer be supporting the platform by the summer of 2015.



Though by no means comprehensive, this is a list of some of the most important and continually useful lessons from my time running Advocate:

  • Understand the strengths and challenges of your market.
    Schools budget out for tools and software at the beginning of each year, meaning a short window of oppotunity with a very long sales cycle. Non-profits are easy to connect with but protective of their listservs. Depending on the organization they may also be picky about what kinds of skills and commitment their volunteers have.

  • Keep a sharp awareness of your value differentiators and how defensible they are.
    Depending on the underlying technology, most social features are not too difficult to copy, so ultimately your overall UX and user base itself are your biggest assets. Competitors with different business models may be able to offer your core value differentiators for free.

  • Know when to learn and when to hire.
    Over the course of 1.5 years I managed a variety of partners and collaborators. Hiring visual designers, community engagement officers, and technology advisors all took valuable time to vet and onboard, and sometimes counterproductively so. Gauging ultimately what skills and tasks can be owned in-house is crucial.

  • Don’t assume anything about your users.
    Wireframing and prototyping too fast with not enough user testing throught the process makes it easy to assume you know how users are going to use your tool. Meanwhile, pictures will be posted sideways, kids will pen inappropriate usernames, and you will learn that highschoolers have all but abondoned Facebook for Snapchat. Airbnb famously hired a professional photographer to go to listings and take pictures to address low bookings caused by poor smartphone camera pictures, expect to adapt similarly.

  • Responsibility to your community.
    When you create something that serves a community, one of the most damaging things you can do is to take it away, especially if they have come to depend on it. The story of well-meaning entrepreneurs swooping in for the rescue and then being notably absent later when they are needed the most is a sad and well worn one at this point, but is something to think about with any kind of disruptive development.

  • Despite everything, do it anyway.
    Notwithstanding the time, effort and resources poured in, there’s nothing like actually building and testing an idea from beginning to end in the real world. Building Advocate gave me a profound understanding on not only the value but also the limitations of Design to address large problems, and how it best functions with all the other componenets of a business.