Filepicker.io Blog

Express your ideas with conviction, but be willing to drop them and adopt better ideas as they come along. The best leaders and organizations are those that are pragmatic. Here at Filepicker.io, we say “Strong Opinions, Weakly Held” - a concise and effective way of encouraging active debate and the meritocracy of ideas.

“Strong Opinions” means two things: that you should express your ideas with conviction, and that those opinions should be strong opinions, supported by evidence and logical. If you don’t express your opinion strongly, it may not stick in the listener’s head as well as an overall weaker idea that someone else expresses with more zeal.

“Weakly Held” means that if a legitimately better idea is presented, embrace it and change your stance as soon as possible. This is often referred to as “check your ego at the door” - there is no honor in continuing to fight for an opinion just because you expressed it previously.

It is not uncommon for people here to be passionately arguing a feature, a design, an architecture, and for one person to suddenly stop and say “oh - yeah, you’re right. Cool. What’s next?” This can be unnerving to people who experience it for the first time, but it’s been very effective in sifting out the best ideas and facilitating a culture of health arguments and deep mutual respect.

Discuss on HackerNews

We’ve been growing in headcount and we found ourselves with an odd problem: we didn’t have enough key fobs to the office. Filepicker.io moved into a nice work live space overlooking AT&T park last October and our landlord has been great; we just kept asking for more key fobs. However, here’s how we got Twilio to open the door for us. [1]

The door, like many live/work spaces, has a phone box. There is a list of names and corresponding numbers. Dialing the right code rings the resident and the door opens when they press ‘9’. We’re going to integrate with this existing system to allow our code to interface with the door.

Solution

The system is straightforward. Text a number when you’re about to reach the office. [2] If your number is on the server’s whitelist, it will be expecting you to arrive in the next 5 minutes. Then punch in the number of the office and Twilio will let you in. If the door isn’t expecting one of us, it will simply forward the call to one of us.

There’s also a party mode, where you tell it to let anyone in. No more having the host keep having to answer their phone to make sure everyone gets in.

Security

We considered other security models as well. Taking a look at how people ensure that they aren’t letting random people in is by verifying the name, voice, and if they are expecting them. Mimicking that would be difficult, both due to the voice recognition (had a tough time finding good libraries for voiceprinting) and arrival expectation (based on people’s Google Calendar?).

Our phone system didn’t seem to forward DMTF tones from the phone box so we weren’t able to use a PIN number.

We also considered a location based phone app that would open up the door whenever you got near it. However, given that our offices were right above the door, it’s difficult to distinguish between one of us sitting at our desk and one of us waiting outside.

Infrastructure and Code

Infrastructure-wise, we’re running it on a AWS Micro and an elastic ip, though Heroku works as well. [3] You can set up your own doorman as the source code is here and Twilio is super easy to set up. You’ll just need to ask your landlord to change the phone number to your Twilio number.

We’re open sourcing our code and you can get it here, with relevant setup instructions: https://github.com/Filepicker/gatekeeper

It’s pretty simple code, but the configuration management is worth mention. We wanted it to be highly configurable, but didn’t want to write a web or curses interface. Instead we opted for a YAML backed dictionary. Modify the file and the next time the app needs the data, it will reload the config. If you made a typo and the yaml parsing fails, it won’t crash. It will just continue to hum along with the previous configuration.

It’s been rock solid for us (it’s pretty easy to be bug free with <100 lines of code) but pull requests and suggestions welcome.

This probably shouldn’t be used to protect Fort Knox, but it’s a good system that has allowed us to grow and scale out the team here at Filepicker.io. Startups at our stage all have growing pains, both those that you’d expect and those you wouldn’t. Migrating your db to SSD’s is one you’d expect. Migrating your door off of key fobs, not as much.

[1] This was also a flyout interview project. Double bonus.

[2] You can also have Siri send the text message for you, ala http://rumsey.org/blog/2011/11/voice-controlled-garage-door/

[3] I haven’t experimented to see if the single dyno sleeping will serious impact the code. You may need 2 dynos.

Hi all,

Monday the 1st I joined Filepicker.io to work on User Acquisition and Product Management and I am pumped!

Prior to this role, I worked as a Product Manager of Shopping and Merchandising at Nook (the e-reader owned by B&N) in Palo Alto, Product Manager of League of Legends Shop at Riot Games in Santa Monica, and as a Program Manager on System Center at Microsoft In Seattle. Through these roles I acquired a good amount of knowledge in the areas of eCommerce, Merchandising, Personalization, User Experience, and Enterprise IT Solutions (can you spot the one that comes from Microsoft?). I very much enjoyed defining and building product and look forward to incorporating that knowledge and experience as well as extending my knowledge to identify and address any needs which help with driving healthy adoption of the product.

The largest driver of my fresh excitement stems form the fact that the company, the role, and the space are very young and ripe for innovation and definition. We are again in a position where we are experiencing a paradigm shift like the introduction of the OS, web, mobile, social which I call the interoperability paradigm (until someone comes up with a better name) where developers of end user solutions switch from building their own way of doing everything to adopting services that give you a majority of your applications functionality without having to develop it yourself. Examples include logging in with Facebook, Google Analytics, Ad Platforms, and of course Filepicker! Chances are very high that your application does not specialize in uploading and downloading files and hence any time you spend building those features is time you don’t spend building your magic sauce. Or you can not provide these features and force your users to peck around the web for their files and hope they don’t get discouraged enough to stop using your service. You can think of this space as having two dimensions, horizontal interoperability is something like Filepicker where you get extra functionality which you don’t have to build. Vertical interoperability is for example using Mongo DB instead of building your own. Vertical interoperability has been around for a while and is seeing great adoption at this time, and horizontal is just getting of the ground floor.

My personal definition of success in my role is delighted users. This means that your users are happier with your service because of our service to you. If that is the case I go home happy, if that is not the case, I don’t go home. Here are some principles by which I tend to do my work:

1. Having a small user base that loves you is better than a large users base that thinks you are mehhh, ok…
2. Our product is our best salesperson.
3. An authentic representation is important. You as the community should be informed about all the good and bad of our product or service and kept up to date on improvement and issues in the service.

With these principles in my pocket I hope to provide the best developer experience for our developer community and user experience for their customers. I am sure I will communicate much with many of you and I look forward to that.

I am one of those people that does a little bit of everything when it comes to hobbies, and it changes frequently. Currently I go bike, hike, read, sip lattes, and watch Battle Star Galactica (almost done!).

I hope to meet many of you in the future,

Darko

One of the most requested features we hear from our customers is the ability to use video transcoding with Filepicker.io in a way that’s just as powerful and easy to integrate as our image conversion capabilities. We took a deep look at the video transcoding space and knew that we wanted to work with Zencoder to make it happen. The result? The easiest way for your application to collect, transcode, and display videos to your users.

Here’s how to get Filepicker.io and Zencoder working together in your application (or just see the demo and source code):

0. Head on over to Filepicker.io and Zencoder to sign up for accounts if you haven’t yet - keep your API keys handy, you’ll use them soon

1. Pull together the basic html template:

2. Add the custom javascript to call Filepicker.io when the upload link is clicked

3. Add the logic to take the upload and send it to Zencoder’s servers for processing

For a full tutorial on using the two services together, see the tutorial and the accompanying demo, along with accompanying source code on github

We’re really excited to see what you all build with this new partnership - whether your users upload videos for their profiles, a product review, a crowdfunding project, or really anything else, Filepicker.io and Zencoder can help you make it happen.

A special thanks to Matthew McClure and Casey Wilms at Zencoder for their work to make this possible.

When you’re working on javascript code, you can set a breakpoint from your editor by putting in the statement ‘debugger;’ in your code where you want to break. It’s better in many cases than manually setting a breakpoint in the inspector.

I recently was working with a very talented front-end engineer who had never seen this trick, and so wanted to share it with the subset of javascript engineers out there who for whatever reason have never seen this. Put it in your code where you want to break, open up the web inspector, and the code will stop where you commanded, allowing you to walk the code forward, inspect the stack, and get and set local variables at will.

(function(){
   var time = +new Date;
   //no idea what that did, let's check it out
   debugger;
   //You can now modify local variables as well
   alert(time);
})();

Pro Tip: ‘debugger’ statements cannot be disabled at runtime, so don’t put ‘debugger’ inside of a loop. Instead put it right before the loop and then manually set a breakpoint in the web inspector. That way once you’ve found out what you need inside the loop, you can disable the manual breakpoint and the rest of the iterations will continue without you having to mash F8.

Discussion on HackerNews

First let’s set some boundary conditions for this post. It is meant for early stage tech startups with limited resources embarking on their first usability testing experiment.

Yes, usability testing is important. But performing usability testing at an early stage startup is hard. Best practices from larger companies with dedicated product managers do not carry over easily. We learned this when we rolled out a structured usability testing exercise at Filepicker.io

Our goal: reduce friction in developer onboarding on the website. Here is what we learned:

#1: Startups are resource constrained. Think minimum viable process.

usability testing best practices advocate an exploratory, open ended approach. There are several awesome resources such as this one that can guide the experiment.
So when we started the experiment, we wanted to understand if developers had enough information on:
a) How to start using filepicker.io in their relevant language/platform
b) Whether the steps are specific enough to setup a simple integration
c) Whether they feel comfortable with the sample code
d) What other actionable items are required to go live with the service

But when we asked ourselves what we would do with the answers to these questions, we realized that we wouldn’t do much. Rather, we couldn’t do much.

Why?

None of the responses would help us determine where to draw the line on follow up actions. For example: how much guidance should we provide till a developer feels comfortable with the sample code? Or how many of the actionable suggestions should we implement?

While the open ended questions certainly yield a wealth of knowledge, what use are they if they can’t be implemented? Startups always have a sh*t-ton of work and, as it always feels, there are never enough resources. With limited resources to go around, all nice-to-have or would-be-great-to-have tasks seem like luxuries and the focus always remains on resource maximization to grow the company as fast as possible.

Therefore, the better approach was to limit the scope the experiment to prove or disprove some specific unit of measurement for a specific customer persona. Thus, we redefined the learning objective as:

“For customer persona X, it’s not possible go through the entire onboarding flow without reaching out to support@”

This allowed us to quantify and prioritize the feedback that we received from the usability testing. Initial usability testing (we need to do this for a statistically significant sample) proved that developers could finish the onboarding flow for a simple use case without reaching support (phew!). This meant that we WOULD NOT have to prioritize improving the website right away. The feedback we got from the exercise has been added to our icebox as nice-to-have rather than a must-have.

#2: Take responsibility for the entire user experience including third party products

Sometimes the problem in the onboarding flow might not lie in your product but in the handoffs occurring between your product and other third party products.

In our case configuring the AWS S3 settings is a critical step in the developer onboarding flow. When we reviewed the recording from the Silverbackapp we realized that developers were getting lost in setting the IAM policies. While we provide links in our developer portal to the AWS support page on this topic, it was obviously insufficient. Though they eventually figured it out, there was quite a bit of toggling between screens to understand what needed to be done.

It was clear to us that if we wanted to provide as frictionless as an experience as possible to the developer, then we had to take ownership of that experience as well. So we made a screenshare of how to configure the IAM permissions in S3.

In conclusion, think minimum viable process for user testing. If you are a startup, be wary of adopting best practices designed for large companies. Open ended usability testing may not be the most optimal thing. If your onboarding flow involves third party products then watch out for friction in the points of handoffs.

One of our primary goals at Filepicker.io is to create a best in class developer experience, guided by tests like this one step at a time. Try us out and tell us how we’re doing.

-Chintan & Anand

Follow the discussion on HN

[Edit]-Per Chris Smeder’s comment on HN, user testing has been changed to usability testing throughout the article.

Unfortunately, I couldn’t change the title as it would break the url which has been reblogged and distributed.

Very recently, without many people realizing it, there’s been a major shift in the way that software companies treat cloud storage services like Dropbox, Box, Google Drive etc. Online storage is starting to become a primary hard drive for users rather than a secondary. We’ve been seeing it in the rapid pace of our growth as well as through moves by others in the space, such as the Dropbox chooser and Gmail adding attachments from Google.

Originally, people only stored files online as backups. Then Box and later Dropbox opened up the collaboration use case, storing files online so they could be shared between two people. Now, people on an appreciable scale are starting to use the files they have in online storage as the primary version, particularly with photos. In more and more cases, the content that people want to work with is not sitting on their local hard drive, it’s online, synced up there by their mobile device or shared from a friend.

This is why we created Filepicker.io, to help developers deal with this migration of the primary content to the cloud, and with products like the Dropbox chooser and Gmail-Google Drive integration surfacing, it’s clear that the industry is moving forward, that consumers will soon expect their applications to work with directly cloud storage. Of course we believe that applications should integrate with all the cloud storage services not just one, but there are other interests at stake and so getting all applications to work with all sources of content will take time. For now, we’ll keep encouraging applications like Cloudy that add in multi-platform support.

Users are starting to treat online storage as primary sources, and as the applications they use start working with that content directly, it’s a major step forward in the notion of the web as a platform. As we at Filepicker.io and elsewhere push this notion of interoperability forward, we’ll see a web where from any device, a user can log in to their accounts, view, store, edit, and share their content, all online, without ever needing to download or upload.

We started this company with the belief that as more content went online, there needed to be a better way for applications to work with this online data. And this change is happening now, with some customers now having over 70% of uploads starting from the cloud, up from 20% several months ago. To us, the shift towards people using online storage as their primary drive is very exciting, and we’re thrilled to have played a role in pushing it forward. The signs of this paradigm shift are just starting to show, and it’s only the beginning.

Discussion on Hacker News

Fresh from Thanksgiving and its associated warm fuzzies, I found myself wondering if the spirit of generosity and gratitude extend to business contexts.

For example, how do people respond when they are presented a product or service without a corresponding price? I am specifically referring to situations where the seller invites the buyer to name his own price for something of value that is being offered by the seller.

Evidence shows that when the user is asked to name his price he often quotes $0!

A popular variant of name-your-price model in internet businesses is the “Support the Product” or “Donate” button where the user is free to name a price for the software module.

A lot of independent developers and incubating startups often use the Support or Donate button when they spin up a new product or service. Since the product just launched, the developer tends to be unclear about the pricing model and often is motivated by building something that people want; monetization is a secondary problem. The argument goes “if you are building something people want then why not let people pay what they want for it?”

Well, it turns out that customer based pricing is flawed because customers have no idea about what they should pay for it.

For example when we launched Filepicker.io on April 19th on HN, we had a “support our Product” button on our website too! We weren’t sure about how we would price Filepicker.io but more importantly we wanted to validate if the product was something that people wanted. So we put up a “Support our Product” button inviting those interested to contribute whatever they wanted. Hopefully, after seeing the documentation & API calls they would see the value in the product and then pay us.

We observed something interesting. We had about 14,000 unique visitors from the launch and about 2000 odd signups for the API keys but no one clicked the Support button to pay us for the product. In subsequent days and weeks we saw a lot of our customers go-live with Filepicker.io but the metrics on payments never changed. Still $0.

It turns out that this problem with “name your price” isn’t unique to software. In 2007, the British band Radiohead released their Album ‘In Rainbows’ in a pay-what-you-want model. Around 62% of listeners chose to pay nothing for the album though they were fans of Radiohead! On a worldwide basis the average price for the album was $2.26. More details here It is interesting to note that while name-your-own-price didn’t yield massive revenues, the buzz around the scheme helped the Radioheads see additional discs, concert tours etc.!

So moral of the story is that name-your-price schemes tend not to work if you are sharing something with a broader audience and expecting them to pay for it (or at least want to know how much it is worth). You are better off naming price and asking customers to pick a price point that works for them.

By the way, there are two exceptions to the name-your-price models that seem to be working in the marketplace currently; Kickstarter and auctions. I suspect that social proof that there are others backing a project motivates Kickstarter users to name a price (starting at $1 minimum bid). It would be interesting to see the statistics on how the funding pattern breaks down because there are different rewards for different amounts contributed (much like different benefits in economy class vs. first class on airlines).

In auctions, the pressure of being outbid forces users to bid up to the point where the fair market value of the product is established. This is true of bid-buy products like ebay and Priceline.com

As far as Filepicker.io’s “Support the Product” button went, we yanked it after we found it didn’t help us learn how much customers were willing to pay. We later on changed the pricing model to explicitly present a pricing plan and tweaked it around a bit to build alignment with the marketplace. You can read about our learning from pricing changes here.

-Anand Dass

Follow the discussion on HN

You started a company!? High five, good work. It’s now been a few months, you’ve had a lot of late nights with your cofounders, and it’s starting to look like you are making something people want.

Here’s a heads up on some of the things you’ve probably ignored so far, but you should probably take care of. These are primarily geared to people who have never started a business.

1. It’s illegal to not have Workman’s Comp. It doesn’t take a lot of effort, particularly if you get a broker to do it, but you’ll have to pay some money. Given that you legally have to, it’s a good idea. *Note: this definitely applies to CA, but check with brokers in your local area if you don’t think you need it

2. Go through any code you have and make sure of two things:

   1. That any open-source components you’re using are fine for commercial use. These days, a lot of great software is being written under the MIT or Apache Licenses, but check. Twice.

   2. That there are no lines of code written by people who didn’t explicitly transfer ownership to the company (usually involves paper). It seems silly, but if someone can argue that those 10 lines they wrote when they came over for an interview resulted in 0.1% of the company’s success, you’ll kick yourself. Draft up a quick document, pay them a fair amount for the work, and keep the signature.

3. If you’re hiring people, you should have an Employee Handbook. There are legal reasons, but it’s also a good forcing function for you and your cofounders to make decisions on things you haven’t had to yet, i.e. What is your vacation policy? Are weekends off? Is swearing in the office ok? What can be expensed to the company? If you have employees agree to the handbook it can also help you not get sued for wrongful termination.

4. Speaking of expensing things, don’t use cash for anything. Your (eventual) accountant will be very upset at you, and the IRS likely will as well. Best is to use a company credit card, next a company check, next a personal card/check. And always keep receipts, either digitally or in a drawer for “later”.

5. Ask around about any good part-time accountants that can help you when you eventually get to “later”.

6. When paying vendors for business services, use Paypal. At the end of the year, Paypal will take care of sending your vendors tax-related forms such as 1099-K, so you won’t have to worry about additional things to follow up on near tax season.

7. What’s the company strategy around patents, or IP in general? Whatever you decide is fine, but you should be conscious about it. Apparently there was a startup called “Bing” that essentially failed but made quite a bit of money on the trademark.

8. Be aware that pictures and other things you write down (including emails) can be used against you for legal/tax purposes. If you’re living out of your office or visa-versa, you didn’t tell me, and you don’t have any pictures. It can be dealt with, but you’d rather not.

9. If you have investors, many times they are entitled to quarterly reports on financials, etc. Put those dates in your calendar and follow through.

10. Get a lawyer. There are hundreds of little regulations that may or may not apply to you and it’s impossible to keep track of them all yourself. The best lawyers will agree to deferred compensation if you’re persuasive enough. They protect you now, you pay them later.

11. Get your own office. Co-working spaces are fun, but they often make it impossible to build your own company culture. You don’t want to get shushed when you want to laugh loudly at that funny youtube video, or when you want to have a lively product debate.

12. Start a relationship with your banker. Having someone at your bank who knows you can be invaluable. Startups have to move at lightning speed, and you don’t want a debit card hold (they happen all the time) to kill a sale, investment, new hire.

13. Get a company health insurance policy. There are certain things you just don’t want your teammates thinking about, and health insurance is one of them. Have one person on the team figure this out for everyone, and make it a perk.

14. You’ve dealt with your 83b Election already right? If not, call a lawyer and discuss your options. You may be better off dissolving and reforming the company.

15. As the number of people in the company increases, define an expense policy of what can be expensed to the company. While this may seem overly corporate, it helps make sure everyone is clear and isn’t stressed about every single transaction. How you define this policy is up to you - some companies define a broad expense policy and let employees make judgment calls on whether an item fits the category. This makes the employees feel like the company will take care of the things they need, but since this policy is based on trust, and can go south without the right company culture in place.

Note that this is not official legal, tax, or business advice, we are not lawyers/CPAs, don’t sue us. Thanks to Brett van Zuiden, Anand Dass, Seth Bannon and Fred Stevens-Smith for their input.

This will be maintained as an evolving list on github at https://github.com/Filepicker/LearningToWalk

Discussion on HackerNews

It has been said you should enter a business plan competition at most once. Steve Blank wouldn’t even go that far. Most startup events are similar, particularly around universities - going to more than one can be dangerous in that it creates a false sense of accomplishment.

Don’t get me wrong, these events are fun, and for the people presenting, they’re a good chance to build some brand equity. If you’re going for some interesting stories, maybe a free breakfast, then have fun, but far too often I see people I know attend these events month after month as a way of “getting into startups.” The time is better spent actually working on your company, as the necessary ingredient of getting into startups is to start or work at an early-stage company.

So here’s my rule: if you go to a startup event, plan on attending the following year as a presenter. And when you do, pass this rule on to the audience there.

-Brett van Zuiden