Launch HN: Infield (YC W20) – Safer, faster dependency upgrades

Hi HN, we’re Steve, Allison, and Andy, founders of Infield (https://infield.ai). Infield makes it clear which open source dependencies you should upgrade next, and how to do so safely. We do this by using a LLM to read every changelog.

Here’s a short demo video: https://www.youtube.com/watch?v=diCGmtMUeRU

We’re launching today with support for Ruby packages. If you’ve ever run `bundle outdated` or upgraded a Rails app, Infield is for you. You can try it on your own project at https://app.infield.ai/hn. Upload your Gemfile and Gemfile.lock (no email/name/cc required) and we’ll show you Infield on your code.

I (Steve) have been building open source software and commercial web apps for more than a decade. I spent the last year personally upgrading Rails apps by hand for companies in order to research this problem. I'm convinced that every company is re-inventing the wheel and doing by hand a bunch of toilsome work that can be done with software.

As one example, I was working as a consultant upgrading an app to Rails 7. This company was using the attr_encrypted gem to encrypt information at the database level. Rails 7 brings built-in support for encryption in a way that's incompatible with this gem. Having hit this same problem at two other companies I already knew how to handle the migration; but if I hadn’t, they could have risked their most sensitive customer data (this is what you tend to encrypt). After that project I started building a personal database of "upgrade experiences" and before long felt sure we could make useful software.

The time-consuming part of package upgrades is not coding—it’s mostly risk assessment, research, and project planning. If I’m on a maintenance rotation and have half a day to pay down some technical debt, which package upgrades should I look at? I might end up spending that time trying to upgrade something only to get blocked and give up. Worse, many breaking changes are subtle and won’t be caught by CI. I’ve brought down production only to find an issue was buried in a changelog I didn’t read!

Infield scans all of your dependencies to prioritize upgrades based on effort (how much work is this? Is it risky?) and impact (will upgrading fix a security issue? will it get me onto a supported branch?). We can do this because we use GPT to read the changelog for every package you rely on. Changelogs are broken apart into discrete changes and classified according to the keepachangelog.com standard. Then a human expert reviews the output. We can spend more time researching each package than you because we’re going to re-use this work for every future customer doing the same upgrade.

Sometimes you want to do a complex upgrade like Rails that might be blocked on other packages being upgraded first. For this case we run an optimization based on the PubGrub algorithm to solve for a suggested target version of all your dependencies that will be compatible with the next version of Rails. We group and order these blockers into an "Upgrade path" you can follow.

Most of the existing work in this space is security monitoring software like Dependabot or Snyk. These tools are primarily sold to security teams to let you know about CVEs that affect your dependencies. They’re reactive, a way to let developers know when they need to upgrade something but not how to do it. Our goal with Infield is to make it so easy to keep dependencies up to date that you’re always on the latest versions.

Infield is $60/mo/repo and we’re launching today with support for Ruby. Javascript and Python are probably next, but we’re very interested to hear which language you feel this pain in most acutely. Ruby is first since the consolidation around Rails allows us to really nail the experience for a focused set of packages.

You can try Infield on your own codebase at https://app.infield.ai/hn. With the paid plan we’ll hook into your codebase to continuously scan your dependencies as you merge PRs. That works via a Github app, or you can use our CLI tool to send us just the files we need as part of your CI pipeline.

Please give it a try and comments are welcome! We’d love to hear everything you hate (or love, or just think) about dependency management and how we can make it better!