Mesteparten av denne teksten er skrevet av AI som en del av utviklingsprosessen, fra notater jeg laget underveis.
Hva PoolView er, og hvem det er for.
PoolView er en diagrameditor for pumperom på basseng. Du drar komponenter — pumper, filtre, varmere, ventiler, sikringer, stikkontakter — inn på et rutenett, kobler dem sammen med rør eller ledninger, og ser systemet komme til live. Skru en ventil og strømmen nedstrøms blir gul. Slå ut en sikring og utstyret nedstrøms blir mørkt.
Det startet som et personlig verktøy for å dokumentere pumperommet på hytta. Det er på vei til å bli en vertikal SaaS for bassengselskaper. Typen små bedrifter som vedlikeholder 50+ kundelokasjoner og i dag drives på delte regneark, bildemapper og minnet til én erfaren tekniker.
Designprinsipper jeg forpliktet meg til.
Diagrammet er dokumentet
Leseretningen er fra venstre til høyre, og speiler suksjon → behandling → retur. Komponenter er dimensjonert i jevne multipler av et 24 px-rutenett, slik at en ryddig layout kan oppnås bare ved å dra. Kanter rutes i trinn med rette vinkler og avrundede hjørner, som leses som «ekte vannrør» heller enn «grafteori».
Farge bærer mening, ikke personlighet
Cyan og rosa på håndtak for kilde vs. mål. Grønt og blått på rør for suksjons- vs. retursiden, klassifisert automatisk ved å gå framover fra hver pumpe. Gul stiplet på ledninger for elektrisk, aldri til å forveksle med rør. Redusert strøm blir gul, stoppet blir rosa stiplet. Små mørke trekanter inne i hvert håndtak peker i strømretningen, slik at en fargeblind bruker fortsatt kan lese retning fra form.
Standarder som utgangspunkt, brukeren former resten
Hver komponent kommer med fornuftige håndtak. Pumper og filtre får 1 inn / 1 ut, basseng får ett av hver på hver side, manifolder kommer med tre utganger. Tilkoblingseditoren i sidefeltet lister hver tilkobling og lar teknikeren fjerne eller legge til hvilken som helst av dem. Standarder er et utgangspunkt, ikke et gulv.
Kognitiv last over fleksibilitet
Auto-ruting, omforming via dra-håndtak, smarte guider, fleridvalg-rotasjon. Det meste er fraværende. Beslutningsregelen var Teslers lov: rør er kompliserte i seg selv, brukerens diagram fanger deres skjønn, verktøyet skal ikke overprøve det. Vi auto-ruter ikke rundt hindringer. Vi lar brukeren plassere ting og stoler på layouten deres.
Hvordan det kom sammen.
Fem tekniske valg verdt å nevne, fra typesatt i18n til BFS-basert rørklassifisering.
- 01
Ett basseng, returen sløyfer tilbake
Første iterasjon behandlet suksjon og retur som separate bassengnoder for ren venstre-til-høyre-lesning. Det var en fiksjon. Et basseng er ett basseng. Nå leverer maler ett enkelt basseng med returkanten som sløyfer tilbake til høyre-bunn-håndtaket. computeEdgeFlows behandler hvert basseng som en ubetinget strømkilde og en oppryddingspasse fyller inn returkantene. classifyDirection avslutter BFS ved bassengnoder slik at bassengets utgående suksjonskanter ikke feilmerkes som retur.
- 02
Egen typesatt i18n
Jeg vurderte next-intl, men appen er en SPA og trengte ikke ruting. En 60-linjers modul med to TypeScript-filer for engelsk og norsk gir full kompileringstid-håndheving: den norske filen må implementere den kanoniske Messages-formen, og manglende nøkler er typefeil. UI-en leverer kun norsk for nå (vekslebryteren er skjult), men den engelske katalogen kompilerer fortsatt, så å skru på flerspråklighet igjen er én komponentendring. Å legge til fransk ville vært én ny fil.
- 03
Standardhåndtak per type, med valgfrie overstyringer
getKindDefaults returnerer grunnlinjen, getHandleCounts respekterer overstyringer fra datafeltet på toppen. Kantbeskjæring bruker samme funksjon som renderen, så de kan ikke drive fra hverandre.
- 04
Rørretning klassifisert automatisk
En enkel BFS fra hver pumpe merker alle nåbare rørkanter som «retur». Alt annet er som standard «suksjon». Kantkomponenten leser retning fra kantdata og velger farge.
- 05
WCAG var en rammebetingelse, ikke en ettertanke
Typoskala er 16 / 14 / 12 med 12 som gulv. Inputfelter er 16 px slik at iOS ikke zoomer ved fokus. div role='button' på interaktive noder, fordi en ekte button konflikter med React Flow-dra. Beskrivende aria-labels på hver ikonknapp. Ventil- og strømtilstander kommuniseres både med farge og en teksttagg.
Hvordan AI passer inn i dette.
Vi har basseng på hytta. Jeg har aldri vært veldig teknisk, men pappa er ingeniør og elsker å forstå sånt. Så her hadde vi muligheten sammen: jeg som lærte noe nytt, både med rammeverket og med hvordan bassenget faktisk fungerer.
Dette er første iterasjon. Forhåpentligvis kobler jeg det til Supabase snart så vi kan få live boards.
Ikke noe banebrytende. Men med kraften av nysgjerrighet, AI og litt prøving, feiling og iterasjon kan du lage noe råkult.
Det som ikke er bygget ennå.
- Inspektør-modus. Teknikeren åpner en kundelokasjon på adressen, går gjennom diagrammet som en sjekkliste, fotograferer typeskiltet, legger til et notat. Resultatet er en rapport knyttet til besøket, arkivert mot lokasjonens historikk.
- Live boards. Koble til Supabase slik at flere teknikere kan se samme pumperom i sanntid.
- Reell lastberegning (16 A sikring, 8 A pumpe er greit; legg til en varmer og det går). Eller bli ved boolsk strøm.
- Plantegning / overhead-romlig visning ved siden av venstre-høyre-flyten, eller om det bare skaper forvirring.
- Funksjonsgating per organisasjonsplan fra dag én, eller la det være gratis til noen faktisk vil betale.
- Hvor tung inspeksjonsrapporten skal være. Én-sides sjekkliste, eller full revisjon med bilder og signaturer.
- Next.js 16
- React 19
- TypeScript 5
- Tailwind CSS v4
- React Flow 12
- Zustand v5
- shadcn/ui
- base-ui
- Vercel
- Claude Code