Vi validerade behovet innan vi byggde
Fluit började hösten 2022 med research hos svensk industri. Fyra år senare är det ett helt affärssystem, och varje del av det går tillbaka på något någon faktiskt bad om.
- Behovsanalyser sedan 2022
- IFS, Jeeves, Navision, Pyramid
- Byggt på validerade behov
Vi frågade inköparna först
Hösten 2022 satte vi oss ner med inköpare, inköpschefer och IT-ansvariga på ett tjugotal svenska industri- och handelsbolag. En av Nordens största grossister inom VVS och el. Ett börsnoterat medicinteknikbolag. En nordisk hydraulikkoncern. Tillverkande bolag, grossister och familjeägda verkstäder. De körde IFS, Jeeves, Navision och Pyramid, i olika storlekar och olika branscher.
De beskrev samma vardag. Orderbekräftelsen kommer som en PDF i mailen. Någon öppnar den, jämför mot beställningen och ser att leveransdatumet flyttats två veckor. Eller ser det inte. Ingen loggar att man hört av sig till leverantören. När fakturan kommer stämmer den inte mot inleveransen, och någon får sitta och reda ut varför.
En inköpschef på ett av de större bolagen satte fingret på vad som faktiskt är kritiskt. Inte ledtiden i sig, utan förändringar i ledtiden inom pågående ledtid. Prognos, kampanjer, inneliggande kundorder och minsta orderkvantitet går att planera för. Det som gör ont är när förutsättningarna ändras efter att ordern är lagd. Det är också precis det som inget system fångar.
Så vi kartlade affärssystemens egna inköps- och lagermoduler. Mellan "optimal inköpsmängd" och "manuell inleverans" fanns det ingenting. Ett tomrum, i system efter system.
Planen var att bygga ovanpå andras system
Vi tänkte oss ett supply chain-stöd som lade sig ovanpå det affärssystem bolaget redan hade. Modellen var enkel: varje beställning är ett ärende. Orderbekräftelser, leveransuppdateringar, följesedlar och övrig kommunikation kopplas till sitt ärende, tolkas och stäms av mot regler. Stämmer allt uppdateras systemet av sig självt. Avviker något hamnar det hos rätt person med det felaktiga fältet markerat.
Vi satte det i produktion och byggde djup integration mot Jeeves, med synkronisering i båda riktningar. Där lärde vi oss vad som händer när ett system ska hantera flera lagerställen, lagerflyttar, XML-inläsningar och Norgetrafik samtidigt, och vad som går sönder när det gör det.
Sedan kom caset som avgjorde riktningen
En kund hörde av sig och ville ha ett lagersystem som också klarade order och inköp. När vi gick igenom kravlistan kände vi igen den. Det var precis de behov vi validerat i intervjuerna, och precis de behov som saknas i många affärssystem.
Det är i glappet mellan lagret och bokföringen de sitter. Ordern är fakturerad, artikeln ser beställd ut, men den kommer aldrig in. Fraktfakturan matchar ingenting. Saldot i systemet stämmer inte med hyllan. På ett stort bolag finns det folk anställda för att hantera det. På ett bolag med femton anställda finns det ingen.
Vi kunde ha byggt ännu ett lager ovanpå ett affärssystem som inte gjorde det kunden behövde. I stället bestämde vi oss för att testa något annat: bygga hela affärssystemet, och bygga det som man faktiskt vill ha det.
Rätt från början, inte lappat i efterhand
Att börja från ett tomt blad är bara värt något om man använder friheten. Flödena vi sett fungera i projekt efter projekt ligger med som standard i stället för att konfigureras fram på löpande räkning. Ytan ska gå att förstå på en förmiddag, och det svåra ska ligga under huven i stället för i en manual.
Vi byggde det också brett med flit. Order, lager, inköp, produktion och e-handel i samma system, med ekonomin kvar i Fortnox. Det är först när hela kedjan ligger på samma data som ett steg kan gå av sig självt: en orderbekräftelse som stäms av, ett inköpsförslag som räknas fram, ett fakturaunderlag som redan stämmer.
Och vi byggde det mitt i AI-skiftet, vilket märks i produkten. AI är inte en flik vid sidan om utan invävt i flödena du redan jobbar i, där det kan svara, fylla i och föreslå. Ett system som byggs idag ska anta att det är så man kommer att arbeta.
Vad vi byggt sedan dess
Grunden låg i order, lager och inköp. Under 2026 har resten av affärssystemet vuxit fram runt den, i månadstakt. Inköpen fick en egen arbetsyta med förslag och uppföljning. Lagret fick samleverans, plockrundor och leveranslöfte som räknar ut vad som faktiskt går att lova en kund. Produktionen fick kvalitetskontroll med kontrollplaner och avvikelser, och förebyggande underhåll på maskinerna.
Runt kärnan kom CRM med pipeline och förlustorsaker, ärendehantering med köer och SLA, en webshop som lägger riktiga försäljningsordrar i Fluit, en mobilapp för lagret och fälteknikern, och ett publikt API som numera täcker även inköp. Fortnox-integrationen synkar artiklar, kunder, ordrar och verifikat, och AI-kopplingen via MCP loggar in som en vanlig användare i stället för med en API-nyckel.
Vi skriver ut varje månad vad som är nytt, med namn på funktionerna och vad de faktiskt gör. Den som vill veta i vilken takt systemet växer behöver inte fråga oss.
Var vi står nu
Fluit ERP är ett affärssystem med lagerhantering och Fortnox-integration, byggt för mindre svenska handels- och tillverkningsbolag. Ekonomin ligger kvar i Fortnox. Order, lager, inköp, produktion och e-handel ligger hos oss.
Vi gissar oss inte fram till vad de behöver. Bakom systemet ligger fyra år av behovsanalyser hos svensk industri, ett system i skarp drift och integrationer mot affärssystem som är betydligt tyngre än de vi möter idag.
Ordningen är hela poängen. Vi validerade behovet först och valde tekniken sedan, i stället för tvärtom.
Känner du igen din egen vardag?
Boka en demo så går vi igenom hur flödet ser ut hos er idag: inköp, inleverans, lager och fakturaunderlag.