Commuting Cost — Raise-Readiness Report

Prepared for: CertiHomes board / capital raise Subject: "Commuting Cost" GPU multimodal true-cost engine, reviewed as a proposed moat component Date: 2026-06-25 Inputs: Four independent investor-grade reviews — YC seed-diligence (skeptic seat), Acquirer CTO / engineering due-diligence, Seasoned CEO / board advisor, Pre-seed/seed pitch coach. Two engineering claims independently re-verified for this report against live infra (see §5).

1. Executive summary + fundability verdict

The four reviewers agree on the shape of the thing, and the agreement is the signal. The technology is real, verifiable, and impressively capital-efficient; the business is not yet proven. All four ran the live engine or inspected the artifacts and confirmed: sub-second national isochrones on a single $1,200 RTX 5080, a bit-exact-validated GPU RAPTOR transit kernel, and — critically — a working /v1/multiuser two-commuter endpoint that every GTM document wrongly calls "spec-only." Three reviewers independently flagged that the team is underselling its single most differentiated capability.

The disagreement is narrow and it is about altitude, not facts. Grades cluster B-/B/B+ with one C+. The C+ (YC) is a focus-and-narrative judgment, not a technical one. The B- (Engineering DD) is the harshest on substance and is the most important read in this packet because it is the only review that re-ran the claims and found three that fail verification: the Canada coverage, the headline speedup, and the depth/freshness of the "moat" data.

Overall fundability verdict:

FUNDABLE as a small pre-seed/angel raise on the "solo operator shipped a real national engine + a hard, unglamorous data moat" story. NOT YET fundable as a venture-scale seed, and NOT fundable on the "acquire-us" thesis as currently written. As a line item inside the CertiHomes raise, it is a credible, milestone-gated capability/option that strengthens the parent's "we price the whole cost of living somewhere" story — provided it is sold as an ingredient, not a standalone moat pillar. The single biggest unforced error across all four reviews: leading with "Google should buy us" instead of "here is the customer paying us," and launching a tier-1 press campaign on report numbers the report's own appendix admits are not yet engine-measured.

The talent and the tech are not the problem. The commercial story (who pays, proven by what revenue) and the founder's instinct to optimize for exit before product-market fit are.

2. The moat thesis in three sentences

The algorithm is public (RAPTOR / Delling-Pajor-Werneck) and the GPU is commodity, so neither is the moat. The defensible asset is the curated, nationally-cleaned price database — 723+ GTFS fare feeds de-bugged of orphan-service-id defects, 36-state tolls, 1,515 geocoded CBD garages, 194 GBFS systems, national fuel — plus the GPU refresh pipeline and the two-commuter "household" math, which together let us price the whole trip, for every mode, for both earners, a quadrant no incumbent currently expresses. This is a timing-and-tedium moat (years of janitorial data work a motivated Google/Esri/Zillow could replicate in roughly 2-3 quarters), not a structural lock-in — which makes it a real but durability-capped advantage that must be monetized through a customer wedge before an incumbent decides the market is worth the cleanup.

3. Strengths (deduped across all four reviewers)

1. The tech is real and survives contact — not vaporware. Independently verified by reviewers: cold isochrone ~0.74s, warm ~0.02s, 15,500+ cells, sane cost range ($3–$33). hexmap-api.service live on :8098, 32/32 regional precompute parquets on disk, 32 metro networks built. A buyer can run it.
2. The flagship is already built and is being undersold. /v1/multiuser returns HTTP 200 in ~1.5s with ~15,530 scored per-cell {time_a, cost_a, time_b, cost_b, combined_cost_month} results, min/cost filters, and an overlap_warning field. Three of four reviewers call out that the docs' "spec-only, greenlight pending" framing is sandbagging the one capability no incumbent can match. Only the consumer /map UI is missing.
3. A genuinely hard, unglamorous data moat. Cleaned national GTFS fares (orphan-service-id repair is real domain IP), 36-state tolls, national CBD parking, GBFS, fuel. The "algorithm is public; the cleaned price DB is the IP" framing is the correct and honest moat thesis — and rare self-awareness for pre-seed.
4. Validation discipline above seed-stage norm. r=0.90 vs CNT H+T, 4/5 ground-truth OD pairs in OTP bands, 12/12 walk legs vs OSRM, bit-exact GPU==CPU at k=1..5 (T1 synthetic + T2 real-feed). Three independent oracles cited with as-of dates.
5. Architecture choices are correct. RAPTOR (not GPU A) for timetables, struct-of-arrays stop-major/origin-minor for coalesced reads, precomputed cuGraph SSSP walk matrices over crow-fly, H3 as index/display not routing graph. REVIEW.md is a real adversarial design review that caught real bugs before* shipping (memory math, snapshot OOM, u16 silent clamp, best-hopping hazard).
6. Exceptional capital efficiency and "founder ships" velocity. A national 32-metro multimodal cost engine on one $1,200 GPU, built largely solo + AI, 83 commits since June 1. This is the de-risking signal a pre-seed check is actually buying.
7. Honest internal caveats are an asset in diligence. The "Data gaps to close" sections and "honest weaknesses" lines pre-empt the gotcha questions. Reviewers uniformly read this candor as a maturity signal worth underwriting.
8. The category insight is sound and the "why now" is real. Incumbents (Google/Mapbox/TravelTime) price time, not dollars; the household/two-commuter shape is a true empty quadrant. Affordability + $5 gas + spreading congestion pricing is a genuine, un-manufactured tailwind.

4. Top risks, ranked by severity

R1 — WHO PAYS is unresolved. Zero revenue, zero signed pilots, zero LOIs, zero design partners. (All four reviewers; the consensus #1.) The packet offers 8 segments, 6 pricing models, and 5 acquirers — breadth standing in for focus. At seed you need ONE buyer paying, not ten hypotheses. The 13-year MLS "warm channel" is asserted, not evidenced with a single closed dollar.

R2 — The "national / Canada" claim is partly fiction, and the failure mode is silent garbage. (Engineering DD; re-verified for this report.) OSRM is US-only (confirmed: extract is us-latest.osm.pbf only). The 6 Canadian metros have broken drive/P&R/K&R/Uber. Toronto downtown snaps ~50 km to a US border node; Seattle→Vancouver returns NoRoute; the engine returned identical cells for Toronto "drive" and "transit" — it produces plausible-looking garbage instead of erroring. A buyer testing any Canadian drive query finds it broken in minutes. See §5.

R3 — The "acquire-us" thesis is the dominant narrative and is the weakest possible foundation for a raise. (YC, CEO, Pitch.) ACQUISITION-POSITIONING.md is the most polished doc in the repo and explicitly plans to "manufacture the signals that make a buyer connect the dots." Corp-dev smells this and it caps the price. "They'll just build it" is the correct default — Google added a fare to Maps without buying anyone. As a slide-12 footnote, optionality is fine; as the thesis, it signals no PMF.

R4 — The press centerpiece ("Losing Ground 2026") is not publication-ready by its own admission. (All four.) The headline transportation numbers are still CNT's modeled baseline "contextualized" with 2026 drivers — NOT the GPU's measured costs the entire pitch is premised on. Energy is Northeast-only applied nationally; HUD limits cover ~4 states; MTA single-ride fare "not cleanly tagged." Launching a tier-1 NYT/Bloomberg push on numbers a competent data journalist can audit is an asymmetric, reputational landmine — and it is currently scheduled ahead of the fixes.

R5 — The headline "1000–10,000× faster than OTP" is benchmarked against a strawman the team itself flagged as unfair. (Engineering DD.) REVIEW.md §4.11 demanded GPU vs in-process optimized CPU RAPTOR over identical arrays; that benchmark was never run. The honest, instrumented number (~21s wall for a full NYC res-9 metro; kernel ~13.2s) is impressive on its own. The marketed multiplier invites exactly the takedown a skeptical acquirer will run.

R6 — The moat is durability-capped; defensibility against a motivated incumbent is thinner than claimed. (All four.) Every input is public or scrapeable. A funded competitor replicates the price DB in ~12–18 months. The honest moat is "nobody big wants this enough to do the cleanup yet" — a timing moat, not a structural one.

R7 — Key-person / bus-factor / single-GPU operational fragility. (All four.) One founder + AI across a sprawling self-hosted fleet full of tribal-knowledge gotchas. The whole engine runs on one RTX 5080 co-resident with a do-not-touch 2 GB Second Brain process, behind a single 429 one-request-at-a-time lock, with large metros (LA ~36K stops) OOM-ing without chunking. This cannot serve a B2B "Scale tier / SLA" as architected.

R8 — The "moat" traffic asset doesn't touch the moat product, and drive time is the softest layer. (Engineering DD; re-verified.) commute.traffic_peak_factors (594 rows, only 15 metros Google-calibrated) feeds only the legacy single-trip path. The live isochrone engine uses a hardcoded constant (see §5). Drive times are modeled (OSRM × peak factor) — so the time axis, the thing buyers A/B against Google Maps, is the weakest input sitting right next to the dollar numbers.

R9 — Narrative incoherence: B2C affordability crusade vs B2B data-licensing vs acqui-bait. (YC, CEO, Pitch.) Three businesses in one coat. Worse, investors.commutingcost.com resolves to "CertiHomes — The Agentic OS for Real Estate," a different product. Brand/cap-table confusion at the front door loses investors before slide 1.

R10 — Toll/fare depth + freshness is thin for a "true-cost" claim, with no expiry tracking. (Engineering DD.) ~194 toll facilities, ~20 null-priced, distance turnpikes flattened to flat rates. Fares loaded in a single bulk with no feed-level validity dates — and CLAUDE.md itself notes an MTA calendar that expired mid-cycle. A wrong toll on a route a user knows is a credibility-killer. "Live, not a stale annual index" overstates a monthly-cron reality.

R11 — Consumer retention is probably one-and-done; CNT IP/trademark exposure on the lead magnet. (YC, CEO, Pitch.) A "what does my commute cost" map is checked once during a move, then churns; same for the home-search finder. No retention loop = the only real model is B2B licensing, which contradicts the consumer-virality engine the campaign funds. Separately, a national "recreation" of CNT's trademarked Losing Ground / H+T® study is close to the line and needs counsel.

R12 — Core routing correctness is still being fixed while a national PR launch is scheduled. (YC.) Open tasks include "Fix 08854→10001 transit $6 bug" and "API silently drops transit for non-NYC ODs." GTM is running ahead of product reliability.

5. Traffic-data + OSRM infra verdicts (called out explicitly)

Both claims below come from the engineering due-diligence review and were independently re-verified against live infra for this report.

Traffic data — VERDICT: the moat traffic table does NOT feed the moat product.

The calibrated table commute.traffic_peak_factors (594 rows; only ~15 metros google_calibrated, the rest TTI literature) feeds only the legacy single-trip multimodal.py path. The live GPU isochrone engine uses a hardcoded global constant, verified in source:

• hexmap-api/modes.py:126 (and hexmap-api-regional/modes.py:126): PEAK_DRIVE = {"am_peak": 1.6, "off_peak": 1.1}
• hexmap-api/engine.py:1539, 1566, 1692: drive/uber/P&R legs read md.PEAK_DRIVE.get(self._window, 1.6) — one global multiplier on OSRM free-flow, no metro or road-class variation, no real-time data.

So the flagship product applies a single 1.6× peak factor nationwide. The asset positioned as a traffic moat is an orphaned table; 15 calibrated metros + literature is not a traffic asset an acquirer values against INRIX/Google. Fix: wire traffic_peak_factors into the GPU engine's drive/uber/P&R legs and expand calibration well beyond 15 metros — or drop traffic from the moat narrative entirely.

OSRM — VERDICT: US-only. "Canada" is fiction for drive/P&R/K&R/Uber, and the failure is silent garbage.

Confirmed on the OSRM host (172.26.1.151): the container runs osrm-routed --algorithm mld /data/us-latest.osrm, and the mounted data directory contains only us-latest.osm.pbf and its derived .osrm files — no canada-latest or north-america extract exists. Consequence: the 6 Canadian metros (Toronto, Vancouver, Montreal, Calgary, Edmonton, Ottawa) have broken drive/P&R/K&R/Uber routing on 4 of 9 modes — i.e. ~19% of the marketed "32 US+CA metros." The reviewer observed Toronto downtown snapping ~50 km to a US border node, Vancouver ~29 km to "Boundary Bay Road" (US side), Seattle→Vancouver returning NoRoute, and — most disqualifying — the engine returning an identical cell result for Toronto "drive" and Toronto "transit," meaning the broken mode emits plausible-looking garbage rather than an error. Fix (in priority order): (1) make broken-country drive queries ERROR explicitly instead of returning relabeled transit cells — the silent-garbage behavior is the single most disqualifying thing a technical DD lead will find; (2) build a north-america-latest OSRM extract or add canada-latest.osm.pbf as a second routed instance behind a country-router; OR (3) honestly re-scope to "US drive + transit-only for Canadian metros."

6. Recommended pitch + the single killer stat

Lead with the receipt, not the engine. Open on a single slide: the $2,302/month Summit drive-vs-rail differential, shown live on the map, with the line:

"Every map tells you this commute takes an hour. None of them tell you it costs $2,302/month more to drive — we're the first to price the trip, for every mode, for the whole household."

• The single killer stat to lead with: $2,302/month (the Summit, NJ rail-vs-drive differential). It is concrete, visceral, screenshot-able, household-relevant, and demonstrably ours — no competitor surfaces it. Backed by $1,924/mo avg across 30 towns with rail cheaper 30/30.
• The killer frame: "Time is solved. Cost is the open field." GPU / 32 metros / r=0.90 / Losing Ground are proof, not hook. The packet is currently ~80% proof / 20% hook — invert it.
• Then put a Traction/Pilots slide immediately behind it, followed by the Ask + Use-of-Funds + 18-month milestones (none of which exist in the current GTM docs).
• Ship the multiuser /map demo before the pitch. It already works server-side; it is the one capability no incumbent can show. A working "find the home that works for both of your jobs — in time AND dollars" demo is worth more than the entire 4-document campaign. Do not pitch the multiuser story until you can demo it.
• Produce one non-NYC hero number (a measured, screenshot-able "$X/mo" receipt for a car-dependent Sunbelt metro — Miami/Riverside/Orlando) to kill the "it's just a NYC demo" objection every diligence lead will raise.
• Pull ACQUISITION-POSITIONING.md entirely out of the raise conversation. Keep it gated; never let "manufacture acquisition signals" reach a buyer or investor.

7. Top-5 things to fix BEFORE the raise (priority order)

1. Ship the already-built multiuser two-commuter finder to the live /map. Highest ROI, lowest cost, 90% done (it's dict-work on shipped /v1/isochrone infra — no kernel change). Converts the #1 "un-replicable" claim from spec to fact. Unanimous across all four reviewers.
2. Land ONE paid pilot / signed LOI — recommend the warm MLS channel (CJMLS or GSMLS), even at low five figures — and pick ONE wedge. One signed check kills more diligence objections than any polished doc. Everything else (energy, relocation, lenders, portals, acquisition) goes on a "later" list. Unanimous.
3. Fix the Canada/OSRM silent-garbage and the core transit-cost bugs BEFORE any GTM. Make broken-country drive queries ERROR (don't relabel transit as drive); resolve the 08854→10001 transit bug and the non-NYC OD transit drop. Freeze new GTM work until the cost/routing path is green on ~20 hand-picked national OD pairs with documented oracle comparisons.
4. Substitute GPU-MEASURED costs into "Losing Ground 2026" (or delay/downgrade the press). Replace CNT's modeled transport numbers with the engine's measured costs for at least the top 3–5 metros, close the NE-only energy gap for headline metros, and get counsel to clear the CNT trademark/recreation use in writing. A methodology hole found by a tier-1 reporter is unrecoverable. Sequence: commercial proof → fixed report → press. Unanimous.
5. Untangle the entity + de-risk the bus-factor in the deck. Fix investors.commutingcost.com so it serves the commute-cost narrative (not "Agentic OS for Real Estate"); state clearly whether this is a standalone raise or a CertiHomes capability and on what cap table. Name the first two hires (a data engineer to own the price-DB pipeline; a backend eng to remove the single-GPU 429 lock and add redundancy) tied to use-of-funds. Retire "1000–10,000×" for the honest GPU-attributable number.

8. Appendix — reviewer grades + verdicts

Consensus: B-/B/B+ band with a skeptic C+. The tech is verifiably real and the data moat is genuine but durability-capped. Fundable now as a small pre-seed/angel raise (or a milestone-gated line item in the CertiHomes round) on the "founder ships + hard data moat" story — not on the acquire-us thesis, and not before the multiuser demo ships, one paid logo lands, the Canada/transit bugs are fixed, and the Losing Ground report is either re-measured or honestly re-labeled.