greysteil

Big +1 for this.

The only criticism I have of Indie Hackers is that sometimes discussion can get a little spammy (lots of people looking for early adopters). Not every conversation is like that, but some posts are.

As someone building a startup on their own (full time) I've found Indie Hackers a really supportive community. The stories there are often relatable, and far less sensational than typically seen places like HN. If you're going through the daily grind of trying to grow a small business / startup then it's a good place to drop by every now and again to help stay sane.

The version resolution algorithm is very similar to NuGet's "lowest applicable version" logic, which has been around since 2010. I've seen surprisingly little discussion of the fact they're so similar.

https://docs.microsoft.com/en-us/nuget/consume-packages/depe...

This is about to get better - check out https://github.com/pypa/pipenv/pull/3304.

You might want to check out https://github.com/pypa/pipenv/pull/3304, which Dan is actively working on to solve that.

FWIW, resolution in Python is significantly harder than for Ruby, JS or Elixir because it requires cloning down each dependency. To really speed it up, what's needed is a registry API that provides all of the details for resolution. That's much harder for Python because of the legacy of setup.py, which allows version resolution to depend on arbitrary system considerations.

Sometimes, improvements don't happen in a straight line.

There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release.

If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are committed and doing a great job.

Haha, thanks, I guess that's one place where Dependabot shows its side-project roots - I just want as many people to use it as possible, and am less fussed about capturing the biggest share of value.

About 6 months and it was tough!

2 months of that (part time) was the initial build and the rest was hustling to get initial users. GitHub wouldn't put it in the GitHub Marketplace (which drives pretty much all signups now - I don't do any marketing or sales) until it had 250 users and it was a struggle getting the word out to that many people. In the end I did it by commenting on relevant open source PRs on GitHub asking if they'd be up for giving it a try (being really careful not to be spammy).

I built https://dependabot.com to be passive, but ended up going full time on it (the startup I was working on feel through). Generates $9k/month passively, but I put my full-time energy into growing it (adding new languages / improving support for existing ones).

This is exactly what we do with Dependabot. We have support for dep right now (along with other languages) and will be adding modules support in the next few days.

I had a similar experience getting Dependabot onto the front page of HN as a "Show HN"[1], all be it with less attention than this post (congrats on that!).

- Made it to #10 or thereabouts, and hung around on the front page for ~2 hours

- Got around 10 (free) signups directly from it on the day. At the time we were averaging 10 signups a day, so it doubled that day's attention

- Lots of encouraging feedback, which was great, and a good gauge of what (very) prospective customers might be interested in. No substitute for the learning from direct "sales", though (even when giving the product away for free)

- Harder to measure the long-term awareness effect, but people very rarely mention they saw Dependabot on HN (they're much more likely to have seen it working on an open source repo)

- Getting onto the front page was hard work! You can see from my submissions[2] how many times I tried!

Overall my advice to anyone with an indie app would be to do the hard work of selling / building word-of-mouth referrals. Working on marketing-style blog posts looks easy and effective when you see others doing it, but very few people talk about the numbers that come out of it, and all of the "misses" where your content isn't picked up at all.

-----

[1] Original post: https://news.ycombinator.com/item?id=15953694

[2] My submissions: https://news.ycombinator.com/submitted?id=greysteil

So much love for everyone who received an "accepted" email in error. Don't let it get you down.

I just got rejected with https://dependabot.com despite $6k MRR and 2,000 active users. I'm sure there are lots of other great companies in the same situation - let's keep building great things.

Thanks Kacy! Had been looking forward to having others to learn from, but I'm pretty confident that Dependabot is going to be OK.

Would love to hear from all the companies that got accepted!

Getting to $200k ARR is an amazing achievement, particularly in just one year and without funding.

I can't advise you on pursuing an acquisition, but I'm in the same boat as you - I run a one-person company making $65k ARR after 16 months of hard labour. I know how tough it is doing it on your own, and how easy it is to question yourself when you don't have the external validation of an employer, investors, etc.

Are you sure you wouldn't be better sticking with it? After a year of working on something on your own all of your biases will be towards selling - if you're not sure then it's almost certainly the wrong choice. Have you looked at doing something like YC / Startup School, even if you don't want to take investment? Having any kind of external validation will help. You should also almost certainly take a few days off and recharge, if you haven't already - I find it hard to do that but whenever I do it helps.

So much this. If you want to build a business then there will be a lot of non-technical things to learn along the way. Keep the tech familiar so you can focus on those.

One of the nicest additions to the GitHub Marketplace is a bot that will optimise your images automatically: https://github.com/marketplace/imgbot

(No connection to me - just think it's a great idea, and totally free.)

FWIW, I'm not sure I'd recommend that. For things outside your control, you've got to deal with the world as it is, not how you would like it to be. Slack own the game for chat bots right now - I think the advice you got from Des Traynor to double down on it is spot on.

Before patents, copyright law, and all that, secrecy was the only way to stop people copying your stuff. That was kinda crappy, and people went to great lengths to obfuscate their IP, expending lots of effort on something that had no benefit for their customers / the world.

Intellectual property law changed that - it made it possible for people to openly disclose their inventions whilst maintaining control of them (normally with some conditions). It was a really, really good thing for society, as it dramatically increased the returns to "thinking work".

I can probably dig out a link if you're interested.

That's not what I'm saying, and I don't think I'm spreading any falsehoods about free software licenses here.

Building a business is about distribution as well as product. My product is pretty good, but my distribution, compared to a large player with an existing user base, is woeful. If I licensed under GPL I would be giving explicit legal permission to any big player (who was open source) to take my product for free, and compete with me solely on distribution.

Licensing my product in the above way wouldn't be good for me financially, and as a result would decrease my likelihood of working full time on Dependabot. Worse still, it would disproportionally decrease my returns from working on the product, as opposed to distribution.

Thanks to copyright law we don't need to hide our codebases in order to charge for our work. That's a great thing, and there should be acceptance of code that is developed in public but without a permissive license. It's a perfectly rational decision, and creators shouldn't be put under pressure to give their development work away for free instead.

Totally agree on licenses and transparent pricing in general, but I think you've missed the context here.

If a commercial entity wants to add the core functionality of my product to their offering then there's definitely going to have to be a negotiation first. AGPLv3 wouldn't be appropriate, as the commercial entity's code being open source isn't a material consideration for me.

(The license text I was referring to is here: https://github.com/dependabot/dependabot-core#license. I could hire a lawyer and put a proper, proprietary license on the repo but I'm bootstrapped and don't think it's necessary.)

Great blog post - thanks for writing it. I've had the same experience with people asking for an MIT license on dependabot-core (the public repo that holds the core logic for my SaaS business, but which has no license and a comment saying those who wish to use it for commercial gain should contact me instead). I already give the product away for free to open source projects and anyone using it in a personal capacity, but for a small number of people that's not enough.

Free software is a wonderful thing - it's fantastic that our community shares its work so widely and generously. It is not, however, the only, or the best, model for creating innovation at all times. I'm able to work full time on Dependabot because by providing it as SaaS I can pay myself a wage and by owning the codebase I can protect myself from a larger player copying my work. There's no doubt in my mind that enabling me to work on the product full time is a better outcome for the world than a license that would let others distribute and profit from it.

For us (Dependabot) the best advice I ever got was that your initial customers should come from sales, not marketing, even for a really low-price SaaS product. I was literally giving Dependabot away for the first 6 months of its existence, but I was still doing concierge sales on it.

When you sell to customers directly you get to hear their reactions and get a much better sense of what's valuable to them. You also make yourself more approachable if/when they've got feedback down the line. Finally, you get a predictable return to your effort (even if it's low!), which prevents the kind of boom and bust that can burn you out in the early days.

I'd really, really highly recommend anyone else looking to start a B2B business take the same approach, even if your product is way too cheap for sales to be scalable.

Seriously? Where is the “congratulations” message?

You’re totally right - I was thinking of Composer, which does flat resolution for git sources so has to go through the above. Cargo sidesteps that issue completely by taking the head commit or whatever’s asked for :-)

Cargo performs dependency resolution, so fetching from git would (and does) significantly slow it down - it wound need to perform git operations to get the tags for each dependency (quick) and then checkout each tag to look for the subdependencies of that package at that version (slow).

Having a central registry is a must for package managers that perform version resolution and want to do so quickly, as it can serve them all the metadata they need to do that resolution.

I worked with @iarna over at npm to get a very similar bug fixed - https://github.com/npm/npm/pull/20198. I'm pretty sure this is just a special case of that bug - if you're not on npm 6.1.0 it might be fixed there. Otherwise I'd encourage you to comment in on that PR / the attached issue with a flow to reproduce.

I built Dependabot to automate keeping dependencies up-to-date / responding to security vulnerabilities at GoCardless. Spun it out into its own business. https://dependabot.com

My best automating stuff story, though, is automating complaint letters to UK banks. We were pushing the limits of what the UK's Direct Debit system can handle, and as a result were seeing all the edge cases where banks got it wrong. One common one was banks accidentally charging back a payment twice, and each bank had their own, totally bespoke complaints procedure for getting in touch when that happened.

A couple of engineers and me spent a couple of days integrating with Lob and a fax provider whose name I forget to automatically write complaint letters every time the banks screwed up. Some of these were being sent to named individuals for all Direct Debit complaints related to RBS, for example.

Needless to say, the banks fixed the problems that were causing us to need to complain soon enough. :-)

That’s normally an option for your manifest file (e.g., a Gemfile or package.json), but most production applications also (sensibly) use a lockfile. Updating the versions in that lockfile is what Dependabot is great for.

A qualified "yes".

Dependabot has ~100 paying customers, and makes just over $2,000 a month. It's still quite a lot of work adding new features, but if I wasn't extending it's functionality it would be passive income.

Personably have raised money and landed some big paying customers - I think there's scope for them to be solving a relatively large problem, having started from a duct-tape fix.

The only proviso I'd add to the article is that sometimes the problems you find like this are small. Dependabot will never be a full-blown startup - it's scope is too small. That's not necessarily a bad thing, though - I think the problem has still been well worth solving thoroughly.

https://dependabot.com https://personably.co

This is exactly what led me to build Dependabot - dependency management was a minor pain at my old job that we'd written some scripts to handle better.

Another group of friends started Personably from exactly the same strategy - we had a script to create dozens of calendar invites for new joiners with all their onboarding details, so things didn't get missed.