Hacker Newsnew | past | comments | ask | show | jobs | submit | ryanchan001's commentslogin

Embedded integrations is such a big problem to solve. Congrats on the launch Brandon and team!


We should chat Steve!! Sounds like a lot of interesting potential and congrats on the launch!

- Ryan from UpKeep (www.onupkeep.com)


Thanks Ryan, I'll reach out, I had you on my radar for post-YC.


Los Angeles, CA | Frontend Web Developer | Backend Web Developer | Marketing | Product Manager

Visit us on the web at https://onupkeep.com/

UpKeep is a mobile first group collaboration and productivity application for maintenance teams. We were part of YC W17. Shoot me an email at ryanchan@onupkeep.com if you're interested in joining an early stage startup with amazing growth potential down in LA


The github page for floydhub has a lot of open source projects. What parts of floyd is not open sourced?


Deep Learning is a very open source friendly community - most of the popular frameworks/algorithms are in fact open source. In fact, Floydhub is built on top of a lot of open source projects. We definitely considered open sourcing the core components of Floyd but the Rethinkdb fiasco made us "rethink" that. Instead, we are supporting the open source community by hosting Deep Learning Docker images, popular datasets, and projects. In the future, we are planning to open source more parts of Floyd but not all (similar to Github).


Hey guys! Your site looks awesome! Sorry for my noobness, but what is a serverless CDN, who is it for, and why do I need it?


Serverless CDN is the term we use to describe a CDN that uses no servers for the content itself.

It's actually a Peer-to-Peer Content Delivery Network. Big content providers (like Netflix, Youtube, ESPN) can use that to deliver their content more efficiently and improve their users' experience. That results in less rebuffering for their users and lower costs on infrastructure.


So full disclosure: I just started YC and we are only about 3 weeks into the program out of 12 weeks. So.... What I am about to say is without the full picture, but here's what I can say so far.

It's not too different than before :P. YC is very very hands off. I went to a pretty large public university and it sort of feels like that. There's a bunch of really awesome people, but there won't ever be anyone to hold your hand to make sure don't jump off a cliff. You or I need to seek out the right people and make sure to connect to those that would be best suited to help the business!

So, with all of that being said, I guess what I can say is that the experiences of being a solo founder are pretty identical to the experiences of being a solo founder in YC.

I'll elaborate more about some of the challenges I went through and some that I still do go through! But if I have bored you by now you can stop here hah.

I think as a solo founder you just go through different set of struggles, some easier and some more difficult than having multiple cofounders. At the end of the day we always just make the most out of our situation regardless of what that is (ie. don't force yourself to have cofounders or not have cofounders if the stars aren't aligned). To give you an idea of some of the struggles... I worked completely alone in my mom's garage for almost 2 years! I had a remote offshore team helping out with some of the work as we grew, but for a long long time it was just me. I actually hired my first in-house employee 2 weeks ago and he's been super awesome so far--what a game changer!

Anyways, going through this path was the first for a lot of things for me. I made a ton of mistakes that sometimes I wished I could've just bounced ideas off of someone else with from time to time. It was the first time I had ever programmed, so even getting my development setup took way longer than it should have, trying to market, sell a product, price a product, set up HR, design, legal, omg I am getting overwhelmed just thinking about at all of the stuff that I learned. But anyways, it was super rough at times just not knowing.... and having conversations with myself about whether or not I am making the right decisions. But the caveat to all of this was that I learned a tremendous amount in a short period of time and I made really quick decisions without ever feeling paralyzed by discussion. A lot of the time I made the wrong choice, but I learned! And for that... I am super grateful :)


Fascinating! Thanks so much for sharing!


Yeah of course!!! It's been a crazy journey and it's just getting started!


Yeah.... I get that it sounds a little bit gimmicky. But the main point is to really give people a quick 5 word summary so people have a good idea of what it is we do!


Sure! So here's the most common use case

Employee A notices that there's a broken piece of equipment and wants to submit a work request. This is typically someone who is not involved in the day to day maintenance of the facility. Instead this is normally a employee, cashier, executive, marketing, operator, etc.

For companies that have a lot of employees, we provide them with a dedicated URL, what we call their "Company Request Portal", to submit work requests. So, like you said, they don't need to create an UpKeep account for every single user which would be super prohibitive. Instead they take this link and either embed that web-page in their company website, or have that link saved somewhere all employees know where they can submit a work request.

Regardless of whether the request was made via the "portal" or through the application, the tickets get funneled into UpKeep. It sends a notification to the "Admin" of the group which then has the option to "Approve" or "Reject" the request. When they approve it, they are typically assigning the work order to one of the their maintenance technicians. When the maintenance technician updates a work order, both the admin and the requester are notified about the new status of the request :)


Follow-ups questions:

1. How do companies educate their employee base on where this portal is? I imagine this is something that many employees will never use in their entire lifetime at a company.

1b. Isnt is more intuitive for an employee to simply call their helpdesk and report a maintenance issue. Shouldnt the focus of your product be to have help desk employees submit the work request on behalf of Employee A? Since I imagine most employees are just conditioned to call their help desk for any type of issue they have. In which case, now you'll have to compete against competitors like ServiceNow who dominates in help desk software.

Edit:

Please don't take this as me hating on your product. I don't. Quite the opposite. I'm just really fascinated by what your created. Hope you succeed and interested in reading your response.


Thanks and don't worry 1 bit! I love this conversation and the insightful questions you are asking.

1 - Email blast! And it depends on the type of company. If you are a property management company with lots of employees you're right a lot of people won't use it. Then UpKeep becomes a more internally facing tool for admins to enter in requests and dispatch jobs out. BUT if you are a maintenance heavy company (industrial, manufacturing, etc) you are used to submitting work requests and tickets in every single day.

1b - Yes! So basically the requester normally has the most information. If they can take a picture and send it in with the work order, it is soooo much more descriptive and helpful to the admin user. They can also call it in, and UpKeep works in both ways. But it adds additional overhead to the admin users to be manning the phones at all times.

At the end of the day, UpKeep works in both scenarios and it really depends on the workflow of the company! :)


If someone calls, you can pretend to be a requestor submit a service request on the caller's behalf using his/her e-mail and phone you ask over the phone.

The confirmation e-mail can reinforce:

1) check request status online 2) create new requests online

Customers that prefer to call will continue to call, but those that prefer the portal will save you time and submit online.

When the business is closed, customer can submit non-emergencies online as well.


Awesome Q. Believe it or not, this is a pretty crowded industry with a lot of legacy solutions that have massive marketing budgets. I knew that I couldn't compete with them on a dollar per dollar basis trying to buy clicks through adwords and marketing towards managers, so I haven't bothered to go down that route... yet. Instead I have been playing to UpKeep's strengths. We created a tool for technicians and have a beautiful easy to use mobile application to go with that. So... We've been trying to drive all of our traffic to our mobile applications and encourage bottom-up adoption (technicians tell their boss there's this awesome new app called UpKeep! We should use it). I think marketing it this way, just out of the nature of our strategy, led us in the hands of lots of small-medium sized businesses, or smaller silos into large enterprises where they get more governance over the tools they use. We've seen a lot of successful users in the facility management space from coworking spaces, restaurant franchise owners, and smaller manufacturing groups.

A common use case for UpKeep is that someone sees a broken piece of equipment, pulls out their phone, opens up UpKeep, snaps a picture, and sends it off to the technician for repair. The technician now has a prioritized list of his/her tasks for the day and can easily follow up with requests!

In terms of how did I both build and market with a full time job... I didn't do any marketing for UpKeep in the beginning. I had the most common misconception that "If I built it people would come". In the beginning, UpKeep was a free application for everyone, and I viewed it more as a hobby as I was learning to program. It slowly started gaining popularity in the "free to use" category for business applications and it was fueled all by what a cool app that's completely free.

Now... If you ask about the transition from a free product into a paid service... I felt so so bad doing it because we actually upset a lot of users during that transition. But yeah that's a whole new story :)


Yeah I think the most important thing I am hearing from everyone on HN (and it is very much appreciated) is that we need to do better on our pricing page.

I love the feedback though! I always feel like I want to keep adding details to try to make it more clear, but I can see that we've come to a point where it may be having the opposite effect.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: