ShipFoundry is live for agentic builders

I’ve technically been trying to launch ShipFoundry for the past month and a half.

Every time I got close to the finish line, I would do one more full start-to-finish run, find another place where the product sounded confident without actually knowing enough, and turn around to fix it.

At some point, “one more QA pass” became a hostage situation.

But for this product, it paid off.

Because I’m dogfooding ShipFoundry against my own products, I know when a recommendation is bullshit. I know the repository, the architecture, the adjacent packages, why certain workarounds exist, and whether a vendor update actually fits the product or merely sounds vaguely relevant.

That is an annoying superpower when you are trying to get something out the door.

It is a very useful superpower when the entire value of the product depends on knowing the difference between a real opportunity and a plausible-sounding waste of time.

The Stack Is Accelerating

Coding agents have dramatically changed how I build software.

My agents write most of the implementation code now. I still decide what should exist, connect the context, review the output, test the product, and decide what ships - but raw implementation is no longer the bottleneck it used to be.

The same acceleration is happening everywhere underneath the product.

Frameworks, runtimes, databases, SDKs, APIs, auth providers, billing platforms, observability tools, deployment systems, and AI infrastructure are all shipping faster.

Some gains arrive automatically. You update a package, or a provider improves something behind the scenes, and your product benefits without much effort.

A lot of gains do not.

A new SDK can eliminate custom glue. A runtime can replace a clunky dependency. A platform feature can remove an old workaround. A better API can lower token burn, simplify a route, reduce infrastructure cost, improve reliability, or unlock a product capability that was not practical a month ago.

But those gains only matter if you know they exist, determine whether they apply to your product, and actually absorb them.

Otherwise, the improvement just sits there idle in your stack while your product completely misses it.

And attention is finite. Reading every changelog is not a strategy.

The Existing Options Are Not Enough

There are already plenty of dependency tools. They are useful. They can tell you that a new version exists or that a package is outdated.

That is not the same as telling you:

• whether the change applies to your product;
• whether you already have the capability;
• whether the likely payoff is worth the lift;

The other option is to live on X, Hacker News, vendor blogs, launch posts, release feeds, and documentation pages.

You will see a lot of updates, and you will also spend an enormous amount of time determining which vendor announcements matter for your product.

What ShipFoundry Does

ShipFoundry watches the tools behind your product and creates a project-specific decision loop around their updates.

Each project has a Watchlist. That defines the stack ShipFoundry is actively monitoring for your product.

When a meaningful update lands, ShipFoundry breaks it down to the meaning and potential range of the update and plays it against the project context. It then uses the required read-only GitHub connection to look for applicable evidence in the current repository that this is applicable or an unlock depending on your current implementation, architecture, related packages etc.

It checks the things that make the difference between an interesting release and useful product work and then makes a call on what you should do next.

The result can be a range of relevance and potential to your product, from the coveted Big Unlock to a smaller but useful improvement, something that needs one specific answer from you, or categorized as no action at all.

That final category matters as much as the unlocks.

I do not want a system that turns every vendor launch with non applicable updates into a task. I want a system that is just as good at saying:

“This does not apply to your project. Don’t waste focus on it.”

When an update survives the evidence check, ShipFoundry turns it into a handoff: a Research Brief, an Engineering Spike, a quick win, sometimes as small as a configuration option you did not know existed, or an implementation-ready handoff with affected files, source context, risks, constraints, suggested direction, and acceptance checks.

You can work entirely from the dashboard. You can copy the brief into the agent you already use. You can connect to our Linear integration for your own internal flows. Or you can connect ShipFoundry through MCP and let Codex, Claude Code, Cursor, OpenCode, or another compatible agent use it as a project-aware work queue and report the result back.

ShipFoundry’s live workflow today is the dashboard, copyable handoffs, MCP, and Linear.

Why the Naive Version Was Not Good Enough

The earliest versions of ShipFoundry could do the obvious part:

This product uses X. X shipped Y. Maybe Y matters.

That is a starting point.

But it is not a useful recommendation.

A package being installed does not prove a feature is used. A configuration file does not prove the implementation needs to change. A broad React match should not authorize a recommendation about every React-adjacent package. A vendor claim should not become an engineering task just because an LLM can write a convincing paragraph about it.

ShipFoundry now builds bounded structural and semantic context from the selected repository. For an individual update, it runs a focused investigation against the current commit, reads the relevant files and snippets, extracts applicable import, route, symbol, and call-site facts, grades the evidence, and reconciles that evidence into the final recommendation.

It does not simply throw the entire repository into a prompt and ask a model to vibe.

The evidence system deliberately distinguishes package or configuration context from real implementation proof. Direct handoff readiness requires current repository evidence and final synthesis agreement rather than a broad technology match.

That difference sounds technical.

In the product, it is the difference between:

Bun upgraded to 1.3.14. You use Bun. Use it.

And:

This repository uses Sharp in these image-processing paths. This update among other improvements includes Bun.Image which may replace part of that path for potential runtime, dependency, and deployment improvements. Inspect these files first. Verify format support, output parity, deployment behavior, and performance comparison before removing the dependency and switching usage.

Bun 1.3.14 and Bun.Image was one of the recommendations that made the product click for me.

ShipFoundry connected the release to a real Sharp-based image path in one of my products and turned it into a concrete investigation instead of a generic upgrade suggestion.

It did not silently replace Sharp. It did not promise a performance win it had not measured. It found the exact opportunity, the relevant files, the likely payoff, and the checks required to decide whether the migration was actually worth it. That was then more than enough to hand off to an agent to do full-depth discovery, comparison and implementation.

That is the product.

The Decisions Matter Too

ShipFoundry also records what happens after the recommendation:

Useful. Shipped. Dismissed. Not relevant. And why.

Those outcomes matter because the same update can be valuable for one product or type of organization and useless for another.

The more decisions you record, the more ShipFoundry can use the project’s history, priorities, and previous outcomes to become useful for the way you or your team works.

What ShipFoundry Is Not

ShipFoundry is not another release-note feed.

It is not a dependency bot.

It is not an “upgrade everything” machine.

It does not write to GitHub, create commits, or open pull requests. The GitHub App is read-only. You remain in control of whether to investigate, ship, defer, dismiss, or mark an update irrelevant.

ShipFoundry is the judgment layer between the stack that keeps accelerating and the agents that can turn the right changes into product work.

What Is Live Today

ShipFoundry is publicly available now.

Both plans include the full core product: the dashboard, daily update matching, required read-only GitHub evidence, evidence-backed handoffs, MCP, and Linear integration.

• Dev is $9/month for one project and 10 tracked stack items.
• Pro is $29/month for up to three projects and 60 tracked stack items shared across the account.

Both begin with a seven-day trial. A card is required because the trial performs real repository indexing, update analysis, and AI-backed investigation rather than unlocking a static demo.

For launch, use code SHIPFOUNDRY for 30% off the first two paid months.

A selected GitHub repository is required because the product simply was not good enough without it.

I tried.

Removing the repository also removed most of what makes the matching and recommendations trustworthy.

MCP and Linear are optional. You can use the dashboard and copy a brief directly into your agent without connecting either one.

I am also launching Signals - ShipFoundry’s public judgment feed for meaningful stack updates: what changed, who should care, who should not, and the verdict before you give the update any more attention.

Try It Out

Connect your product and see whether ShipFoundry finds one useful change this week that you otherwise would have missed - or saves you from wasting attention on five updates that do not actually matter.

Then tell me where it is wrong.

The entire engineering stack is accelerating around us.

Your product should accelerate with it.