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

Envisioning a better future

Working in tech and entrepreneurship, we are taught and encouraged to challenge the status quo.  In tech companies, this is said a lot, but it does not always happen depending on the company culture, the team, and the manager.  However, being an entrepreneur is all about challenging the status quo.

I have an end game in mind here.  I want to have my own company (possibly several) that I start, grow, and eventually hand off to someone who wants to run a giant corporation.  As I have reflected on my goals and interests, I realize that I do not want to be the Vice President at a massive technology company.  I also (likely) don't want to be the CEO or CTO of a billion dollar venture.  The reason is that once a company reaches a certain size, it maintains impact in its field, but it rarely creates a new wave, a serious change.   

Take Google, Facebook and Apple as examples.  

Google's biggest impact to the world was creating PageRank Search.  The internet existed, but it was hard to use.  This idea that you just know a URL and type it in for everything you might need is ludicrous (in retrospect).  The internet was great, but metaphorically, it was a TV set, and Google became its remote controller.  With just a TV, you have to sit there and guess where functions and cable channels are.  With a remote control, you can access all functions of the TV, and be connected to all of the cable channels it has to offer.  That being said, Google technically was not the first search engine, but it was the best.  Since then, other Google products have been massively successful, but nothing was quite the game changer and innovation as PageRank Search.  Everything else Google has done has built off of its search platform.

Facebook changed how we interact with people close and far away.  Granted, it also was not a first mover, but it was the best.  Facebook has continued to innovate, but it is all connected to its initial idea, a social network.

Apple changed the world with the personal computer.  It continued to improve it, then dropped off.  Apple is the rare breed that shocked the world again with the iPod, the iPhone, and the iPad. You can argue that these all still built off of the personal computer, but since they were significant deviations from the personal computer, you can call Apple a large company that continued to change the game with serious innovations.

In all of this though, the beauty of a startup is it has a fresh idea and team, is it is uniquely new.  It comes into the field to shake things up.  It's not looking to appease shareholders, it's not looking to iterate on the next version of its software or device, it's looking to make a difference, to do something phenomenal and new.

But here is my issue with Silicon Valley's startups these days: Everyone is solving the same problems, just variations of it.  Sometimes it's a new technology, other times it's an app that saves you time or connects you to the world in a different way than the other 6 social media apps that anyone has heard of.  Everyone is looking to use "Big Data", "Social", "Local", "Synergy" to solve yet another techie first world problem.

Silicon Valley needs to stop priding itself on how innovative it is with its next first world problem solutions.  I personally want to have my own startup that solves some basic first world problem, but ultimately, I want to use the reputation, power, and wealth that I would gain from solving one of these first world problems, and channel these resources into solving real-world problems.  Problems that affect the people who are not able to use Silicon Valley's apps.

I truly admire Bill and Melinda Gates for starting the Bill and Melinda Gates Foundation.  What they have done to help the different populations of the world is truly incredible.  I think this needs to be taken to a new variation and degree.

The brilliant entrepreneurs in Silicon Valley need to make their app, win a fortune, but then re-channel their efforts to our fellow humans who lack basic needs.  There are small businesses and programs that hire convicted felons to bake goods such as brownies.  This model of building a sustainable business to create jobs for those who have no other means of finding work is what this world needs.

I don't know exactly how this can be done yet, but I know we can solve this problem.  I don't know if it should be for our homeless, for those who live near the poverty line, or for former criminals.  Ideally, there should be a solution for each demographic.  I would like to pilot an idea like this in the United States, because I believe in taking care of your home first.  People say the United States is the greatest, but a team is only as strong as its weakest player, and the United States has left a lot of weak players lying around.

We cannot wait and rely on the government.  I'm not taking a Libertarian stance on government; it is needed and it does great things.  But innovation does not happen within the government, our brightest and most driven individuals are not going after government jobs as much as they used to.  An idea like this needs to be funded and executed by the private industry.  The government can support it, but it needs to remain independent.

Our brightest citizens who have already made a fortune need to stop simply donating money, and need not enter into early retirement.  These people need to put their thinking cap on again, and look at how we can build a sustainable business to give people jobs who otherwise have no means to get a job.  

Handing out money and goods is not a bad thing.  I am not a Conservative that is hating on charity hand-outs.  There are instances where it is crucial.  What I am saying is, giving a hand-out does not help an individual in need long-term.  Many Conservatives say that if someone has the drive and will to make it, then they will -- This is not accurate if there are no opportunities present to an individual.  Creating a sustainable business geared to hire people in poor situations not only ensures a constant flow of money to the workers, but it gives them a sense of purpose.  It teaches the individual how to grow, learn, and earn.  It builds confidence and self-worth.

This idea sounds crazy, it sounds far-fetched and too idealistic, but so did a personal computer in every household, so did a search engine, and so did social profiles.  

I think entrepreneurship is amazing and critical to this country and our planet.  A lot of the best ideas and innovations come from entrepreneurs.  But now it's time for these people who are so great at building businesses, to stop building the business that makes an app, and start building the business that we all need, the one that bridges the wealth gap and does good.

This is essentially a privatized, capitalist New Deal Act... the "New New Deal".

I personally am very passionate about this idea.  I have first world company ideas that I want to launch, because I am excited about them, but more so as a gateway to pioneer this idea and movement myself.  It is long overdue, and it can be solved.  It's just a matter of how.

I envision a better future.