Hey Derick. Great question. At the time, we were at a low confidence point. Crew was actually called 'ooomf' at the time. And what we were building was a Kickstarter-like model but for apps. My co-founders and I had shipped a lot of product for about 6 months building ooomf but nothing was really sticking.

So part of our reasoning for doing just a Mailchimp and Wufoo form was we had lost some faith in ourselves as makers. We weren't sure we could come up with a good product solution to any problem. To regain this trust in ourselves, we felt it was better to throw ideas out quickly to validate them. And to start as simple as possible in case we felt we were approaching a problem in the wrong way.

We weren't sure if what we were building would be enough to generate interest. But our feeling was if people would use a primitive Mailchimp and Wufoo combo to solve this problem, then people would probably find it even more useful as we built a better product.

Unsplash was a similar case. We started Unsplash as a Tumblr blog and built it in an afternoon. We thought about what were the big problems we had trying to find a good stock photo:

• many stock photos were cheesy
• many stock photo sites had confusing licenses
• many stock photo sites had poor experiences to finding the right photo/size

So we attempted again to build something that solved these problems while writing minimal custom design and code. We thought this early version might be useful for maybe a handful of designers. And if it was, we felt we could build more to make it even more useful for more designers.

Though we didn't expect it, Unsplash ended up being #1 on HackerNews the day it launched and had 20k downloads. So this early version went way above our expectations. And this is something we've found often taking this 'building minimal first' approach. We've often seen more people are interested in this minimal version than we expect. And most of the time, we're happy we didn't start by building more.

Granted, this approach might not work for every type of product. But this is an approach we've taken for many products we make. We think about the future custom-built version we want to make, but we first try to see if there's a first version we can put together with minimal custom design and code.

One of the added benefits of starting this way is you lower the bar for your own expectations. When you don't spend too long perfecting something, you don't need millions of people using what you made. Even if tens or hundreds of people like your first version, and you like it too, you feel energized to do more. And continue building toward that substantial dream version that may interest lots of people.

Hey Giulio! Thanks for the question. The hardest part of building a company constantly evolves.

At first, the hardest part was making something people wanted to use.

Next, it was figuring out if someone would pay for it.

Then, it was figuring out if someone would pay for it again.

These challenges don't go away. They layer on top of one another. But they are all related back to how well your product solves a problem compared to alternatives.

So if you've got an idea for a project, I'd suggest evaluating that it's a problem you've faced personally and that you start small.

If your project is related to something you've faced personally, then you will likely be much more in tune with the alternative options and thus, understand how you could build something that stands out.

I've found starting small has a few main advantages:

• starting small creates a simple product. And the simplest product often wins because our brains prefer simple
• starting small lowers the upfront investment in case you need to change direction
• starting small lowers your expectations which can create momentum and energy to improve your project

I don't know how to code apart from a bit of HTML/CSS. But there's many ways to solve a problem that don't need code. Even if you can design and write code, I'd suggest starting small and thinking about how you can do the least amount of design and code.

Now the least amount of design and code doesn't mean make shitty designs or write broken code. It means doing the minimal amount of design/code that you think is good enough to solve the problem you want to solve.

Hey Filip! Thanks for writing.

Early on, one of the main issues we faced was figuring out the right ratio of members to projects. Our aim has been to have enough work to support all members but in 2013/14, our ratio was not accurate. We still haven't gotten this balance quite right but it's getting better.

Over the last year, we've been using a Slack channel with members to make sure we're doing what we can to help our members have a good experience.

We've also been regularly keeping up with every accepted member to see what we can be doing to deliver more of the desired amount and type of work you want.

Winning projects usually is a result of intro messages that could be stronger and/or having an updated portfolio on Crew with enough relevant examples to the current projects you'd like to be working on.

If you have any specific questions related to your profile, feel free to DM us in the Crew Members Slack and we can point out specific things we could do to improve.

Thanks again Filip.

Yes, great to meet this weekend and thanks for the question David!

We have standardized legal agreements in Crew that protect IP for both clients and Crew professionals. These agreements can also be supplemented with additional agreements if one of our members requires it because of company legal policy for instance.

If an issue comes up (e.g. a delay, an issue with a deliverable, etc.), we offer Project Protection, which is a review we organize to determine a fair ruling for any issue that comes up on a project. These issues are rare (we've had 14 out of 2,000+ completed projects) but nonetheless, we want to have a process in place to help our members resolve any issues in the event they come up.

If we've helped connect people to work together, then we also need to do what we can to make sure everyone is happy with the end result, delivered on time and on budget.

Hey thanks so much Stephen!

Most of our side project ideas just start as 1-line ideas. Something popped into someone's head and thought it would be cool. Any idea at this point is fare game, no matter how weird it seems. We store these ideas as the first column in our "Special Projects" Trello board.

When it comes to execution, we aim to do at least 1 project a month that's not within our core product. So when the time comes to choose this project, we look at our 'ideas' column, figure out which idea could have the biggest impact toward what we're focusing on, and we prioritize the building of that idea amongst our other priorities.

Most of the time spent on these ideas is upfront research, figuring out how to pull-off the idea with minimal custom design/dev. We often look to build on top of existing platforms rather than building custom because this makes ongoing maintenance easier. This is why we built Coffee & Power on top of Foursquare rather than as a custom iOS app for example. We've been able to regularly update Coffee & Power and haven't had to worry about app crashes or put anyone's attention toward that.

Eventually, we might move a project to something more custom, but most of our side projects have to prove their worth before we do that. This is what happened with Unsplash. Unsplash started as a Tumblr blog + Mailchimp newsletter. A year later, after we saw the site had grown almost tenfold, we decided it was worth it to build it custom so we could do more with it.

We've never cut the chord on a project. I think this is partly a product of trying to start by finding the simplest way to build something. When you build products that hardly have a scope, it's easier to finish them.

To decide if a project deserves more attention, we watch the data after a project is launched. Usually the numbers make it obvious which projects might deserve more time. But we still assess this 'doing more' against doing a separate, new project. Will the energy/time/focus put toward improving this project the way we want to improve it be equal or greater than doing another project?

Thanks again for the question Stephen :)

Thanks Kevin.

Over the last few months, we’ve gotten better at focusing more on the projects that matter most and saying ‘no’ to others.

I’m guilty of trying to take on too many things at once. When I see an opportunity, I don’t like to let it pass by.

What I’ve learned though is that it’s important to weigh every opportunity, no matter how good it sounds, against all your current ones. If you’re working on something right now that you’ve said is important but then another opportunity comes along (even if it feels important), you need to be able to say ‘no’ or at least ‘not right now.’

You can still store these ideas for later but starting too many things at once won’t help you get anything done faster. It will just distract your already limited attention.

Our latest investor update is a good representation of where we are focusing as a company. Everyone on our team gets this update so we all get a reminder of where our focus is. These updates help guide us toward what we should be building.

To figure out what and what not to build, we constantly prioritize and re-prioritize, picking out projects we think will have the most impact and that we can sustainably take on with our team size and money we have.

We're not a big team but we have a lot of projects going on, so we need to think about where people cross-over on multiple projects, and decide which things to prioritize as a whole. Side projects get prioritized amongst core product priorities. Nothing exists in singularity.

We start by tracking all our ideas but we don't jump on any of them until we understand company priorities. We look at all priorities across the company (including core product, support, side projects, etc.) and figure out an ordered list of projects we want to tackle for the next quarter based on expected impact.

Once we start making stuff, we revisit this priority list every couple of weeks. Often priorities shift, so we've learned it's important for us to have regular points to look at our priorities again and shuffle as needed.

Hey Suganth! Thanks for the questions.

1. What's next for Unsplash? 2 main areas of focus. First, we want to push more exposure to each photographer. We're working on some things to figure out where Unsplash photos end up so we can track and share these with each photographer. And the second thing is starting to include more of the things created with Unsplash photos within the Unsplash community. We don't want to get in the way of the primary utility of finding a photo to use on unsplash.com but we'd like to showcase more of the work made with Unsplash photos and track those back to the original photos. We see Unsplash evolving into a place that not only showcases photos but also the derivative creative work inspired by these photos. We see Unsplash as an eventual showcase of human creativity at work.

2. Can unsplash can get in to a sector of teaching photography in future, probably by the community? Yes, this is something we've started doing a bit. We've had a few of our members host events on photography and we hope to do more of this in the near future.

3. What's that one product/app you can't live without or you use it regularly. Not sure it qualifies as an app but I’d have to say TextEdit. I’ve realized it’s the thing I use and have open the most. I turn it on plain text mode and I feel like I've got a companion for my brain all day long that never begs for attention and is dead simple to use.