R.T. Cohen · ר.ט. כהן — Candidate Projects & Discovery Plan
6 candidate projects from the Ronen call, each with what we need to do to scope it. ↩ post-call brief
Where to start — the strategic read
⭐ P2 · H-ERP
The platform play. Many businesses run Hashavshevet — a proven read/write integration + front-end layer is a reusable product (build once, resell). Lucrative now, capability moat later.
⚡ P3 · Dispatch
Lowest-friction entry. They already run a tool that reads/writes data somewhere — if we map it, we may ride on it instead of building from zero.
🎯 P1 · Parts
Biggest pain, hardest build. Expert-eye part matching is the hard part — a strong later wedge, not the first bite.
P2Hashavshevet (H-ERP) integrationStrategic · pursue
Pain: everything siloed in the ERP + manual re-keying; the work-card → approve → invoice flow.
To scope it, we need to
- Confirm their edition (Hashavshevet Windows on-prem vs H-WEB cloud) + version.
- Confirm whether H-CONNECT (the API module) is licensed — if not, the cost/path to enable it.
- Pull the H-CONNECT API docs; map the objects we need — items, part locations, customers, machines-by-serial, work-cards, invoices — and confirm read and write scope on each.
- Talk to their Hashavshevet reseller/integrator; get a test company + credentials.
- Reusability check: confirm H-CONNECT is standard across installs (→ product-izable). Proof: read one record + write one to the test company.
P3Dispatch / logistics optimizerLowest friction
Pain: Yuval assigns drivers to service calls by hand; nothing tracks who's where, zones, capacity, or rebalancing.
To scope it, we need to
- Map their existing (Hana) tool — stack, database, what it reads/writes, where data lives. This decides ride-on vs rebuild.
- Get Hana's contact (the developer) — reachable? has the schema / source / docs?
- Trace where the tool pulls service calls + machines from — standalone DB or linked to Hashavshevet?
- Capture Yuval's dispatch logic (zones, schedules, capacity) to model the optimizer.
- Honest risk: the tool is 8 yrs old & unmaintained — riding on it may be fragile; the map tells us.
P1Parts-ID / catalog lookup tool (Toro-first)Biggest pain · hardest
Pain: matching a machine to its exact part — needs expert eyes + manual catalog hunting.
To scope it, we need to
- Get 5–10 real Toro models/serials from R.T. Cohen to test against.
- Feasibility probe (we can run now): extract Toro's public catalog (model → parts → #, description, price, drawings) reliably; confirm it's scrapable.
- Test format consistency across old + new models (his "stable 20 yrs" claim).
- Define the expert-eye gap — what stays human / escalates. Proof: a tiny lookup demo on 1–2 models.
P4Fault-codes + supplier claims
Pain #2: decode error codes fast; open/track warranty claims.
To scope it
- Source manufacturer error-code lists (Weidemann etc.) — obtainable? structured?
- Sample how Ronen answers codes today → capture the logic (KB seed).
- Map per-supplier claim process — which allow API vs manual-only.
- Get warranty $ / volume for ROI. Claims half is gated on supplier access.
P6Technician field app
He's already part-built this (digital work-card, photos, signature, auto-send).
To scope it
- Review what he built — stack, gaps.
- Decide complete his version vs rebuild.
- Tie to Hashavshevet work-cards (needs P2).
P5Customer service portalLater
Transparency: customers see their call status, timeline, ETA. He wants it — internal first.
To scope it
- Depends on P2 data (service/work-card).
- Define what customers see + their auth model.
- Light discovery until P2 exists.
+Slices & parked
Captured so they're not lost.
- Quote → order flow (USD×10 → ₪ → approve → order) — a slice of P1+P2, not standalone.
- Parked: employee-hours / job-costing (he was lukewarm).
- Parked: BI/analytics — Hashavshevet ships H-BI, may not rebuild.