Mjukvaruutveckling för företag vars arbetsflöden inte passar i något standardverktyg.

01

Vem det är för och vad det löser

Mjukvaruprojekt börjar oftast med en nödlösning som har vuxit sig för stor. En driftchef har den verkliga planen i ett kalkylark eftersom det officiella systemet inte kan uttrycka den. Ett logistikföretag följer uppdrag i mejltrådar och telefonsamtal. En utbildningsanordnare hanterar anmälningar, fakturor och intyg för hand i tre olika verktyg. En besiktnings- och värderingsfirma är beroende av en gammal PHP-applikation som ingen vågar ändra i. En grundare har en produktidé och behöver en första version som riktiga kunder kan använda. Gemensamt för situationerna är dubbel inmatning, ingen gemensam källa till data, för grova behörigheter och rapporter som sätts ihop för hand varje månad. Vi ersätter nödlösningen med ett system som modellerar den verkliga processen, så att data matas in en gång och finns tillgänglig för dem som behöver den.

02

Det vi bygger

Vi tar ansvar för hela produkten, från datamodellen till den skärm användaren ser. Exemplen nedan kommer från våra egna produkter och från kundarbete.

• Interna system och administrationsverktyg
• Översikter och driftsrapportering
• API:er och integrationer mellan befintliga system
• SaaS-produkter för flera kunder, med företag, platser och roller
• Modernisering av äldre system, till exempel från PHP till TypeScript
• Kundportaler, till exempel felanmälan med prioritetsnivåer

03

Så går ett mjukvaruprojekt till

Risken i ett mjukvaruprojekt är att bygga fel sak väl. Arbetssättet är utformat för att upptäcka det tidigt och billigt.

1. 1Omfattning: vi kartlägger användare, arbetsflöden, data och de system som ska kopplas ihop. Du får en skriftlig omfattning där första versionen är tydligt skild från senare idéer, och en offert för den versionen.
2. 2Arkitektur och UX: datamodell, roller och behörigheter samt de viktigaste skärmarna som klickbara flöden. Du får en beskrivning av arkitekturen och skärmarna att godkänna innan utvecklingen börjar.
3. 3Utveckling: frontend, backend och integrationer byggs i korta iterationer. Du får en fungerande version i en förhandsmiljö efter varje iteration och kan testa den med verkliga fall.
4. 4Driftsättning: datamigrering, användarkonton, sluttester och publicering i produktion. Du får det körande systemet och en genomgång för dem som ska använda det.
5. 5Drift och förbättring: rättningar och nya funktioner prioriteras utifrån verklig användning. Kunder rapporterar problem via en ärendeportal med prioritetsnivå, så att brådskande problem hanteras först.

04

Teknik och tekniska beslut

Vi skriver TypeScript på båda sidor av applikationen: React i webbläsaren och Node.js på servern, så att ett typsystem täcker hela produkten och många fel fångas innan koden körs. Data lagras i PostgreSQL. GastroApp, vår produkt för restaurangdrift, använder ett REST-API, Prisma som ORM, tokenbaserad autentisering och rollbaserade behörigheter på en modell där ett företag har flera platser och varje användare är behörig för utvalda platser. Lättare API:er, som order- och kontofunktionerna på den här webbplatsen, körs på Cloudflare Workers med serverlös Postgres. Betalningar, transaktionsmejl och fillagring integreras genom leverantörernas egna API:er och inte genom tillägg. Automatiska tester och typkontroll körs före varje driftsättning, och driftsättning sker från Git. Vi väljer beprövade komponenter framför nyheter, eftersom verksamhetsmjukvara ska underhållas i många år.

05

Så ser en bra första version ut

Den första versionen ska vara liten nog att bli klar och komplett nog att användas varje dag. I praktiken betyder det ett centralt arbetsflöde från början till slut, de roller som deltar i det, den data det kräver och den enda integration utan vilken systemet skulle skapa dubbelarbete. Allt annat hamnar på en lista för senare. Det är inget sätt att leverera mindre. Ett system som används dagligen ger bättre krav än någon workshop, och den andra versionen planeras utifrån vad människor faktiskt gör i den första. Det håller också budgeten under din kontroll, eftersom varje steg offereras och godkänns för sig.

06

Budget, tidsplan och när man inte ska bygga

Kostnaden följer antalet användarroller, datamodellen, integrationerna och hur stor del av processen den första versionen ska hantera. Vi publicerar inga prisintervall, eftersom en siffra utan omfattning skulle vilseleda. Vår guide om vad mjukvaruutveckling kostar i Danmark beskriver kostnadsdrivarna och hur man budgeterar i etapper. Skräddarsydd mjukvara är inte heller alltid svaret: om en standardprodukt täcker processen väl är det billigare och snabbare att köpa den, och det säger vi. Jämförelsen mellan skräddarsydd mjukvara och SaaS förklarar var gränsen brukar gå.