Since.dev

Self-repairing software for a world that never stops changing.

Since.dev is building self-repairing software for a world that never stops changing.

Modern software depends on APIs, SDKs, packages, and AI models that evolve independently of your code. A service changes its behavior, an endpoint disappears, a model gets retired—and software that worked yesterday can fail without a single commit.

We close the gap between what changed outside your code and what needs to change inside it. Since monitors external dependencies, assesses their impact on your repository, and prepares targeted repairs as draft pull requests. Your existing CI checks the changes, and your team decides what ships.

For AI agents, Since delivers the same change evidence through API, MCP, and webhooks, helping them work from current information instead of outdated assumptions.

Our mission is to make adapting to change a built-in capability of software, so keeping it working takes less human intervention.

About Since.dev

Since.dev is a development product listed on Uneed, with a free tier and paid plans. It's tagged with CI CD, Testing. See the best CI CD products for related options.

Frequently asked questions about Since.dev

What is Since.dev?

Since.dev is self-repairing software for a world that never stops changing.

Is Since.dev free?

Since.dev offers a free tier with paid plans available for additional features.

What are alternatives to Since.dev?

Discover similar ci cd, testing, api & data products in the Uneed directory.

What category does Since.dev belong to?

Since.dev is listed under Development on Uneed.

What users say about Since.dev

SpinHire
The failure mode that costs us most is not the one where an endpoint disappears. We run a crawler over dozens of job boards every six hours for an iGaming index of about 6,700 postings, and the expensive breakages are the quiet ones: the response still returns 200, the selector still matches something, and we get forty jobs instead of four hundred, or the same four hundred with the salary field silently empty. Nothing throws, CI stays green, and we only catch it when a weekly number looks off. Hard breaks we find within the hour. The other half of what we depend on has no release to watch at all, like an undocumented JSON endpoint some frontend calls or plain HTML that gets rewritten without notice. Does Since treat those as dependencies as well, or does it need a versioned surface with a changelog before it can tell me something moved?

Read all 1 review

User reviews

SpinHire@spinhire · Sep 22, 2026

The failure mode that costs us most is not the one where an endpoint disappears. We run a crawler over dozens of job boards every six hours for an iGaming index of about 6,700 postings, and the expensive breakages are the quiet ones: the response still returns 200, the selector still matches something, and we get forty jobs instead of four hundred, or the same four hundred with the salary field silently empty. Nothing throws, CI stays green, and we only catch it when a weekly number looks off. Hard breaks we find within the hour. The other half of what we depend on has no release to watch at all, like an undocumented JSON endpoint some frontend calls or plain HTML that gets rewritten without notice. Does Since treat those as dependencies as well, or does it need a versioned surface with a changelog before it can tell me something moved?

View

nabuhadAuthorSep 22, 2026

Since can already watch publicly readable pages without a version or changelog. But it doesn’t currently validate your crawler’s output, so I wouldn’t promise it would catch 400 jobs dropping to 40 or salaries quietly becoming empty.

Undocumented JSON response contracts and those data quality checks are gaps today. I’ve added them to the roadmap: monitoring JSON and HTML structure, plus per-source counts and field completeness. The important part of your example is catching incomplete results even when the request succeeds and the selector still matches.

SpinHireSep 24, 2026

@nabuhad thanks for the straight answer, that is more useful than a yes. Per-source counts would already cover most of our pain, because the drop from 400 to 40 is only visible against that source's own history, not against a global threshold. The part I would think hard about is the baseline: our sources are seasonal, a board can legitimately halve before a big conference and then recover. When you build it, do you plan a fixed floor per source that the user sets, or a baseline learned from the last few weeks of runs?