Seven Years of Reverse-Engineering Sneaker Bots, Turned Into a Real Business

01 /The Concept

Browser automation breaks. Anyone who has built a Selenium or Playwright scraper knows the cycle: the target site changes a class name, your selectors break, you patch, it breaks again. Computer-use agents – the newer approach – are slow, expensive, and nondeterministic. They might click the right button or they might hallucinate a UI element that doesn’t exist.

Kampala takes a fundamentally different approach. Instead of automating the browser, it watches the network. You install a man-in-the-middle proxy, use the target application normally for a few minutes – logging in, clicking through the workflow you want to automate – and Kampala captures the underlying API calls. After a brief processing period, it returns a structured "surface": typed endpoints, inferred authentication, rate-limit handling, and dependency mapping.

The result is a clean API where no official API exists. Not a brittle scraper that breaks when the CSS changes, but a deterministic set of HTTP calls that replicate exactly what the application does under the hood. The proxy intercepts traffic without modifying TLS or HTTP2 fingerprints, which means it sidesteps the anti-bot detection that plagues conventional approaches.

Co-founder Alex Blackwell spent seven or eight years in the web reverse-engineering underground – building integrations for sneaker releases, ticket platforms, and sportsbooks. The company itself emerged from Zatanna, a dental tech startup where the founders needed to integrate with legacy insurance payer dashboards that had no APIs. They built Kampala to solve their own problem, realized the tool was more valuable than the dental product, and pivoted.

Kampala launched from Y Combinator’s W26 batch.

02 /Why It Matters

The enterprise software landscape is full of critical systems that have no public API – legacy ERPs, government portals, insurance platforms, internal dashboards built fifteen years ago. The standard integration approach is either "wait for the vendor to build an API" (which may never happen) or "build a browser automation that someone has to babysit" (which always breaks).

Kampala’s MITM approach resolves this by operating at the network layer, which is structurally more stable than the UI layer. CSS changes constantly. JavaScript frameworks get rewritten. But the underlying HTTP endpoints that actually move data between client and server change far less frequently – because changing them would break the vendor’s own application.

The interesting tension: Kampala is technically doing something most companies’ terms of service prohibit. Reverse-engineering traffic, replaying authentication tokens, mapping undocumented endpoints – this is gray-area territory. But the demand is real because the alternative (manually operating legacy dashboards for hours per day) is worse. The dental origin story is telling – the founders weren’t trying to hack anything, they were trying to file insurance claims without spending four hours a day in a portal built in 2008.

The AI integration angle extends the value: once Kampala surfaces a structured API, users can pipe it directly to Claude Code or Cursor through MCP and generate automation scripts from natural language. The workflow becomes "use the app once manually, get an API, ask AI to build the automation." From legacy dashboard to fully automated workflow in under an hour.

03 /Opportunities

The "reverse-engineer any app into an API" capability has clear applications beyond individual workflow automation.

Data integration platforms like Fivetran and Airbyte have connector libraries for popular SaaS tools, but their coverage drops off sharply for niche or legacy systems. A Kampala-style approach could generate connectors on demand for any application a user can log into – turning the long-tail connector problem from an engineering challenge into a configuration step.

The healthcare and insurance verticals are particularly ripe. Both industries run on decades-old systems with no APIs, and both have workers spending hours per day manually transferring data between portals. The dental origin story validates this – and dental is one of the simpler healthcare verticals. Medical billing, prior authorizations, claims reconciliation across multiple payer portals – each is a workflow that Kampala could automate if the session management and re-authentication issues are solved.

The most defensible play for builders: don’t just use Kampala to automate one workflow. Use it to build a vertical-specific automation product for an industry still stuck on manual portal operations. The insurance broker who can process claims in seconds instead of hours doesn’t care how you built it – they care that it works. Kampala becomes your infrastructure layer; the vertical expertise becomes your moat.