När vi bestämda oss för att Fixa, Fixa

Fixa är vårt egna system för att hantera våra kunder och projekt. Det är där vi samlar projektöversikt, kundinformation, tidrapportering, planering, fakturaunderlag och en hel del annat som behövs för att kunna sköta det dagliga arbetet på en utvecklingsbyrå.

Som med många interna system är Fixa sprunget ur ett behov i kombination med teknisk nyfikenhet och utbildningsmöjligheter. Vi behövde något som passade vårt sätt att arbeta, som gick snabbt att ändra och som inte tvingade in oss i ett färdigt arbetssätt. Det gamla Fixa gjorde det jobbet bra under lång tid.

Men efter några år märkte vi att systemet hade blivit viktigt på ett annat sätt än från början. Det var inte längre bara ett internt verktyg med några praktiska funktioner. Det hade blivit en central del av hur vi planerar, följer upp och håller ihop information kring våra projekt.

Och då började också bristerna synas tydligare.

Inte nödvändigtvis för den som bara skulle rapportera tid eller hitta ett projekt. Men för oss som byggde vidare på systemet blev det allt mer tydligt att grunden inte riktigt följde med längre.

Framför allt blev det svårare att utveckla vidare
i den takt vi ville.

Det gamla Fixa

Det gamla Fixa var byggt i PHP och hade med tiden fått mer modern frontend ovanpå, bland annat TypeScript och React. Det var inget konstigt med det. Så växer många system fram.

Man bygger en funktion när behovet finns. Sedan bygger man nästa. Och nästa.

Efter ett tag har man ett system som gör mycket, men där det inte alltid är helt självklart var ny funktionalitet ska ligga, hur saker hänger ihop eller vilka gamla beslut som fortfarande påverkar nya delar.

I vårt fall fanns det en blandning av äldre PHP-vyer, Bootstrap, jQuery-relaterade beroenden, DataTables, React-komponenter och TypeScript. Det fungerade, men det blev också svårare att få systemet att kännas som en sammanhållen applikation.

Framför allt blev det svårare att utveckla vidare i den takt vi ville.

Varför vi valde att bygga om

Att bygga om ett system är nästan aldrig ett enkelt beslut. Det är lätt att underskatta hur mycket som faktiskt finns i ett internt verktyg som använts i flera år.

Det handlar inte bara om att återskapa sidor och formulär. Det handlar om små beteenden, gamla specialfall, arbetssätt som sitter i väggarna och funktioner som någon använder mer än man först tror.

Därför ville vi inte bygga om Fixa bara för att få nyare teknik. Det hade varit ett ganska dåligt skäl.

För oss handlade det mer om att få en tydligare grund för nästa steg. Vi ville kunna arbeta mer konsekvent med projekt, kunder, planering, tid och dokumentation. Vi ville också kunna bygga systemet mer som en produkt, även om det började som ett internt verktyg.

Den nya grunden

Nya Fixa byggs med Laravel, React och Inertia.

Laravel ger oss en tydligare backend med routes, controllers, modeller, migreringar och de konventioner som följer med ett etablerat ramverk. Det gör stor skillnad när ett system ska leva länge och fler utvecklare ska kunna förstå hur det är uppbyggt.

React gör att vi kan bygga gränssnittet mer komponentbaserat. Formulär, tabeller, modaler, statusar och andra återkommande delar kan återanvändas istället för att byggas om på nytt i varje vy.

Inertia gör att vi kan kombinera Laravel och React utan att behöva bygga ett separat API för varje del av systemet. Det passar bra för den här typen av applikation, där vi vill ha en modern användarupplevelse men fortfarande behålla mycket av enkelheten i en klassisk Laravel-applikation.

Det låter kanske tekniskt, men i praktiken handlar det mest om att göra det lättare att bygga rätt saker på rätt plats.

Från isolerade sidor till arbetsflöden

En av de större skillnaderna är hur vi tänker kring gränssnittet.

I gamla Fixa var många delar mer som separata sidor med sina egna funktioner och egenskaper. Det fungerar ganska bra så länge funktionerna är enkla. Men när man börjar arbeta med planering, drag and drop, filter, flikar, filer, anteckningar och dynamiska listor blir det snabbt svårare att hålla ihop.

I nya Fixa försöker vi istället bygga systemet efter hur vi faktiskt arbetar och tänker.

Ett projekt ska inte enbart vara en rad i en lista. Det ska kunna samla information om kund, kontaktpersoner, budget, deadline, repo, externa länkar, teknisk dokumentation, anteckningar och filer.

På samma sätt ska ett företag inte bara vara ett namn. Det ska kunna ha personer kopplade till sig, anteckningar och historik som gör det lättare att hitta all relevant information i ett och samma system.

Det är sådana saker som gör ett system användbart över tid. Inte för att varje enskild funktion är avancerad, utan för att informationen hamnar där man förväntar sig att hitta den.

Möjlighet att expandera med multi-tenancy

En av de mer omfattande delarna i nya Fixa är stödet för flera tenants. En tenant i detta fallet är en isolerad arbetsyta, med sina egna användare, inställningar och innehåll.

I praktiken gör det Fixa mer förberett för att användas fler företag och organisationer, och inte enbart som ett internt verktyg.

Det här har också varit en av de delar som krävt mest eftertanke.

Inloggning, subdomäner, tenant-val, migreringar, databaser och relationen mellan användare och arbetsytor behöver fungera på ett bra sätt. Det är inte något man bara lägger till på slutet.

Samtidigt är det just den typen av beslut som påverkar hur stort ett system kan växa. Multi-tenancy gör systemet mer komplext, men ger också en möjligheter framåt att expandera det.

Projekt, tid och planering

Projekt är fortfarande en av de viktigaste delarna i Fixa.

I nya versionen har vi lagt mer vikt vid att projekt faktiskt ser olika ut. Ett projekt kan vara ett mindre uppdrag, men det kan också vara en lång relation, en produkt eller en webbplats som lever över flera år.

Därför finns stöd för huvudprojekt och underprojekt. Tanken är att den långsiktiga informationen kan ligga kvar på huvudprojektet, medan mer konkreta insatser kan ha egen budget, egen tidsram och egen fakturering.

Tidrapporteringen byggs också med mer kontext. Det ska gå att se hur mycket tid som finns kvar mot estimerad tid, framför allt i fastprisprojekt. Det finns också tankar kring taggar för rapporterad tid, till exempel möte, sälj eller estimat, så att tiden inte bara blir fakturaunderlag utan också något vi kan lära oss av.

Planeringen är en annan del där den nya tekniska grunden märks tydligt. Veckoplanering och långtidsplanering behöver kännas snabba att arbeta med. Projekt ska kunna flyttas, justeras och planeras utan att det känns som att man hela tiden väntar på sidan.

Det låter enkelt, men det är ofta där skillnaden mellan ett system man använder och ett system man undviker uppstår.

Dokumentation där den hör hemma

En sak vi ofta saknat är ett bättre sätt att hålla ihop den information som finns runt ett projekt.

I praktiken ligger mycket utspritt. Figma, Google Docs, GitHub, kundens Jira, Clickup, Trello, Slack och andra verktyg. Vi vill inte ersätta alla de verktygen med Fixa. Det hade varken varit rimligt eller särskilt bra.

Däremot vill vi att Fixa ska kunna samla länkarna, anteckningarna och den interna kontexten.

Om någon behöver hitta designen, repot, dokumentationen eller kundens projektverktyg ska det gå att börja i Fixa. Om någon har skrivit en viktig anteckning om projektet ska den inte bara försvinna i en Slack-tråd.

På sikt vill vi också kunna koppla mer teknisk information till projekt, till exempel tech stack från GitHub och dokumentation från repo. Det skulle göra Fixa mer användbart även för utvecklare som snabbt behöver förstå ett projekt de inte jobbat i tidigare.

Dashboarden

Startsidan i nya Fixa är tänkt att vara mer än en landningssida.

Det ska vara en arbetsyta där man kan se sin planering, rapportera tid, få överblick över projekt och se sådant som är relevant för dagen.

För en utvecklare kan det handla om planering, tid och information från GitHub. För en projektledare kan det handla om budget, deadlines och projektstatus. För administratörer kan det handla om fakturering, användare och uppföljning.

Det viktiga är att systemet inte bara blir något man öppnar när man måste. Det ska hjälpa till i vardagen.

🎓 Lärdomar och slutsatser

Att bygga om Fixa har lärt oss mycket om vår egen process.

Vi har behövt reda ut tekniska frågor kring hur vi arbetar med och sätter upp Laravel, Inertia, multi-tenancy, Google-inloggning, Docker, deploy, migrationer, Sentry, Vite och lokal utvecklingsmiljö. En del har gått snabbt. Annat har krävt omtag och omvärdering.

Det har också blivit tydligt hur viktigt det är att bryta ner stora idéer till mindre delar. Många funktioner låter enkla när man pratar om dem, men blir mer komplexa när man börjar titta på relationer, behörigheter, gamla arbetssätt och hur information faktiskt används.

Det är kanske också det som gör arbetet intressant och lärorikt.

Fixa är inte ett påhittat case. Det är ett system vi själva använder. När något blir bättre märker vi det. När något blir krångligt eller inte fungerar, så påverkar det oss själva direkt.

Det gamla Fixa var inte fel eller trasigt. Det gjorde mycket rätt, och det har hjälpt oss att förstå vad vi faktiskt behöver.

Det nya Fixa är snarare ett försök att ta med oss de lärdomarna in i en bättre grund.

Vi vet mer nu om hur vi vill strukturera projekt. Vi vet mer om hur tid, planering och fakturering hänger ihop. Vi vet mer om vilken information som behöver finnas på företag, personer och arbetsytor. Och vi vet mer om vilken typ av kodbas vi vill arbeta i över tid.

Så även om vi bygger om mycket från grunden känns det inte som att vi börjar om.

Det känns mer som att vi bygger den version vi hade velat ha från början, men nu med facit från flera års användning.