The irritation
Territory changes are deceptively dangerous. A quick boundary edit can silently change routing, ownership, reporting, and an entire sales team’s operating reality.
ProductBuildingIn development
Territory Logic
A revisioned territory-planning system that lets teams model, test, and safely roll back geographic ownership changes.
- Current state
- Building — In development
- Jack’s role
- Product architecture, Geospatial engineering, Cloud systems, HubSpot integration
- Find it in the workshop
- Systems & Maps Lab · Illuminated map table
Built because…
The real build story.
What I built
I designed a multi-tenant map system with spatial queries, draft revisions, conflict simulation, queued calculations, publishing, and rollback.
The hard part
The difficult work is preserving tenant isolation and a trustworthy history while geographic edits and downstream CRM updates happen asynchronously.
Under the casing
Proof, not decoration.
Build evidence03 items
- PostGIS-backed boundary and intersection operations
- Draft simulation, revision history, publishing, and rollback
- Tenant-scoped access with queued downstream processing
- MapLibre
- PostGIS
- Hono
- Cloudflare Workers
- Queues
- Workflows
- R2
- Hyperdrive
Scope of work
What I owned.
- Product architecture
- Geospatial engineering
- Cloud systems
- HubSpot integration
No victory-lap math
Outcome and lesson.
Where it landed
The current build has the shape of a production system: explicit revisions, simulated consequences, controlled publication, and recovery instead of direct map edits.
What stayed
Operational software should make consequences visible before it makes changes permanent. Reversibility is a product feature, not just a database concern.
This project has a physical address.
In the playable workshop, Territory Logic lives in the Systems & Maps Lab as a illuminated map table. You can inspect it without unlocking anything.