Plattform och teknisk kontroll

Vårt arbetssätt är code-first low-code, inte low-code som en ”svart låda”.

I plattformen finns två typer av kod: baskod (återanvändbara komponenter och tjänster) och autogenererad projektkod. Det viktiga är att all kod (baskod eller genererad kod) ursprungligen är skriven av ingenjörer. En utvecklare implementerar först en komponent/modul/tjänst enligt vår interna kodstil och branschstandarder, varefter den granskas och testas. Därefter omvandlas komponenten manuellt till en mall som passar generatorn och som kan ingå i en applikationsmall.

Under den inledande utrullningen (vanligtvis ~20–40 minuter) av en kundlösning anpassas (refaktoreras) mallkoden av generatorn så att den motsvarar kundprojektet (t.ex. namngivning, prefix, namnrymder, copyrighthuvuden osv.). Som en del av denna process skapas en kopia av komponenten/mallen, som lagras i ett separat, dedikerat kodförråd som skapats för just den kunden och det projektet. Den refaktorerade kopian följer samma kodstandarder och kodstil och är tillgänglig för manuell utveckling och ändringar efter driftsättningen.

Autogenererad kod är tillgänglig för felsökning och utbyggnad (t.ex. via partiella klasser och arv) och förblir läsbar och standardenlig.

Exempel på autogenererad kod (merparten):

• TypeScript-modeller för frontend som genereras från backendens datamodeller och gränssnitt i C#
• Lokaliseringshjälpare för frontend (översättningsvariabler) som krävs för ett flerspråkigt användargränssnitt
• Grundläggande hjälp- och mappningsklasser för vanliga UI-representationer (strängar, listelement osv.)

Exempel på baskod (återanvändbar kod):

• AuthService – autentisering och auktorisering
• NotificationService – notifieringar (e-post, sms, push, i appen)
• FileService – lagring/hantering av filer och bilder
• SyncService – återanvändbara integrationsmekanismer för anslutning till ERP-system (inkl. synkroniseringsmönster)

Förtydliganden (riskminskning)

Ingen ”magi” vid körning

Kodgenereringen sker under uppsättningen/implementeringen; resultatet är en vanlig kodbas, inte dold logik som körs i en proprietär motor.

Underhållbarhet

Den genererade och refaktorerade koden följer en enhetlig kodstil och enhetliga arkitekturkonventioner.

Säkra utbyggnadspunkter

Vi bygger ut med standardmekanismer (partiella klasser, arv, separata tilläggsfiler) så att uppdateringar/omgenerering inte skriver över kundspecifik logik.

I vår modell börjar den kundanpassade utvecklingen direkt efter projektets inledande utrullning.

När kunden har registrerats i ReApptor Portal gör vi en inledande driftsättning (vanligtvis ~20–40 minuter). Under denna utrullning skapar vi en fullt fungerande, isolerad kundmiljö och en kundspecifik kodbas för applikationen:

• Koden skapas som en refaktorerad kopia av de valda mallarna/modulerna
• Alla nödvändiga CI/CD- och driftsättningsskript ingår
• Allt lagras i ett separat, dedikerat kodförråd som skapats för just den kunden och det projektet

Från den tidpunkten bedrivs utvecklingsarbetet som i ett vanligt mjukvaruprojekt: våra ingenjörer ansluter till det nyskapade kundförrådet och hämtar den refaktorerade projektkoden. Alla vidare ändringar genomförs i kundprojektets kodbas och hanteras med normal praxis för mjukvaruutveckling (versionshantering, kodgranskning, CI/CD, releaser).

Med andra ord: efter utrullningen handlar det inte längre om att ”konfigurera en plattform som är en svart låda” – vi utvecklar och vidareutvecklar er lösning i dess eget kodförråd och dess egen miljö.

Plattformen är optimerad för transaktionella affärsflöden, bland annat order, uppgifter, inspektioner, dokument, medarbetare osv.

Den är inte avsedd att vara:

• En 3D-CAD-motor i realtid
• Ett fullskaligt MES/PLC-styrsystem
• En tung plattform för data science/big data-analys på egen hand

Vi integrerar med sådana system där det behövs (t.ex. CAD, BI-verktyg, ERP), men vi har inte som mål att ersätta dem.

Ett specialiserat system passar bättre när kravet blir:

• Realtidsstyrning av maskiner på millisekundnivå
• Extremt komplex CAD-manipulering på låg nivå i webbläsaren

För allt som rör orderhantering, planering, arbetsorder, digitala kvalitetskontroller, dokumenthantering och mobilt arbete ligger komplexiteten väl inom ramen för vad plattformen hanterar effektivt.

I vår modell finns inget hårt funktionellt ”plattformstak” i klassisk low-code-mening, eftersom lösningen efter utrullningen körs som en vanlig, fristående kodbas (kopierade tjänster/komponenter + kundens kodförråd). Vi arbetar inte inuti en ”plattformslåda” med egen körmiljö, så det finns inget funktionellt ”tak” där plattformen inte längre kan stödja komplexiteten.

I praktiken blir frågan: vid vilken punkt upphör lösningen att främst påskyndas av återanvändbara moduler/mallar och blir främst kundanpassat ingenjörsarbete, samtidigt som den förblir fullt supporterad, skalbar och underhållbar?

Den punkten nås först när kraven går från ”affärssystemskomplexitet” (som vi konstruerar för) till specialiserade begränsningar på FoU-nivå, till exempel:

Optimeringsmotorns omfattning

Om produktionsplaneringen utvecklas till en fullständig villkorslösare (constraint solver) med kontinuerlig automatisk omplanering och flermålsoptimering (inte bara schemaläggning/överblick).

Extrema icke-funktionella krav

Mycket hög samtidighet och genomströmning med hårda krav på UI-uppdateringar i realtid och svarstider under en sekund i mycket stor skala.

Tunga pipelines för CAD/visuell beräkning

Om ni kräver rendering, konvertering och bearbetning av stora CAD-tillgångar på serversidan som en kärnförmåga (utöver att lagra/versionshantera/godkänna ritningar).

Även i de fallen är svaret fortfarande ”vi kan genomföra det” – men vi behandlar det som ett separat ingenjörspaket med uttryckligen avgränsad omfattning, tydliga acceptanskriterier och prestandatester, så att det inte obemärkt förbrukar budget eller tidsplan.

Krav som rör order, arbetsuppgifter, planeringsvyer, leverans, inspektioner, integrationer, filhantering och skalbar tillväxt hör helt och hållet hemma i den kategori som plattformen byggdes för.

Tekniskt sett är lösningen en standardmässig molnbaserad (cloud-native) webbapplikationsstack som driftsätts som en dedikerad kundmiljö:

Backend

.NET (C#) med en relationsdatabas (MySQL / Aurora).

Frontend

React / TypeScript (webb + mobilanpassat användargränssnitt).

Filer (formulär, order, ritningar/CAD och andra bilagor)

Lagras i objektlagring (AWS S3) med strömning och signerade URL:er (inga ”filer via databasen”).

Driftsättning

Containerbaserade tjänster med horisontell skalning, lastbalansering och produktionsövervakning.

AI

En kombination av interna och externa AI-tjänster används för intelligent bearbetning och automatisering av dokument, röst, video, bilder, granskningar, ritningar och andra uppgifter.

Ur ett kapacitetsperspektiv omfattar vår kommersiella modell fördefinierade infrastrukturnivåer (Standard / Medium / Extra) med en förutsägbar månadskostnad per applikation, beroende på nivån.

För en typisk inledande omfattning och indikativa kapacitetsantaganden (ett enda land, färre än 1 000 aktiva användare och färre än 1 000 000 order per år) rekommenderar vi nivån Standard. Om volymerna växer kan ni uppgradera nivån utan att ändra applikationsarkitekturen. Priset är fast under den överenskomna löptiden.

Ja. Alla miljöer övervakas kontinuerligt (mätvärden för infrastruktur + applikation), inklusive resursutnyttjande, svarstider, databasbelastning och fil-/lagringsanvändning. Vi kan dela ögonblicksbilder av prestandamätningar samt trendrapporter från jämförbara produktionssystem (under NDA).

Exempel från produktion (nivån Standard)

Beställningar inom hälso- och sjukvården

~30 % genomsnittligt resursutnyttjande; 494 496 orderrader; 582 aktiva användare; 9 338 unika produkter; 96 809 sortiment; 84 215 filer; 330 kundplatser (sjukhus).

Biljetthantering och bokning

~10 % genomsnittligt resursutnyttjande; 1 517 bokningar; 4 737 passagerare; 5 112 aktiva användare.

Hantering av hamntjänster och uppgifter

~3 % genomsnittligt resursutnyttjande; 3 358 tjänster; 363 aktiva användare; 6 451 dokument.

Tillverkning av hisspaneler

34 774 order; 953 produktgrupper; 9 659 produktsortiment.

Teknisk skuld hanteras som i vilken professionell mjukvaruprodukt som helst:

• Delade plattformsmoduler versionshanteras, testas och refaktoreras kontinuerligt
• Kundspecifik logik ligger i separata kodförråd med kodgranskning, automatiserade tester och CI/CD
• Varje ändring kan spåras till ett ärende (Jira) och dokumenteras

Low-code betyder i vårt fall inte ”ingen kod och ingen kontroll”; det betyder att vi minskar dupliceringen och centraliserar gemensamma mönster, så att skulden blir lättare att se och hantera.

All kundanpassad kod är:

• Standard C# / .NET och React / TypeScript
• Organiserad i en ren, skiktad arkitektur
• Förvaltad i ett vanligt Git-kodförråd (Bitbucket)
• Dokumenterad på kod- och lösningsnivå

Det finns inget proprietärt skriptspråk som bara ReApptor förstår.

Eftersom all genererad kod tas fram från mallar som ursprungligen skrivits av ingenjörer följer den samma interna kodstil och ingenjörsstandarder som handskriven kod.

Funktions- eller säkerhetsuppdateringar av plattformen införs i en kundlösning endast genom en kontrollerad, manuellt godkänd releaseprocess: de dokumenteras i Jira, granskas/godkänns, testas i test- och stagingmiljöer, regressionstestas och släpps därefter till produktion genom en ny driftsättning.

Vi följer en versionshanterad, bakåtkompatibel releasemodell:

• Plattformsbibliotek publiceras som versionerade paket (NuGet / npm).
• Brytande ändringar undviks och införs, om de någon gång behövs, endast i huvudversioner.
• Kundlösningar låser specifika plattformsversioner och uppgraderas på ett kontrollerat sätt.
• Ny funktionalitet aktiveras vanligtvis genom ett aktivt val (opt-in) via konfiguration och/eller funktionsflaggor.

På så sätt kan vi kontinuerligt förbättra plattformen samtidigt som den kundspecifika logiken förblir stabil och förutsägbar.

Plattformen är redan i produktion för:

• Order- och uppgiftsstyrd verksamhet
• Arbetsflöden för service och underhåll
• Arbetsflöden för säkerhetsrapportering
• Mobila fältarbetare (t.ex. logistik, bygg, hälso- och sjukvård)

Dessa lösningar körs med SLA, övervakning och kontinuerliga uppdateringar.

Våra största användningsfall i dag omfattar fleråriga operativa system med:

• Tusentals slutanvändare över tid
• Hundratusentals order och uppgifter
• Integrationer med ERP och andra kärnsystem

En av våra största kundlösningar finns inom hälso- och sjukvården och har varit i produktion i flera år. Produktionsmätvärden med datumangivelse kan granskas under NDA.

Vi kan dela konkreta kundreferenser och anonymiserade mätvärden under NDA för att ge en mer exakt bild.

Teknisk skalbarhet uppnås genom:

• Horisontellt skalbara applikationsnoder
• Separata databaser per kund och applikation
• Separat objektlagring i molnet för filer per kund och applikation
• Bakgrundsprocesser för långvariga jobb

Arkitekturen är utformad så att vi, om kundens volym växer (fler order, fler medarbetare, fler kunder), kan skala ut infrastrukturen utan att konstruera om applikationen.

Den kommersiella skalbarhetsmodellen är:

• En fast månadsavgift för plattform och infrastruktur
• Transparenta utvecklingsalternativ (fast omfattning eller abonnemang)
• Tre mindre förbättringar per månad ingår i licensen efter den aktiva utvecklingen

När er användning växer inför vi inga straffavgifter per användare eller per order. Om infrastrukturkostnaderna ökar väsentligt (t.ex. på grund av mycket högre volymer) hanteras detta genom tydliga tröskelvärden och dialog, inte genom ensidiga ändringar.

Vi säkerställer bakåtkompatibilitet genom att:

• Versionshantera API:er och datastrukturer
• Införa nya funktioner som valfria tillägg
• Underhålla migreringsskript för schemaändringar

För en kund innebär det att vi under de kommande åren kan:

• Lägga till nya moduler
• Vidareutveckla befintliga vyer
• Förbättra prestandan

Allt detta utan att tvinga fram störande omkonstruktioner eller långa frysperioder.

Dessutom omfattar månadslicensen tre mindre förbättringar/funktioner per månad efter den aktiva utvecklingsfasen, för att säkerställa en kontinuerlig och förutsägbar utökning av lösningens funktionalitet och affärsvärde.

Vi kan tillhandahålla produktionsreferenser och genomgångar (under NDA vid behov) inom tre områden som kan matchas mot kundens krav:

• Order- och arbetsflödesstyrd verksamhet (order, uppgifter, rollbaserade användargränssnitt, godkännanden, rapportering).
• Schemaläggning/planering och operativt genomförande (arbetsorder, tilldelning av uppgifter, överblick över kapacitet).
• Arbetsflöden för inspektion/kvalitet/service (steg-för-steg-checklistor med foton/kommentarer, genomförande med mobilen i första hand).

Exempel är försörjningsflöden inom hälso- och sjukvården, orderkonfiguratorer och priskalkylatorer för flyttjänster riktade till konsumenter samt operativ uppgifts- och servicehantering för hamntjänster – i produktion på samma plattformsgrund.