1,399 karma · joined March 25, 2012
I can't stress enough how valuable (from a learning perspective) sales was for Dependabot, but only after I started targeting the right people. For Dependabot that was commenting on open-source dependency update PRs (that people had created manually).
The above would have to change if I started doing serious sales, in which case I’d need a higher number to justify the time involved.
Financially, it's been tough - after 10 months Dependabot makes $2,100 a month (although that's now growing quite fast). I know I'm the kind of personality that couldn't have started it at the same time as working a full time job, though - I need to be really focussed on one thing at a time.
I'll add my own, since I've spent the last year building a little SaaS product (Dependabot): in the early days, nothing beats one-on-one sales. It's not glamorous, but early on you learn so much more from each attempted sale than each time you try a marketing strategy. If you buy facebook ads, blog, etc., then it's hard to tell why customers are engaging with you or not. Don't get me wrong, it's possible, but the feedback you get is so much stronger when it's a sale and you can ask the other person straight up.
I did the above (after failing at every other marketing strategy) with Dependabot when we were literally giving it away and it made a huge difference to the product and our user numbers.
Technically, getting something that's polished enough that other people can use it is a higher bar than having something that works for you. In particular, you need to think about:
- Error handling (i.e., non-happy path flows). Your users won't be able to see your logs / error reporting emails, so their experience is different to your own one.
- UI. Your users won't know how they're meant to use your product, because they didn't build it. They'll have a much harder time figuring out how to use it than you do.
- Robustness (i.e., bugs). Once you have lots of people using your product, they're going to start surfacing lots of bugs you didn't know existed. They're also going to start using the product in ways that you yourself don't. You'll need a robust test suite to ensure you don't have to load all of the additional context into your head each/every time you make changes.
Beyond that, getting 1,000 people to use your thing is going to need some thinking about distribution:
- You almost certainly want to start with "sales". Even if you're giving your thing away for free. You'll learn more, faster by contacting people individually and trying to persuade them to use your thing. You'll also see a more predictable growth in users, and save yourself from getting depressed about botched launches / blog posts that no-one reads.
- Later, you need a growth engine just like any business.
There are lots of great interviews on IndieHackers (https://www.indiehackers.com/businesses) that might help with the above. My own personal experience is from building Dependabot (there's an interview on there from me!).
A fully rational company should be thinking "what do I have to pay to get the work I need doing done?" If that work can be done remotely then that optimisation works out as:
- Who can I hire in low cost locations and pay less for, without sacrificing quality (which I'm using VERY broadly to represent ANY differences in the work, team interactions, etc.).
- If I can't hire enough of those, fast enough, how much am I willing to pay in high-cost locations.
In the short term, when the company is trying to hire fast, talent is scare globally, and the company isn't connected to all global talent pools (so struggle to hire there) a sensible optimisation is salaries adjusted by location.
In the long term, as the company has time to build its remote brand and (if) its hiring requirements stabilise, a sensible optimisation will be work leaving high-cost centres like SF.
Don't feel too sorry for people in low-cost centres who work gets redistributed to at a lower cost - in the long term work from the high-cost centres is shifting to them, unless there are quality reasons for it to stay in the high-cost areas.
http://engineering.appfolio.com/appfolio-engineering/2015/11...
The biggest difference to Gemnasium is that we’ll creat the update PRs for you automatically. The biggest difference to Greenkeeper is that we handle lockfiles out of the box and give you compatibility scores for each update. We love both services, though!
And yes - totally agree!
Has had some real highs (a Japanese customer emailing who wanted stickers!) and some real lows (getting 1 signup the say we "launched").
Would love feedback from anyone!
The core of the project, which is all the logic for actually doing the dependency updates, is open source at https://github.com/dependabot/dependabot-core