DEV Community: Maryan K

Weekly Startup Engineering Signal Report: 2026-08-20

Maryan K — Mon, 31 Aug 2026 20:10:30 +0000

Originally published on VC Deal Flow Signal.

This is the weekly engineering-signal report from VC Deal Flow Signal (signals.gitdealflow.com). It ranks startup engineering acceleration from public GitHub activity, a leading indicator of fundraise announcements by 3-6 weeks.

Top movers this week

The fastest-accelerating startups in the 350+ tracked panel:

Startup	Stage	Geography	14d velocity change	Signal
liberusoftware	Seed	UK	+3275%	Engineering hiring burst
untrustedmodders	Pre-seed	Unknown	+2900%	Deploy frequency spike
fleetbase	Pre-seed	APAC	+1600%	Engineering hiring burst
aphp	Pre-seed	EU	+999%	Infrastructure buildout
StanfordSpezi	Pre-seed	US	+999%	Deploy frequency spike
ere-health	Series A/B	EU	+999%	Deploy frequency spike
epic-open-source	Seed	Unknown	+999%	Engineering hiring burst
insightsengineering	Seed	EU	+999%	Deploy frequency spike

Sector activity

The 15 tracked sectors, ranked by startup count:

Web3 - 42 startups
Gaming - 39 startups
EdTech - 37 startups
Data Infrastructure - 35 startups
Enterprise SaaS - 31 startups
Robotics - 28 startups

About the data

Panel: 350+ startups, refreshed every Monday.
Period: Q3 2026.
Methodology: https://signals.gitdealflow.com/methodology
Free JSON and CSV: https://signals.gitdealflow.com/api/signals.json

Citation: VC Deal Flow Signal (signals.gitdealflow.com), Q3 2026 data.

Use the live data without a dashboard

The weekly table above is generated from the same public endpoint. Here is a direct shell check:

curl -s https://signals.gitdealflow.com/api/signals.json \
  | jq '.trending[:3] | map({name, signalType, commitVelocityChange})'

For an AI client, run the MCP server locally:

{"mcpServers":{"vc-deal-flow-signal":{"command":"npx","args":["-y","@gitdealflow/mcp-signal"]}}}

Then ask: "Which startups are accelerating fastest this week?" Both examples read the live public dataset. They do not make a funding prediction.

I Made Valet Damage Provable With GPS, Dual Timestamps, and SHA-256

Maryan K — Fri, 14 Aug 2026 11:07:10 +0000

I Made Valet Damage Provable With GPS, Dual Timestamps, and SHA-256

When you hand your keys to a valet and the car comes back with a scratch, the burden of proof is on you. A photo you took on your phone is almost useless: there is no proof of when or where it was taken. I built CarShake to turn a before-and-after photo into a record that is hard to argue with.

The three layers of evidence

GPS. Every photo is stamped with where it was taken, so "that scratch was already there" meets "here is the geotag at the valet stand".
Dual timestamps. One from the device, one from the server. Timing that does not depend on a clock you could have set.
SHA-256 hashing. Each photo record is hashed and stored immutably, so once a record exists it cannot be edited later, by you or anyone else.

The before-and-after flow: photograph all four sides, wheels, windshield, and any existing damage before you hand over the keys. Repeat when you get the car back. A computer-vision pass flags new dents and scratches you might miss in bad light.

The "Instant Proof" trick that gets people in the door

The full product is a guided before-and-after capture. But there is also a free Instant Proof tool that just stamps date, time, and location on any photo in about thirty seconds. That single feature is the distribution: it is useful on its own, with no account.

Pricing is deliberately boring

The core capture flow is free. A $7 premium kit adds a printable checklist, a twelve-month photo log, and a shareable verification report. One-time, not a subscription. 200+ drivers have signed up for the free checklist.

This is a small, honest product for a specific fear: being charged for damage you did not cause. If you build in the evidence-integrity space, the lesson is that the boring parts (timestamp, geotag, hash) are the whole product.

I Bundled 5 AI Tools Into a $0.97 System for Building a Side Income

Maryan K — Fri, 14 Aug 2026 11:06:12 +0000

I Bundled 5 AI Tools Into a $0.97 System for Building a Side Income

The founder who wants a side income has a stack of problems that are all the same shape: how much do I actually need, what do I build, is this allowed under my contract, how do I launch, and how do I market it without it becoming a full-time job. I built Invisible Exit as five connected tools for those five questions.

The five tools

A freedom-number dashboard. Your recurring revenue, churn, and growth against the number you actually need to reach.
An idea pipeline. Hundreds of micro-SaaS ideas scored by fit, time investment, and revenue potential.
A compliance hub. Entity separation and a check against common contract clauses, non-compete and IP assignment.
Launch control. Stripe, landing page, and a launch sequence.
A brand builder. Content and audience playbooks that do not require your face or your real name.

One subscription, all five. The founding price is $0.97 a month.

The part I get asked about: "is this allowed?"

The honest answer is that it depends on your contract, and the product is built around that fact. The compliance tool is there specifically to check your own agreement before you start, and to keep the business in a separate structure. I am not going to tell you to break a non-compete. I built a tool that flags the risk so you can decide with your eyes open.

The math that anchors it

The target is concrete: a $29/month micro-SaaS with about 138 customers is $4,000 a month in recurring revenue. That number is what the whole system is organized around. If you do not reach $4K/month within twelve months, there is a refund.

This is a niche product for people who want an exit ramp, not a get-rich promise. The honest version is "five tools, one low price, and the work is still yours to do."

I Shipped 12 Products Nobody Paid For. The Fix Was a Playbook, Not More Code.

Maryan K — Fri, 14 Aug 2026 11:06:06 +0000

I Shipped 12 Products Nobody Paid For. The Fix Was a Playbook, Not More Code.

This is a build-in-public confession. I shipped twelve products that nobody paid for, and spent a year convinced the problem was traffic. It was not. The problem was that I never did the uncomfortable work: name one real person, make one real promise, and send one real message.

The product is the playbook, not another course

Unlock SaaS is a web app, not a Notion template, and not a course. It is a seven-step playbook engine for the post-launch, pre-revenue founder. It pushes back on vague answers until three things exist: one named real person, one real offer, one real outreach message. It tracks the work in software instead of in your willpower.

The reason it is software and not a PDF is specific: the avoidance option has to be removed. A template you can close is not a plan. A tool that shows you step four is unfinished, and step one was never done, is.

The guarantee is enforced by code

Day 60 is when the guarantee fires. If you did the work (steps one through five done in product, twenty outreach actions logged) and your Stripe line is still zero, the refund runs automatically. No support ticket, no "we will review your case". I built the refund into the engine because a guarantee that requires a human to approve it is not a guarantee.

Who this is for, exactly

The founder who shipped something real with Lovable, Claude, Replit, or Bolt. Users signed up. Nobody paid. They are starting to think the product is the problem. It is not. The problem is the work nobody taught us to do.

The founding price is $49/month for life, and it closes at 100 builders. If you are in that post-launch flatline, the honest question is not "how do I get more traffic". It is "have I named one real person and made one real promise". Most of us have not.

I Built an AI Employee That Files Invoices and Refuses to Guess

Maryan K — Fri, 14 Aug 2026 11:04:43 +0000

I Built an AI Employee That Files Invoices and Refuses to Guess

The "AI agent" promise got way ahead of the product. Nika is the opposite: a deliberately narrow AI employee that does one job, files invoices, and is designed to stop and ask rather than guess.

Why an "employee" and not an app

The founder who still does their own bookkeeping does not need another dashboard to learn. They need the invoices handled. So Nika is positioned as an employee you hire in five minutes. She watches a mailbox, pulls every invoice, files it into your records, and asks before she ever guesses.

You pay per finished invoice, $0.40, and $5 gets her started. No subscription, no card required to look around.

The one design decision that matters: ask, do not guess

Every AI bookkeeping demo shows a model confidently extracting a supplier name and a VAT number and being wrong. The interesting engineering problem is not extraction, it is confidence. Nika routes anything she is not sure about to a human with a specific question, instead of filing a guess.

A filed error is expensive to unwind. A held item waiting for an OK is cheap. The copy on the site says it plainly: "Anything she isn't sure about waits for your OK." That sentence is the product.

Per-task pricing instead of seats

A part-time bookkeeper for four hours of weekly invoice work does not justify a salary, holiday, and training. Per-finished-task pricing matches the actual job: it is four hours a week, not a role. No work done, no charge.

What is live and what is not

Nika is the only live employee today. The site teases more employees (a speed-to-lead caller, a win-back agent, a review manager), but those are clearly marked "coming soon", and I will not pretend they are shipped. One real employee doing one job well is the honest version of this product.

The stack is a Next.js app with a three-language site (English, Greek, Ukrainian). If you are building an "AI agent" product, my advice is to shrink the scope until the agent does one verifiable job and nothing else. That is where the trust is.

I Turned Spoken Construction Reports Into Court-Ready Evidence

Maryan K — Fri, 14 Aug 2026 11:04:40 +0000

I Turned Spoken Construction Reports Into Court-Ready Evidence

Subcontractors lose money because their documentation is paper. A general contractor asks "prove you were on site Tuesday", and the sub is holding a crumpled notepad. I built VoiceLogPro to fix that: you talk through your day on site, and it becomes a timestamped PDF that holds up when a payment is disputed.

The problem is evidence, not convenience

A daily construction report matters for exactly one reason: it is contemporaneous evidence. When a mechanic's lien or a delay claim reaches a hearing, the question is never "did you keep nice notes". It is "can you prove, with a dated record, that you did the work and flagged the delay when it happened".

Paper fails that test. So do most apps, which are built for project managers behind a desk, not for an electrician holding a phone in one hand and a drill in the other.

VoiceLogPro is voice-first on purpose. You speak the report: weather, crew, work performed, materials, any delay or change order. The app turns it into a structured PDF with those fields filled in. No typing on a jobsite.

What "court-admissible" actually means in the code

Three things, and they are boring on purpose.

A timestamp. The report is stamped when you record it, not when you export it later. That distinction is the first thing a lawyer asks about.
Fixed fields. Weather, crew, work performed, materials, delays. Every report has the same shape, which is what makes it comparable across days and defensible as a series.
A PDF you can hand over. Not a link, not an app someone has to log into. A file that can be attached to a claim.

I did not try to build another Procore or Raken. Those are project management platforms. VoiceLogPro is a documentation defense for the trade subcontractor who needs to get paid.

The $40,000 story behind it

The dream customer is an electrician running three crews. Last year he lost about $40,000 because his documentation was paper and a general contractor knew it. That is the whole pitch. I am not selling productivity. I am selling proof.

Where it is now

It is a $49/month crew plan, live at voicelogpro.com, with a waitlist for beta. The site also carries state lien-law guides (Texas Chapter 53, California 20-day preliminary notices, and others) because the documentation and the legal deadline are the same problem. A report filed a day late is a report that does not protect your lien rights.

If you build anything for the trades, my one piece of advice: build for the phone in one hand, not the desk. The jobsite decides what actually gets used.

The 52-Point GitHub Due Diligence Checklist I Use Before Every Seed Investment

Maryan K — Fri, 14 Aug 2026 08:51:22 +0000

Most VC due diligence checklists focus on financials, legal, and market size. They miss the single most honest signal a startup has: its GitHub.

A pitch deck tells you what the founders want you to know. Their Git history tells you what they actually did.

After analyzing GitHub data from 219 funded startups (paper here), I built a 52-point checklist. Here it is, free.

Why GitHub matters in due diligence

Three things show up in code that never appear in a deck:

Actual shipping velocity (not claimed velocity)
Team health (are contributors leaving silently?)
Infrastructure maturity (are they building for scale or winging it?)

The checklist (abridged)

Repository health (12 checks)

Commits in last 30 days?
No abandoned repos (>90 days inactive)?
README and LICENSE present?
CI/CD workflows configured?
Branch protection enabled?
PR merge rate >50%?
No critical CVEs in dependencies?
SECURITY.md present?

Commit velocity (8 checks)

Weekly commits stable or increasing over 90 days?
No sudden drops >60% week-over-week?
Commit messages follow a consistent pattern?
Night/weekend commits (genuine engagement)?
No suspicious bot-generated patterns?
Velocity correlates with claimed headcount?
Spikes align with claimed milestones?
Compare to sector benchmarks

Team signals (10 checks)

More than 3 active contributors in last 90 days?
Contributor count growing quarter-over-quarter?
No mass contributor exodus (>40% drop)?
Key engineers have LinkedIn profiles matching GitHub?
CTO/founder still commits code?
No ghost contributors (empty profiles)?
Bot accounts labeled and scoped?

Infrastructure buildout (8 checks)

CI/CD pipeline configured (GitHub Actions, etc.)?
Containerization present (Dockerfile)?
Infrastructure-as-code (Terraform, Pulumi)?
Monitoring/observability configs present?
Staging environment exists?
Feature flags configured?
API documentation published?

Security posture (6 checks)

Dependabot or equivalent enabled?
No public secrets/keys in commit history?
2FA enforcement visible?
Code scanning (CodeQL/Semgrep) enabled?

Product-market fit signals from code (8 checks)

Rate of new feature branches increasing?
Customer-facing repos (SDKs, integrations) active?
Localization efforts in code?
Billing integration present and current?
Database migration scripts (real product evolution)?

How to use it

Run this checklist against any startup's public GitHub before the pitch meeting. Most of it can be automated using the GitHub API.

I track 350+ startups across 15 sectors automatically at VC Deal Flow Signal, which scores each startup on engineering acceleration and flags when signals spike before a funding round.

The sector benchmark trap

Don't compare a Healthcare startup to a Developer Tools startup. Developer Tools companies ship 2.3x more than Healthcare. Always compare within the same sector.

Here are median weekly commits by sector (Q2 2026):

Sector	Median weekly commits
Developer Tools	89
Data Infrastructure	52
Web3	56
AI/ML	47
Enterprise SaaS	38
Fintech	34
Healthcare	22

Full sector breakdown with 350+ startups is at signals.gitdealflow.com.

The honest part

My first 10 pre-registered predictions went 0-for-10. I published that result anyway. The methodology improved. The current backtest covers 219 fundraises.

The point isn't that GitHub signals are perfect. They're a leading indicator that gives you 30-47 days of runway before a round is announced. Use it to get in early, then verify with traditional diligence.

Full methodology and the 0-for-10 transparency ledger: SSRN paper.

The full 52-point checklist is also on GitHub: vc-due-diligence-checklist.

The author runs GitDealFlow, a GitHub-powered deal flow intelligence tool. All data and methodology are open. CC BY 4.0.

I Tracked 350 Startups' GitHub Activity for 6 Months. Here's What Predicts Fundraises.

Maryan K — Fri, 14 Aug 2026 08:48:18 +0000

Six months ago I started tracking the GitHub activity of 350+ startups across 15 sectors. The goal: find public signals that predict which startups are about to raise.

I backtested against 219 actual fundraises. Here's what I found.

The setup

Every week, my system pulls data from the GitHub API for 350+ startup organizations:

Commit counts per repository
Active contributor counts
New repository creation
Infrastructure file changes (CI/CD, Dockerfiles, monitoring configs)

I normalize by sector (a Healthcare startup ships differently than a Dev Tools startup) and score each startup on an Engineering Acceleration Score.

Live data is at signals.gitdealflow.com.

Three signals that predict fundraises

1. Commit velocity acceleration (the strongest signal)

Startups that raised within 90 days showed a median 34% week-over-week increase in commit velocity. The pattern is distinctive: steady baseline for months, then a sharp ramp.

This makes intuitive sense. Teams push hard to ship milestones before pitching investors. The code acceleration starts before the deck is finished.

2. Contributor count spike

Fundraising startups added a median of 2.3 new active contributors in the 60 days before their round. This reflects pre-round hiring pushes. You're building the team before you ask for money.

3. Infrastructure buildout

Startups about to raise were 3.2x more likely to add new CI/CD workflows, Dockerfiles, or monitoring configs in the 90 days pre-round. This signals preparing for scale (and investor demos).

Sector benchmarks (Q2 2026)

Sector	Startups	Median weekly commits	Top quartile
AI & ML	67	47	112
Developer Tools	34	89	203
Fintech	42	34	78
Web3	28	56	134
Healthcare	19	22	51
Enterprise SaaS	45	38	84

Full table across all 15 sectors at signals.gitdealflow.com.

The honest result

My first pre-registered cohort went 0-for-10. Zero correct predictions out of 10 startups I said would raise within 90 days.

I published that result. Then I refined the methodology, expanded the dataset, and re-ran the backtest against 219 actual fundraises.

The improved signals now identify acceleration patterns that precede fundraises. But I lead with the failure because that's what makes the data trustworthy.

Full paper with the 0-for-10 transparency ledger: SSRN abstract 6606558.

How to use this

If you're an angel or VC:

Track GitHub activity for startups in your thesis sectors
Watch for the three-signal composite (velocity + contributors + infra)
When all three fire, the startup is likely 30-47 days from announcing a round
Reach out before the round is announced

The automated version of this is at GitDealFlow. You can also browse the open data at signals.gitdealflow.com.

Open source everything

Methodology: SSRN paper
Due diligence checklist: GitHub
Live data: signals.gitdealflow.com
Signal interpretation guide: GitHub

The author runs GitDealFlow. All methodology is open. CC BY 4.0.

Why Your Agent Burned $2,800 at 3 AM: And How to See It

Maryan K — Thu, 13 Aug 2026 13:36:02 +0000

Co-authored with Jacopo (Agent-Devtools)

At 3:07 AM, my agent made 21 API calls to a premium LLM endpoint. Each cost $133. Total time: 60 seconds. Total bill: $2,800.

I was asleep. The budget alert email, the thing I'd set up so this couldn't happen, arrived 4 minutes later. Also while I was asleep. It was a very informative email about money that was already gone.

That night taught me something that took two open-source projects to fully solve:

You need a firewall to stop the bleed. You need a debugger to see why it happened. One without the other is half a safety system.

Half one: stop the bleeding

Before that night, I'd tried the standard defenses, in order:

Budget alert emails. They fire after the spend happens. At 3 AM the only thing reading them is your inbox.
Rate limits. They cap speed, not spend. An agent can trickle its way to the same bill over an hour.
Manual monitoring. It fails at exactly the moment you need it most, 3 AM, weekends, holidays, the one night you forget.

So I built AgentShield: a pre-execution spend firewall for AI agents. Every transaction is evaluated against your rules before the API call goes out. Pure Python stdlib, zero dependencies, <1ms per evaluation, 7 composable rules, transaction limits, daily totals, velocity, merchant allowlists, category blocks, session budgets, cascade cost estimates, plus a kill switch. APPROVED, BLOCKED, or FLAGGED, in priority order, deterministically.

The 3 AM incident wouldn't have survived contact with a single rule: transaction_limit: max_amount $100.

That solves "what should we block right now?" It does not solve "why did it happen?"

Half two: see the loop

Blocking a runaway agent is like unplugging a burning appliance. Safe. Necessary. But you still don't know if it was a bug in your code, a retry loop in a library, a poisoned tool response, or a bad prompt. Without that answer, the agent just runs again tomorrow, and you play firewall whack-a-mole.

That's the problem Agent-Devtools, built by Jacopo, solves: a local-first causal debugger for agent runs. It answers "why did my agent behave this way?" with visual replay, behavior diffing, and full visibility into prompts, context, memory, retrieval, and tool calls, the exact execution timeline that led to the bad decision.

Jacopo found AgentShield through a comment on a LangChain issue about runaway agent loops, saw the same gap I did, and opened an issue: "You stop the bleed, I show the loop. Want to integrate?" We both said yes.

Wiring the halves together

The integration is deliberately boring, a shared event schema, two small modules, no hosted services:

from agentshield import SpendControlEngine, SpendEvaluationEmitter
from agent_devtools import TraceStore
from agent_devtools.adapters.agentshield import make_agentshield_callback

store = TraceStore()
cb = make_agentshield_callback(store)

engine = SpendControlEngine()
emitter = SpendEvaluationEmitter(engine)

# Every evaluation flows into your trace store automatically
emitter.emit(
 transaction={"amount": "500.00", "merchant": "openai-api",
 "category": "llm_inference"},
 rules=[{"id": "r1", "type": "transaction_limit", "priority": 1,
 "params": {"max_amount": "250.00"}, "action": "BLOCK"}],
 trace_id="trace_42",
 on_event=cb,
)

That's it. Under the hood:

AgentShield emits one agentshield.spend.evaluation event per evaluation, NDJSON to stdout or a file (for tailing), or an in-process callback for embedding.
trace_id joins directly to Agent-Devtools' native run_id, so spend decisions render inside the execution timeline, the blocked call, the rule that fired, the actual-vs-threshold numbers, and the agent's own reasoning, all in one view.
Per-rule trace visibility: every rule reports triggered, passed, skipped, or not_reached. You see near-misses, not just the winning rule.
Money stays exact: amounts cross the wire as Decimal-safe strings, never floats.

The result is the loop the title promises: the firewall stops the spend at the moment it happens, and the debugger shows you the replay of why the agent got there.

What the collaboration actually took

The nice thing about this integration is how little ceremony it needed:

Jacopo opened the issue. We agreed on a schema before writing code, the contract took one document.
AgentShield shipped the emitter (evaluate_with_trace() + SpendEvaluationEmitter), additive, so existing evaluate() behavior didn't change.
Agent-Devtools shipped the adapter, a parser, a callback, and NDJSON ingestion.
Then the important part: independent E2E verification on both sides. We ran each other's code against real events, and it surfaced real edge cases: missing trace_id crashing the host runtime (now falls back to unattributed), callback events invisible in the run list (runs now auto-create), one malformed NDJSON line dropping the rest of a file (now skip-and-continue), and a Decimal precision bug on our side (now exact).
Everything merged. Both suites green. 37/37 across the cross-stack harness.

Two repos, one issue thread, under a day from first comment to both sides merged.

The takeaway

Every agent team eventually has their own 3 AM. The only question is whether it's a $2,800 lesson or a $19/month non-event.

The pattern worth stealing isn't the code, it's the division of labor: pre-execution control answers "should this run?"; post-execution visibility answers "why did it run badly?" Monitoring tools only tell you what already happened. Budget alerts only tell you what already happened. An agent safety story needs both halves, and now they're one integration.

AgentShield (pre-execution firewall): github.com/kindrat86/agentshield, stdlib-only, 7 rules, <1ms, kill switch.
Agent-Devtools (post-execution debugger): github.com/Jacopos311/Agent-Devtools, local-first visual replay for agent runs.

Both MIT. Both merged. Star both, wire them together, and sleep through the next 3 AM with confidence.

How I Built a Deal-Flow Signal From Public GitHub Data (219 Fundraises Backtested)

Maryan K — Wed, 12 Aug 2026 21:27:04 +0000

Eighteen months ago I noticed something odd while stalking a startup's GitHub org before an angel check: their commit activity had tripled about a month before they announced their round. Not after. Before.

I'm a data person, so I did what data people do. I stopped looking at one company and started looking at all of them.

The hypothesis

Startups behave differently on GitHub in the weeks before a fundraise. They clean up repos, ship faster, onboard new engineers hired ahead of the announcement, and spin up infrastructure for the growth they're about to buy. All of that is visible in public API data if you know what to measure.

So I built a tracker. It now watches 4,200+ startup GitHub orgs weekly across 20 sectors, computing three signals:

Commit velocity — commits across tracked repos in a trailing 14-day window vs. the prior window
Contributor growth — distinct active contributors over 30 days vs. baseline (new hires show up here first)
New repo creation — fresh public repos in 30 days (infrastructure buildout)

These get combined into a composite score and classified: breakout, acceleration, steady, cooling.

Did it actually work?

I backtested the pattern against 219 documented fundraises. Companies showing the acceleration pattern raised at roughly 3.4× the base rate, with the signal appearing 21–47 days before the public announcement in the cases where it fired.

The full methodology is published as an SSRN preprint (DOI: 10.2139/ssrn.6606558) with the backtest dataset on Zenodo (10.5281/zenodo.19650920). I wanted this to be checkable, not another black-box "AI signal."

What it caught this quarter

A few live examples from the current Q3 2026 period (all public data, verifiable on GitHub right now):

Fleetbase (logistics OS, pre-seed): commit velocity up ~16× over its prior window, 7 active contributors (+73% in 30 days). Classic engineering-hiring-burst shape.
Tuva Health (healthcare analytics): 48 active contributors, 3 new repos in 30 days. Infrastructure buildout pattern.
Swell (e-commerce infra): contributor count doubled in 30 days, 2 new repos. Hiring burst.
Reliza (DevOps/supply chain, pre-seed): contributors up 5× from a small base, 2 new repos.

Will all of these raise? No. That's the honest part.

The honest limitations

~23% false-positive rate. Acceleration sometimes means a big enterprise deal, an open-source push, or a hackathon, not a round.
Stealth-first companies are invisible. No public repos, no signal.
AI-heavy startups are noisy. Model releases create commit spikes that look like fundraise prep.
Small-base distortion. A 3-contributor org going to 6 is +100% but means little. The composite score penalizes low-base orgs, but it's not perfect.

Anyone who sells you a startup signal without a false-positive number is selling you a story.

The stack, briefly

GitHub REST API v3 (search/repositories, stats/commit_activity, contributors), a weekly batch pipeline that processes all 4,200 orgs for under €50/month of compute, and a scoring layer. No scraping, no private data, nothing you couldn't rebuild yourself — the signal computation logic is being open-sourced (MIT).

There's also a free MCP server, so if you use Claude Desktop or Cursor you can query the live signal data directly from your editor: six tools, no paywall on any of them.

Where this goes

I publish the weekly top movers in a free Sunday email at gitdealflow.com. The heavier stuff (full rankings, sector sweeps, dashboards) is paid, which is what funds the compute.

But the core idea is free and reproducible: public engineering activity is a leading indicator of private funding events. If you're an angel, a scout, or just someone who likes watching startups through their commits, the data is sitting there in the open.

Happy to answer questions about the methodology, the backtest design, or the pipeline in the comments.

— The Data Nerd

I Built a Firewall for AI Agent Spending — Here is What I Learned From 56 Attack Scenarios

Maryan K — Tue, 11 Aug 2026 21:46:34 +0000

It started with a $2,800 Stripe charge.

An AI agent we'd deployed to handle customer onboarding hit a flaky webhook endpoint. The standard retry logic kicked in. But instead of retrying once or twice, the agent discovered it could call a different endpoint to achieve the same result. Then another. Then it started chaining calls — each one triggering a separate Stripe charge because the underlying action wasn't idempotent.

By the time our billing alert fired four hours later, the damage was done. No single call looked abnormal. The spend curve was smooth and gradual. And our monitoring dashboard showed every single transaction in perfect detail — after the money was already gone.

That's the day I realized: observability is not enforcement.

The Problem: Agents Are Autonomous Spenders

AI agents are fundamentally different from traditional applications. A web app makes API calls based on user actions — predictable, bounded, and rate-limited by human interaction speed. An AI agent makes calls autonomously, at machine speed, and can discover new endpoints and tools at runtime.

This creates a new class of financial risk:

Runaway loops: An agent enters a reasoning loop, burning tokens indefinitely
Cascade discovery: An agent finds a new API and starts making calls you never anticipated
Tool re-execution: Retry logic triggers duplicate payments when tools aren't idempotent
Delegation spirals: An agent delegates sub-tasks to itself, each spawning more tool calls
Infinite reasoning: Thinking-mode loops consume token budgets without producing output

I looked at existing solutions. LangChain had cost tracking. CrewAI had guardrails. AutoGen had governance discussions. But they all shared the same fundamental flaw: they observed spending instead of preventing it.

A dashboard that tells you "you spent $2,800 today" is useless when the money is already gone.

Building AgentShield: A Spend Firewall

I needed something that sits between the agent and the tools it calls — a firewall that inspects every transaction before it executes and blocks anything that violates a budget rule.

The design was inspired by traditional network firewalls: deterministic, fast, and non-bypassable.

The 7 Rule Types

After analyzing our incident and dozens of similar failure modes reported across GitHub issues in CrewAI, AutoGen, LangChain, and Claude Code, I identified seven distinct spending attack patterns. Each maps to a specific rule type:

1. transaction_limit — Blocks any single transaction above a threshold. Simple but effective. If no individual API call should cost more than $5, this catches the $50 call immediately.

2. daily_total — Rolling 24-hour cumulative spend cap. The failsafe against any single-day disaster. Our $2,800 incident would have been caught at $50.

3. velocity — Rate limiting per merchant/tool. Catches burst attacks where an agent fires 100 calls in 30 seconds. This is the rule that catches retry storms.

4. merchant_allowlist — Only approved endpoints can be called. This is critical for agents that can discover new tools at runtime. If your agent shouldn't be calling unknown APIs, don't let it.

5. category_block — Block entire categories of spending. Useful for compliance ("no cryptocurrency purchases") or cost control ("no premium model calls during batch jobs").

6. session_budget — Per-agent-run budget cap. When an agent session starts, assign it a budget. When it's exhausted, the agent gets a budget-exceeded error and must terminate gracefully.

This is the rule that catches infinite reasoning loops and delegation spirals. The agent might be stuck reasoning forever, but it can't spend more than its session allows.

7. cascade_cost — The most nuanced rule. It detects when total spending is growing super-linearly — the signature of a runaway pattern. If call #1 costs $0.01, call #2 costs $0.01, but by call #50 you're spending $1.00/call, something is wrong.

This is the rule that would have caught our original incident. The agent's per-call cost didn't change, but the frequency was accelerating exponentially as it discovered new endpoints.

The 56-Scenario Evaluation Gym

Rules are only as good as their test coverage. I built a 56-scenario evaluation harness that simulates every spending attack pattern I could find — from GitHub issues, production incidents, and adversarial testing.

The scenarios fall into six categories:

Category	Scenarios	Example
Single-call attacks	8	Agent attempts $500 single transaction
Burst/velocity attacks	12	Agent fires 200 calls in 10 seconds
Cumulative spending	10	Agent spends $1/call for 500 calls
Loop patterns	14	Agent enters infinite reasoning loop
Discovery attacks	8	Agent finds undocumented endpoint
Multi-agent cascades	4	Agent delegates to sub-agents, each spending

Each scenario runs the agent against AgentShield with a configured rule set. The test passes if the firewall blocks the transaction before it reaches the provider, and fails if the spend leaks through.

Current pass rate: 54/56 (96.4%). The two remaining edge cases involve multi-agent systems where spending is distributed across agents — we're working on cross-agent budget aggregation for v2.

Enforcement vs. Observability

This is the distinction that matters most, and it's the one most teams get wrong.

Observability answers: "What happened?"

Dashboards, alerts, logs
Cost tracking per provider
Token usage analytics
Post-incident analysis

Enforcement answers: "What is allowed?"

Rule evaluation before execution
Hard blocks on policy violations
Budget caps that cannot be exceeded
Pre-call authorization

You need both. But enforcement is the one that prevents financial loss.

Think of it this way: a security camera (observability) helps you catch a thief after they've stolen from you. A locked door (enforcement) stops them from entering in the first place.

AgentShield is the locked door. It sits in the tool dispatch path and evaluates rules in under 1 millisecond — fast enough that the agent never notices the checkpoint, strict enough that no transaction can bypass it.

How It Works in Practice

AgentShield runs as middleware. You configure your rules, and every tool call from your agent passes through the firewall:

from agentshield import SpendFirewall

firewall = SpendFirewall(
    rules=[
        {"type": "daily_total", "limit": 50.00},
        {"type": "velocity", "max_calls": 20, "window_seconds": 60},
        {"type": "session_budget", "budget": 10.00},
    ]
)

@firewall.guard(tool_name="stripe_charge")
def process_payment(amount, customer_id):
    return stripe.charges.create(amount=amount, customer=customer_id)

If a rule is violated, the agent receives a BudgetExceededError instead of completing the call. The agent can handle this gracefully — log it, notify a human, or terminate the session.

What's Next

AgentShield is open source and free to use. The hosted version at agentshield.fly.dev includes a dashboard for rule management and spend visualization — the observability layer on top of the enforcement engine.

GitHub: kindrat86/agentshield
Live demo: agentshield.fly.dev
Free tier: Covers most side projects and small teams

If you're running AI agents in production, the question isn't whether you'll have a spending incident — it's when. A spend firewall doesn't prevent bugs, but it ensures that when something goes wrong, the financial damage is bounded.

Because the alternative is finding out from a Stripe bill.

AgentShield is MIT-licensed and runs on Python 3.10+. If you've experienced an agent spending incident, I'd love to hear about it — the 56-scenario eval gym is always accepting new attack patterns.

🔗 github.com/kindrat86/agentshield | agentshield.fly.dev

How I Built a 56-Scenario Eval Gym for AI Spend Control

Maryan K — Tue, 11 Aug 2026 20:50:21 +0000

How I Built a 56-Scenario Eval Gym for AI Spend Control

After my AI agent spent $2,800 in 60 seconds at 3 AM, I knew I needed pre-flight spend control. But how do you test something that's supposed to catch runaway AI spending before it happens?

The answer: an eval gym with 56 labeled scenarios across 9 categories.

Why 56 Scenarios?

When you're building spend-control logic, you quickly realize that simple rules have subtle edge cases:

A $50 limit with a $50.00 transaction — should it block or approve?
What about $49.99 vs $50.01?
Daily total resets at midnight — but what timezone?
Velocity limits: 5 calls in 5 minutes — is the 6th call blocked or just the 5th?

These edge cases compound across 7 rule types. Here's how the scenarios break down:

Category	Scenarios	What it tests
Clean approval	10	Legitimate transactions pass through
Transaction limit	8	Per-transaction caps ($50, $100, etc.)
Daily total	7	Rolling 24h spending caps
Velocity	6	Rate-of-spending detection
Merchant allowlist	7	Vendor whitelisting/blocking
Category blocks	7	Category-level restrictions
Session budget	3	Per-session spending ceiling
Cascade cost	3	Multi-step operation cost analysis
Edge cases	5	Boundary values, nulls, negatives

The gym runs against a clean engine state every time — no shared state, no ordering dependencies. Every scenario is independent.

The Hardest Edge Cases

Amount exactly at limit: If the limit is $50.00 and the transaction is $50.00, should it be approved? We chose approve — "exceeds" means strictly greater than. This is documented and tested.

Decimal precision: All monetary arithmetic uses Python's Decimal type. Never float. 0.1 + 0.2 is fine for graphics; it's catastrophic for money.

Priority ordering: Rules evaluate in priority order. If rule #1 BLOCKs but rule #2 would APPROVE, the first match wins. The test suite verifies that a BLOCK at priority 1 always beats an APPROVE at priority 5.

The Gym is a Universal Benchmark

The eval gym is useful even if you don't use AgentShield. If you're building any kind of spend-control or rate-limiting logic, these 56 scenarios provide a test suite you can run against your own implementation.

Check the live results: 56/56 across 9 categories. The spec is at agentshield.fly.dev/eval-gym-spec.

What's Next

I'm working on adding more scenario categories:

Multi-agent shared budget scenarios
Timezone-aware daily reset edge cases
Cascade cost with variable failure rates

The gym is MIT licensed. Use it. Fork it. Add your own scenarios. If you find a bug in the test suite, open an issue — I'll fix it.

Previously: I built a firewall for AI agent spending — here's the architecture