XMarts room

Winter 2026

Approxima

Your software should build itself.

Visit website

What they do

agents that scope, code, test in sandboxes and merge fixes

How close to us

4, very close

does and validates routine code work end to end; same problem as W1, buyer size not stated

Wedges

  • W1 Trusted 24/7 coding for small startup teams direct
  • W2 Seeing whether your AI agents actually produce adjacent
L1 Company brain (knows the organisation) 1, light
L2 Agent team (runs agents, tools, approvals) 1, light
L3 Does and learns (finishes, checks, measures, updates the brain) 2, clear

Who buys

Firm size
not known
Buyer type
developer
Role
engineering lead
UK
not known
Their own description (from YC)

Human-assisted development should be for novel ideation, not routine maintenance, bug fixes or incremental updates. Approxima is bringing you that future with agents that can scope work, code, validate their fixes end-to-end in sandbox environments and merge to production. Book a demo: https://calendly.com/ashish-selvaraj/approxima

Full teardown

Approxima (YC Winter 2026): teardown vs XMarts

In one line: Approxima sells AI agents that test every pull request in a real browser and report what broke, and (on the YC page) agents that fix the bug and merge it [site] [yc]. Threat: 2, because it is the same problem as W1 (trusting agent-made code) for developer teams, but it is two people, has no named customers and checks code at one point only [yc] [press].

1. Fact file

Item Finding Source
What they say YC line: "Your software should build itself." Home page title: "AI Agents That Test Every Pull Request". [yc] [site]
Founded, team, funding Founded 2025, team of 2, Toronto, YC Winter 2026, primary partner Diana Hu. Funding not public (UNVERIFIED beyond the standard YC deal). One listing says San Francisco. [yc] [press]
Founders Ethan Pronev: trading systems at Jane Street and Citadel Securities, Waterloo CS 2025. Ashish Selvaraj: Delta Live Tables at Databricks, an infra testing engine at Microsoft, Waterloo CS and Business 2025. A third-party tier list adds that he built a side app, Not Evil Sudoku, with about 180K installs. What YC likely saw: strong young engineers with infra and testing experience, and a shipped consumer app (inference). [yc] [press]
Customers None named. The home page shows no logos or case studies in the text we could read. A third-party review says it found no sign of paying customers (Mar to Oct 2026, date not exact). [site] [press]
Price Not public. A single "Demo" tier, contact for pricing. No job ads, so no sales-model hint. [press] [jobs]
Path Earlier product "SideKit": a mobile app backend toolkit (analytics, feedback, version gating, feature flags, MCP server). It no longer accepts new sign-ups. Then Approxima, a coding-agent pitch on the YC page, and a PR-testing pitch on the home page. A third-party post dated 20 Jul 2026 says Approxima is open source (MIT) and self-hostable; we could not find the repo (UNVERIFIED). [site] [yc] [press]

2. Their proposition, reverse engineered

Part What they do
Who buys Engineering teams that ship through pull requests and CI/CD. Team size of the buyer is not stated (inference: startups first, since the founders are two people and the demo is booked by Calendly) [site] [yc].
The pain Routine maintenance, bug fixes and small updates eat engineer time [yc]. Broken pull requests slip through and test scripts are costly to keep up (inference from "zero-maintenance QA" wording in a third-party listing) [press].
The promise Agents build your app in a sandbox, test it in a real browser and report what is broken with screenshots [site]. Third-party listings add: they open a fix as a follow-up PR, no test scripts needed [press]. YC page goes further: agents "scope work, code, validate" and merge to production [yc].
How it works Plugs into CI/CD and runs on every pull request [site]. Isolated sandbox, real browser, screenshots [site]. Third-party write-up: plain-English test steps, a browser agent, a screenshot after each step, "Goal Mode" where the agent explores and writes the steps, self-healing steps, reusable skills such as a login flow [press].
The output A bug report with screenshots on the PR [site]. A fix PR (third-party claim) [press].
Proof style None public. No counts, no money, no time saved [site].
Who sells it Founder-led demos via a booking link [yc]. A magic-link login suggests a self-serve app behind it [press].
Price model Not public [press].
The story "Human-assisted development should be for novel ideation, not routine maintenance." [yc]

3. Positioning

  • Category they claim: agentic QA for CI/CD (site and keywords name Greptile and QA Wolf as the comparison set) [site].
  • Category a YC partner would put them in: AI QA and testing for developers, with a coding-agent ambition (inference).
  • What they want to be known for: software that tests and repairs itself, so humans do only new work [yc].
  • Where they sit on the map: layers L1/L2/L3 = 1/1/2, buyer = unknown size, developer.

4. Three layers vs ours

Layer Them (score + evidence) Us (Marton's logs show)
L1 Company brain 1. Only a reusable test "skills" store and self-healing steps, per a third-party write-up. No company memory [press]. Their old SideKit product had an MCP server that fed usage data to coding agents [site]. A vault of about 1,400 pages, 112 call transcripts and about 8,700 customer quotes, searchable by meaning.
L2 Agent orchestration 1. One browser agent per PR run. YC text says agents "scope work, code, validate" but the site shows only testing [yc] [site]. About 5,600 jobs run by agents from three makers. Each job is built in its own copy of the code.
L3 Execution and learning 2. Does work (tests, and per third parties a fix PR) and checks it with screenshots after each step [site] [press]. No public sign that results change the next run, apart from "self-healing" steps [press]. Each job is checked by a different AI than the one that wrote it, then about 370 automatic checks. About 160 failure records, each adding an automatic check. Only about 15% of jobs reached the main code, and merges were unreliable in October.

5. Same and different

Topic Same or different Them Us
Core belief Same Routine code work should be done by agents [yc]. Agents write and merge code around the clock (brief).
Buyer Similar Engineering lead, size unstated [yc]. W1: small startup teams, up to about 30 engineers (brief). No customer yet.
Where trust comes from Different Test the result in a browser, per PR [site]. A different AI reviews the code, then automatic gates before it joins main. Marton's logs show this on his own repos only.
Point of control Different One point: the pull request [site]. The whole line: queue, build, review, gate, merge, watch.
Learning Different Self-healing test steps (third-party) [press]. Failures become written records and new checks. Marton's logs show about 160.
Kind of work Different Frontend and UI checks, mostly (third-party) [press]. Any code job in a repo, plus content and sales work.
Delivery Different Hosted or self-hosted app plugged into CI/CD [site] [press]. Runs on three of Marton's Macs. Nobody else has run it.
Proof Same (both thin) No customers or numbers [press]. No paying customer. Own-business numbers only.
Price Unknown Demo, contact for pricing [press]. Not set.
Size Same 2 founders [yc]. 2 founders.

6. Wedge overlap

Wedge Fit Why
W1 Trusted 24/7 coding for small startup teams direct Their YC line is agents that code, validate and merge [yc]. Their live product is the "trust" half: test every PR [site]. Same buyer type, same problem.
W2 Seeing whether your AI agents actually produce adjacent They check what agents ship (the PR), not whether the agent fleet is stuck, silent or costly. "Checks only" ground (lens), so a neighbour not a rival.

7. Whitespace (where they stop)

  • Layer gap: one agent at one point (the PR). No company memory, no team of agents, no queue that keeps agents busy overnight [site]. To own it we need a customer repo where our agents write, a second AI reviews and the gate merges, for 4+ weeks.
  • Buyer gap: buyer size and sector are not stated; no customers shown [site]. To own it we need 3 to 5 named small teams (up to about 30 engineers) who hire engineers now and say the pain is real.
  • Number gap: no result is public: no bugs caught, no hours saved, no merge rate [site]. To own it we need one before/after number, such as merged-and-held changes per week or bugs caught before main.
  • Price gap: price hidden behind a demo [press]. Open source and self-hosting (third-party claim) means they may undercut on price [press]. To own it we need a price tied to work merged, not seats.
  • Speed gap: no data. They may be fast: plug into CI and run (inference). Not a gap we can claim.

8. For the YC application

  • Proven today: Marton's logs show his system already runs the whole line on his own repos: about 5,600 jobs, each built in its own copy of the code, checked by a different AI than the one that wrote it, then passed through about 370 automatic checks before main. About 160 failure records each added a check. Approxima's public product tests the app after a PR is written [site].
  • Draft answer to "how are you different from Approxima?": DRAFT. "Approxima tests a pull request in a browser. Our system runs the whole build line: agents write, a different AI reviews, automatic gates decide what merges, and every failure adds a new check." Founders say it their own way.
  • Future claim (needs proof): "Small teams get agent code they can trust, and the merge rate keeps rising." Needs one customer repo run for 4+ weeks with a before/after number (merged changes that held, bugs stopped before main). Marton's logs also show only about 15% of jobs reached main, so the number must be fixed first.
  • What we understand that they don't: the risk is not only a bad PR but a silent fleet: stuck, failing or burning money with no alarm. proven on Marton's own system (about 160 incident records); needs proof on any customer.
  • Copyability (M3): medium. They already run agents in a sandbox with a browser and say they merge [site] [yc], so adding a second-AI review gate is a feature for them. The failure-record habit and fleet-watching layer is months of work and pulls them from QA into queue operations (inference). Two founders and an open-source pitch (third-party) also limit how much they can build [press]. Not hard, so M3 can not score above 3 against Approxima alone.
  • Why now (M4): None found. Do not use "agents can now write code": that is general AI progress.
  • Do not claim: that Approxima does not fix bugs (third parties say it does) [press]. That our merge rate is good (about 15% of jobs, and the lander was in an emergency in October). "Trusted" as proven for any outside customer. That they have no customers: only that we found none.

9. Ideas worth taking

  1. Hook into the place buyers already work: run on every pull request, report with screenshots. A visible proof object on each change.
  2. Plain-English "Goal Mode": describe the outcome, the agent writes the steps and keeps them (third-party description) [press].
  3. A free, open-source entry with a hosted upgrade (third-party claim, UNVERIFIED) [press]. A cheap way to get the first 5 teams to try it.

10. Unknowns

  • Is the open-source claim real, and where is the repo? Look for the GitHub org appsidekit (4 repos seen, none named Approxima) and ask in a demo.
  • Does the live product fix and merge, or only test? Book the demo or sign in to the product.
  • How the "scope and code" YC line and the "test every PR" home page fit together. Likely a shift to QA (inference). Check their X account for dated posts.
  • Customers, pricing, funding beyond YC. Check a Launch YC post, if any, and any later press.
  • Buyer size and country. Ask in a demo.

Sources

Technical detail
Slug
approxima
Lens hash
179096c479
Pass
deep
Stale
no