Propane

Som Software Engineer har jeg været tæt på produktudviklingen, fra bruger-onboarding og teamstyring til abonnementslogik og forbrugsbaseret fakturering via Stripe, samt kernefunktioner i produktet.

Arbejdet har krævet både solid fullstack-arkitektur og forståelse for forretningskritiske flows, hvor klarhed, performance og vedligeholdelse er lige så vigtige som det visuelle udtryk.

Jeg lærte startup-verdenen at kende, men også vigtigheden af komponérbart kode, når retningen kan skifte fra uge til uge. Med en blanding af komposition og konfiguration kunne jeg bygge et skalerbart og vedligeholdelsesvenligt produkt.

Brugerflows til oprettelse, invitation og udløsning af vores business profiler. Bygget med Clerk til authentication. Da jeg startede hos Propane, brugte vi Clerks portaler til både at administrere og autentificere brugere. For at åbne op for flere muligheder byggede jeg de interne komponenter med Clerk, så vi havde mere kontrol over hvornår og hvordan de blev placeret.

Det kom godt med, da vi også har en public route, hvor ikke-autentificerede brugere kan se et specifikt canvas, men ikke kan kommentere uden en konto.

Abonnementshåndtering, forbrugsbaseret fakturering og integration med Stripe, fra checkout til løbende usage tracking. Jeg har arbejdet med Stripe Customer Portal, subscription tiers og usage-based billing, så produktet kan skalere med forbruget.

Meget af dette håndteres i kombination mellem Metronome, Stripe og vores backend. Det var en svær opgave at beslutte, hvor source of truth skulle ligge, og at sikre at alle tre dele var synkroniserede med webhooks fra Stripe.

Samarbejdseditor, kommentarer og AI tool-calls. Editoren og kommentarflowet er bygget til samarbejde i realtid, mens AI tool-calls integreres direkte i brugerens arbejdsgang ved at tilføje kontekst til AI-samtalen.

Alle disse features har én ting til fælles: de kommer fra Tiptap. Så jeg måtte lære, hvordan Tiptap fungerer. Deres funktionalitet er for det meste en headless editor, hvilket betyder at jeg selv skulle finde ud af at binde knuderne sammen.

En stor del af arbejdet handlede om at omstrukturere appen. Ikke kun nye features, men refaktorering af eksisterende logik og layouts, der allerede var på plads.

Det krævede hele tiden en afvejning: hvornår skulle noget have dedikeret logik, og hvornår var casen lille nok til at lade den blive, hvor den var. Undervejs fokuserede jeg på separation of concerns, så UI, data og forretningslogik blev nemmere at forstå og vedligeholde.