Project overview We’re building a web tool that lets users design a fence plan directly on top of Google Maps: draw fence runs, place gates, add posts and accessories, and get a live measurement/estimate. We need an experienced frontend developer to build the drawing and interaction engine — the core mechanics of the map editor itself.
This is a well-specified, self-contained module. You’ll receive: * A detailed written specification covering every interaction rule (drawing, snapping, joints, angles, closed loops, gates, sliding gates, fence gaps, posts, terrain notation, hotkeys, undo/redo), including a data-model reference and pseudocode for the key mechanics. * A working interactive HTML/SVG reference build (vanilla JS, no framework) that demonstrates every scenario live — you’ll be able to click through it to see exactly how each interaction should behave before writing any production code. * A set of acceptance-test scenarios that define “done” for each feature.
What you’ll build * A React + TypeScript implementation of the reference build’s drawing engine, rendering an SVG overlay synced to a real Google Maps instance (the reference build itself runs on an abstract SVG canvas, not real map coordinates — wiring it up to actual geo-coordinates is part of this task). * Full interaction logic: drawing fence runs point-by-point with live metric dimensions, magnetic snapping/joining/disjoining between runs, 90°/exact-angle joints, closed loops, swing and sliding gates, real fence gaps around obstacles, automatic and manual posts, site objects (house, tree, pool, etc.), terrain markers (raked/step-down). * A single-step undo/redo history covering every action (move, join, disjoin, length edit, gap creation). * Keyboard shortcuts that work regardless of keyboard layout (physical key codes, not typed characters).
Tech stack * React + TypeScript * Google Maps JavaScript API (e.g. @vis.gl/react-google-maps or the official loader) with a custom overlay for the SVG layer * SVG for all geometry, handles, and contextual UI (not Canvas — the spec relies on individual hit-areas, readable rotated text, and DOM-level interactivity) * Pointer Events API for unified mouse/touch/stylus handling, with a deliberate drag threshold (~4—7px) before a click becomes a drag * State management of your choice — the reference build implements undo/redo as simple JSON snapshots per action, which is an acceptable pattern to follow rather than a full architectural rewrite
Approach we’re looking for The reference build already contains working, battle-tested logic for every interaction (snapping, joining, dimensioning, gate geometry). We’re not looking for a ground-up redesign — we want that logic ported and typed, then wired to real map coordinates. A pragmatic port that keeps the proven imperative core close to the reference implementation is preferred over a full idiomatic React rewrite; this keeps cost and timeline down without sacrificing correctness. What’s out of scope * Pricing and quote calculations (handled separately) * Product/catalog data sourcing (handled separately) * Final visual styling of buttons, panels, and typography (comes from separate design files; you’re implementing behavior, not pixel-perfect skinning) * Backend, auth, and project storage — a REST backend already exists; you’ll only need to call a save/load endpoint
Requirements * Strong React + TypeScript experience, comfortable with complex, deeply-nested client-side state * Prior experience with the Google Maps JavaScript API (custom overlays, coordinate projection) * Solid SVG skills: manual geometry math (distance, projection onto a segment, angle calculation), not just static SVG markup * Experience building drag-and-drop interactions from scratch with Pointer Events (not just wrapping a pre-built library) * Ability to read a detailed written spec precisely and flag ambiguities rather than guessing
Nice to have * Experience building CAD-like or diagram/floor-plan editors (snapping, joints, dimension lines) * Familiarity with undo/redo history design for interactive editors
What to include in your application Please review the specification and reference build, then share: * Your estimated hours (or a range) for the full scope described above * Any parts of the spec you’d flag as higher-risk or likely to take longer than expected * Whether you’d suggest descoping anything (e.g. sliding gates, fence gaps, terrain notation, site objects) to fit a tighter budget, and the estimated impact on hours
Deliverables & acceptance Work is considered complete when all acceptance-test scenarios from the specification pass on both mouse and touch input, with no console errors and no orphaned data references after delete/split operations.
