Softwareudvikling i Danmark for virksomheder med komplekse arbejdsgange.

01

Hvem det er til, og hvad det løser

Softwareprojekter begynder som regel med en nødløsning, der er vokset for stor. En driftschef har den rigtige plan i et regneark, fordi det officielle system ikke kan udtrykke den. En logistikvirksomhed følger opgaver i mailtråde og telefonopkald. En kursusudbyder håndterer tilmeldinger, fakturaer og beviser manuelt i tre værktøjer. En virksomhed, der laver ekspertvurderinger, er afhængig af en gammel PHP-applikation, som ingen tør ændre. En stifter har en produktidé og mangler en første version, som rigtige kunder kan bruge. Det fælles er dobbelt indtastning, ingen samlet kilde til data, for grove rettigheder og rapporter, der bliver samlet i hånden hver måned. Vi erstatter nødløsningen med et system, der afspejler den reelle proces, så data bliver indtastet én gang.

02

Hvad vi bygger

Vi tager ansvar for hele produktet, fra datamodel til det skærmbillede, brugeren ser. Eksemplerne herunder kommer fra egne produkter og kundearbejde.

• Interne systemer og administrationsværktøjer
• Dashboards og driftsrapportering
• API'er og integrationer mellem eksisterende systemer
• Multi-tenant SaaS-produkter med virksomheder, lokationer og roller
• Modernisering af ældre systemer, for eksempel fra PHP til TypeScript
• Kundeportaler, for eksempel fejlmelding med hastegrad

03

Sådan arbejder vi

Risikoen i et softwareprojekt er at bygge det forkerte rigtig godt. Forløbet er lagt an på at opdage det tidligt og billigt.

1. 1Scope: vi kortlægger brugere, arbejdsgange, data og de systemer, der skal forbindes. I modtager et skriftligt scope, hvor første udgave er tydeligt adskilt fra senere idéer, og et tilbud på den.
2. 2Arkitektur og UX: datamodel, roller og rettigheder samt de vigtigste skærmbilleder som klikbare flows. I modtager en beskrivelse af arkitekturen og skærmbillederne til godkendelse.
3. 3Udvikling: frontend, backend og integrationer bygges i korte iterationer. I modtager en fungerende version i et preview-miljø efter hver iteration.
4. 4Lancering: datamigrering, brugerkonti, afsluttende test og udgivelse til produktion. I modtager det kørende system og en gennemgang til brugerne.
5. 5Drift og forbedring: rettelser og nye funktioner prioriteres ud fra reel brug. Fejl meldes i en ticketportal med hastegrad, så det presserende bliver håndteret først.

04

Teknologi og tekniske valg

Vi skriver TypeScript på begge sider af applikationen: React i browseren og Node.js på serveren, så ét typesystem dækker hele produktet. Data ligger i PostgreSQL. GastroApp, vores produkt til restaurantdrift, bruger et REST API, Prisma som ORM, token-baseret login og rollebaserede rettigheder oven på en multi-tenant-model, hvor en virksomhed har flere lokationer, og hver bruger er godkendt til udvalgte lokationer. Lettere API'er, som ordre- og kontofunktionerne på dette site, kører på Cloudflare Workers med serverless Postgres. Betaling, transaktionsmails og fillagring bliver integreret gennem udbydernes egne API'er og ikke gennem plugins. Automatiske test og typekontrol kører før hver udgivelse, og udgivelsen sker fra Git. Vi vælger gennemprøvede komponenter frem for nyheder, fordi forretningssoftware skal vedligeholdes i mange år.

05

Sådan ser en god første udgave ud

Første udgave skal være lille nok til at blive færdig og komplet nok til at blive brugt hver dag. I praksis betyder det én central arbejdsgang fra start til slut, de roller, der indgår i den, de data, den kræver, og den ene integration, uden hvilken systemet ville skabe dobbeltarbejde. Alt andet kommer på en liste til senere. Et system, der bruges dagligt, giver bedre krav end nogen workshop, og anden udgave bliver planlagt ud fra, hvad folk faktisk gør i den første. Det holder også budgettet under jeres kontrol, fordi hvert trin får sit eget tilbud.

06

Pris, tidsplan og hvornår man ikke skal bygge

Prisen følger antallet af brugerroller, datamodellen, integrationerne og hvor meget af processen første udgave skal dække. Vi offentliggør ikke prisintervaller. Guiden til, hvad softwareudvikling koster i Danmark, beskriver, hvad der driver prisen. Specialudviklet software er heller ikke altid svaret: Dækker et standardprodukt processen godt, er det billigere og hurtigere at købe det, og det siger vi.