Written by:
Last Published:
22 juli 2026
•
MERN står för MongoDB, Express, React och Node.js. De flesta kunder som kommer till oss och efterfrågar MERN-stacken vill ha tre av dessa fyra.
De vill ha React. De vill ha Node. De vill ha ett team, ett språk, en utvecklare som kan följa en funktion från skärmen till databasen och tillbaka igen utan att behöva lämna över den till någon annan. Det de oftast inte har granskat är M:et. MongoDB är ett databasbeslut, och databasen är det beslut som du inte kan ändra till en låg kostnad arton månader senare.
Så låt oss gå igenom det ordentligt. Vad MERN-stacken är, hur de fyra delarna faktiskt hänger ihop, när den är värd sin investering och när vi skulle råda dig att välja något annat.
Om du skriver kod går avsnitten om arkitektur och jämförelser på djupet. Om det är du som godkänner budgeten, hoppa direkt till Stack-Fit Check och när MERN inte är rätt val. Det är där beslutet fattas.
MERN-stacken består av fyra JavaScript-tekniker grupperade under ett namn: MongoDB, Express, React och Node.js. Det är inget du installerar. Det är en konvention, en förkortning för en uppsättning verktyg som redan fungerar bra ihop.
Varför kombinera dessa fyra? För att de tillsammans låter ett team bygga en fullständig webbapplikation utan att behöva byta språk en enda gång. Den egenskapen – att använda ett och samma språk – är hela poängen med MERN. Det handlar inte om någon enskild komponent, utan om att alla fyra talar samma språk och hanterar data i samma format.
Allt som är bra med MERN-stacken följer av detta. Det gör även allt som är krångligt.
En MERN-applikation är full-stack: React i webbläsaren, Express och Node.js på servern, och MongoDB i botten. Det smarta är att samma JSON-struktur löper genom alla tre lager, så ingenting behöver omformas på vägen.
Se det som vatten som du tappar på flaska en gång och aldrig häller om. React fyller flaskan i webbläsaren och skickar den via HTTP till en Express-rutt. Express lämnar över den till MongoDB via drivrutinen, med etiketten intakt, och samma flaska färdas tillbaka när du läser den. En utvecklare som kan JavaScript och JSON kan följa den flaskan från skärm till disk.
Låt oss gå igenom varje lager i tur och ordning.
MongoDB sparar data som dokument istället för rader och kolumner. Det innebär att formen på din React-state och formen på din lagrade data är identiska, utan något översättningslager mellan två olika mentala modeller.
Under huven använder den BSON, en binär form av JSON som lagras mer kompakt och läses snabbare än vanlig text. Dess frågespråk, MQL (MongoDB Query Language, syntaxen du använder för att hitta och uppdatera dokument), är skrivet i JSON och JavaScript. (MongoDBs egen dokumentation om frågeoptimering är den primära källan som är värd att läsa här, snarare än någon av sammanfattningarna.)
Så varför väljer man MongoDB? Flexibel, nästlad data utan ett fast schema, vilket passar produkter vars datamodell fortfarande är under utveckling. Horisontell skalning, vilket innebär att du lägger till fler maskiner istället för att köpa en större. Öppen källkod, och fungerar utmärkt på AWS, Azure och Google Cloud.
Och vad får du ge upp? Joins, transaktionsgarantier för flera dokument och den referentiella integritet som en relationsdatabas ger dig gratis. Mer om det längre ner, för enligt vår erfarenhet är det just denna avvägning som avgör de flesta projekt.
Express är lagret som din frontend faktiskt kommunicerar med. Det hanterar URL-routing och omvandlar inkommande HTTP-förfrågningar till svar, vilket är anledningen till att det är standardvalet för att bygga ett REST-API i en JavaScript-stack.
Vi valde Express för Game Achievements, en spelportal som spårar troféer och milstolpar över PlayStation Network, Xbox och Steam. Resonemanget var oglamoröst och värt att säga rakt ut. API-ytan bestod mestadels av enkel CRUD – det vill säga skapa, läsa, uppdatera och ta bort – över en stor och välkänd datamängd. Teamet ville ha minimalt med ramverkskrångel, och paketekosystemet innebar att ingenting behövde byggas två gånger.
Node.js är det som överhuvudtaget gör Express möjligt. Det är en asynkron, händelsestyrd runtime byggd på icke-blockerande I/O, en modell där programmet fortsätter att ta emot nya förfrågningar istället för att stå stilla medan det väntar på långsamma processer som en databasläsning. En Node-process betjänar en mängd anslutningar samtidigt. När ingen anropar den kostar den nästan ingenting att hålla igång.
Här är strukturen för en Express-rutt så som vi faktiskt skriver den. Validering vid gränsen, tunn kontroller, fel som skickas till en gemensam hanterare istället för att fångas upp var de än dyker upp:
// routes/achievements.js, the pattern we use across Node services at IC
import { Router } from 'express';
import { z } from 'zod';
import { listAchievements } from '../services/achievements.js';
const router = Router();
const listQuery = z.object({
platform: z.enum(['psn', 'xbox', 'steam']),
cursor: z.string().optional(),
limit: z.coerce.number().int().min(1).max(100).default(50),
});
router.get('/achievements', async (req, res, next) => {
try {
const query = listQuery.parse(req.query);
const page = await listAchievements(query);
res.json(page);
} catch (error) {
next(error); // single error middleware, never a bare try/catch response
}
});
export default router;Tre saker vi insisterar på, och anledningen till var och en. Validering sker vid gränsen, så att inget ovaliderat någonsin når en tjänstefunktion. Rutten vet ingenting om databasen, så du skulle kunna byta ut Mongo mot Postgres utan att den här filen behöver ändras. Och fel hamnar på ett ställe, eftersom utspridd felhantering är anledningen till att ett Node-API till slut returnerar sex olika typer av felmeddelanden till samma frontend.
React förvandlar din backend-data till ett gränssnitt. Du skriver det i JSX, ett syntaxtillägg som låter dig placera HTML-liknande kod direkt i JavaScript, vilket gör att en komponents utseende och logik hamnar sida vid sida.
Tänk dig att du driver en biograf med en databas över speltider. Du bygger en informationsruta som tar emot en titel, en tid och ett datum, och React renderar om den för vilken film som helst, vilken dag som helst. Skriv den en gång. Mata in vad som helst.
Reacts virtuella DOM uppdaterar bara de delar av sidan som faktiskt ändras, vilket gör att komplexa gränssnitt förblir snabba. Dess komponentmodell gör UI-kod återanvändbar i hela applikationen, och den har stöd för server-side rendering, vilket genererar den första HTML-koden på servern så att sidan laddas snabbare och blir mer lättläst för sökmotorer.
Vi har sett vad det innebär i praktiken. På AppTweak, en datatung instrumentpanel för app-store-analys som byggdes om i React med TypeScript, Redux och Redux-Saga, förbättrades laddningstiden med 80 %. På FundSpace, gjorde ett omdesignat React-gränssnitt kundens centrala beslutsprocess tio gånger snabbare.
En ärlig nackdel. React är ett bibliotek, inte ett ramverk, så routing och tillståndshantering är upp till dig att välja och koppla ihop. Frihet om ditt team är erfaret. Hemläxa om det inte är det. Det är också anledningen till att debatten om MERN kontra MEAN egentligen är en debatt om React kontra Angular, vilket vi kommer att gå in på.
Både och, och det är hela poängen. MERN-stacken täcker designen, känslan och interaktionen i front-end såväl som datan och logiken i back-end.
För ditt företag är konsekvensen tydlig. En MERN-utvecklare kan ansvara för en funktion från början till slut, vilket är precis där fördelarna med rekrytering och kostnader som nämns senare i artikeln kommer ifrån.
Läs även: att välja den bästa teknikstacken för webbutveckling och så hanterar du teknisk skuld.
Ja, och tre av dess fyra bokstäver finns med bland de fem främsta ramverken för webbutveckling. Den fjärde presterar betydligt sämre i sin kategori, vilket är den här artikelns tes baserad på andras data.
Den senaste publicerade Stack Overflow Developer Survey genomfördes i juli 2025 med cirka 49 000 respondenter. Bland samtliga respondenter leder Node.js alla webbramverk med 48,7 % och React ligger tvåa med 44,7 %, medan Express ligger femma med 19,9 %. Om man begränsar urvalet till professionella utvecklare kvarstår bilden: Node.js 49,1 %, React 46,9 %, Express 20,3 %. React är även det mest eftertraktade ramverket i undersökningen med 30,7 %, tätt följt av Node.js på 29,7 %.
.webp)
Låt oss nu titta på databaserna från samma undersökning. PostgreSQL leder med 55,6 %, följt av MySQL på 40,5 %, SQLite på 37,5 %, Microsoft SQL Server på 30,1 % och Redis på 28 %. MongoDB hamnar på sjätte plats med 24 %, efter fyra relationsdatabaser och en cache. Bland professionella utvecklare ökar klyftan något: PostgreSQL 58,2 % mot MongoDB 24,3 %.
Stack Overflows egen tolkning av trafiken mellan dessa två listor är värd att reflektera över. Utvecklare som redan arbetar med MongoDB visar en tydlig dragning mot PostgreSQL, där de ser relationsdatabaskompetens som något att lägga till snarare än något de har lämnat bakom sig.
Detta gör inte MongoDB till en dålig databas. Det innebär dock att efterfrågan du rekryterar utifrån är koncentrerad till Express, React och Node.js. Om du utgår från att MongoDB ingår i paketet antar du något som marknadsdatan inte ger stöd för.
MEAN och MERN är samma stack med en utbytt del. Ta bort React, sätt in Angular, så blir MongoDB-Express-Angular-Node till MEAN. Båda är open source och båda är JavaScript-baserade, så jämförelsen handlar egentligen om React mot Angular.
| MERN | MEAN | |
|---|---|---|
| Språk | JavaScript eller JSX | TypeScript, i grunden |
| Frontend | React, ett bibliotek | Angular, ett fullständigt ramverk |
| Ingår från start | Routing och tillståndshantering väljer du själv | Routing, formulär, HTTP, DI ingår |
| Inlärningskurva | Enklare, ren JavaScript | Brantare, TypeScript plus ramverkskonventioner |
| Uppgraderingar | Krångligare, du ansvarar för beroendegrafen | Angular CLI uppgraderar smidigt, även om stora ändringar fortfarande kräver manuella steg |
| Dataflöde | Envägsbindning | Envägs- och tvåvägsbindning |
| Testning | Oftast flera verktyg: Jest, React Testing Library | Oftast ett: Karma eller Jasmine |
Den ärliga sammanfattningen: MERN går snabbare att komma igång med men är svårare att styra. MEAN tar längre tid att starta men är lättare att hålla konsekvent i ett stort team över flera år. Angulars användning ligger på 18,2 % i 2025 års undersökning mot Reacts 44,7 %, även om rå popularitet är fel måttstock här. Frågan är vilken uppsättning begränsningar som passar det team du har om tre år, inte det du har detta kvartal.
Vi har sett hur den senare delen av det gett resultat. TrustPortal, en plattform för företagsautomatisering byggd på Angular, NGRX, Redux Toolkit och Node.js med TypeScript, sänkte driftskostnaderna med 40 till 50 % för sina kunder. Den heltäckande typningen var ingen slump. När en plattforms hela värde ligger i pålitlig processautomatisering är garantier vid kompilering över gränssnitten värda den extra ansträngningen. På Learninghubz, en lärandeplattform baserad på Angular, TypeScript, Node.js och .Net, ökade strukturellt arbete antalet aktiva användare med 20 %.
Fem personer som ska leverera en MVP? Välj MERN. Trettio personer som ska underhålla en plattform i ett decennium? Överväg MEAN noga innan ni bestämmer er.
Innan vi placerar någon i en MERN-stack kör vi idén genom ett kort internt test. Fyra frågor, ungefär tio minuter, och du vet om MERN är en stabil grund eller en långsam läcka som du kommer att behöva laga i åratal.
1. Vilken form har din data? Dokumentliknande och föränderlig, som profiler, innehåll, händelser eller aktivitetsflöden? Då passar MongoDB. Djupt relationell och transaktionell, som huvudböcker, lagerhantering eller något som kräver integritet över flera tabeller? Då arbetar MERNs databas i tysthet mot dig.
2. Vilket språk behärskar ditt team? JavaScript-fokuserade utvecklare? MERN tar bort friktionen. Ett team som vill ha typsäkerhet genomdriven i varje lager som ett absolut krav? Då är MEANs TypeScript-först-inställning ett bättre kulturellt val.
3. Hur ser din profil ut för latens och samtidighet? Node trivs med många små, samtidiga I/O-förfrågningar. Är arbetsbelastningen istället CPU-intensiv, med bildbehandling, video eller storskalig databearbetning? Då blir Nodes enkeltrådade händelselopp din flaskhals.
4. Hur bråttom är det? Behöver du få ut en MVP till användare snabbt, där ett team äger hela lösningen? MERNs leverans med ett enda språk är svårslagen.
Tre eller fyra ja-svar innebär att MERN nästan alltid är rätt val. Två eller färre, och nästa avsnitt visar vad du bör välja istället.
Ett praktiskt exempel. VestaConnect, en hälsoteknisk produkt som gick från MVP till betalande användare, svarade ja på snabbhet och ja på ett litet, ansvarigt team. Men dess data var relationell och delar av arbetsbelastningen var beräkningsintensiv. Två av fyra. Vi byggde den på Python, FastAPI och PostgreSQL istället, och den lanserades. Fråga fyra i sig är aldrig tillräcklig för att välja en stack, vilket är precis varför testet består av fyra frågor.
Samma test, motsatt svar. Aurora Analytica behövde snabbt få ut en beslutsmaskin för kliniska prövningar till användare, med ett JavaScript-kunnigt team och I/O-baserade arbetsflöden. Den lösningen byggdes på Next.js, Redux, Auth0 och AWS. React på en Node-runtime, MERN i anden om än inte i databasvalet.
Detta är samma test som vi kör på kundprojekt innan en enda rad kod skrivs. Om du vill att vi kör det på ditt projekt, prata med teamet.
Är MERN-stacken alltid svaret? Nej, naturligtvis inte. Det är ett starkt standardval för team som prioriterar JavaScript, men i vissa tydliga fall är det fel verktyg.
MongoDBs dokumentmodell är utmärkt för flexibla, nästlade data. Den är inte byggd för kopplingar (joins), transaktioner över flera tabeller eller strikt referentiell integritet. Om din produkt är en bankbok, ett affärssystem eller en rapport som sammanfogar ett dussin tabeller, ger PostgreSQL eller MySQL dig en renare modellering och betydligt starkare transaktionsgarantier.
Det är här den första frågan gör det mesta av jobbet. Produkter beskrivs ofta för oss som flexibla och dokumentbaserade, men när man väl kartlägger de faktiska entiteterna framträder något annat. Användare har organisationer. Organisationer har abonnemang. Abonnemang har rättigheter. Plötsligt sitter du och skriver kopplingar för hand i applikationskoden klockan tre på morgonen.
Game Achievements är det tydligaste exemplet vi har. På pappret såg det ut som ett skolboksexempel på ett MERN-projekt: JavaScript-team, Express-API och snabb tid till marknaden. Vi byggde API:et med Express och TypeScript, och placerade sedan PostgreSQL och Prisma under huven istället för MongoDB, eftersom achievements, plattformar, spelare och titlar utgör en genuint relationell datamängd med en stor volym högst strukturerade poster och omfattande filtrering över relationer. Samma JavaScript-runtime, samma routing-lager, men en annan databas. Tjänsten lanserades med spårning av achievements över alla tre stora plattformar och började ranka på Google redan under sin första vecka.
Flipped Normals, en marknadsplats för datorgrafik, illustrerar samma poäng från motsatt håll. Vi migrerade den från WordPress och MySQL till PostgreSQL, och flyttade sedan dess infrastruktur från Heroku, vars skalningsbegränsningar hade blivit en flaskhals, till AWS. Första steget avklarat på två månader. Lärdomen att ta med sig är att databasbeslutet är det som är dyrast att ändra i efterhand. Frontend-ramverk kan bytas ut bit för bit. Datamodeller kan inte det.
Kommer du ihåg flaskan? En relationell databas kräver att du häller om innehållet. Det krävs en annan behållare i andra änden, någon måste hälla, och det hällandet sköts av en objekt-relationell mappning (ORM) – lagret som omvandlar databasrader till vanliga kodobjekt. Du kommer att underhålla detta under hela produktens livslängd. Många produkter bör gladeligen betala det priset, eftersom kopplingar och transaktionsintegritet är värda det. Var bara medveten om att du betalar det.
Du kan lägga till TypeScript i React och Node, vilket vi oftast gör, men MERN-stacken kräver det inte från början till slut. Team som vill ha typning som ett hårt krav genom hela kedjan – vanligtvis större organisationer eller långlivade kodbaser där kompileringstids-kontroller förhindrar defekter – är bättre betjänta av MEAN, där Angular är byggt med TypeScript från grunden.
Tung beräkning, oavsett om det handlar om storskalig databehandling eller mediatranskodning, överbelastar Nodes enkeltrådade händelseloop, och ett språk med verklig parallellism presterar helt enkelt bättre. I den andra extremen är en liten statisk webbplats eller innehållssida sällan i behov av en full stack överhuvudtaget. En generator för statiska webbplatser, en Next.js-app eller Webflow kan vara enklare och billigare att driva under flera år.
Var bor egentligen en MERN-app när den väl är byggd? De fyra delarna driftsätts i två grupper. Databasen ligger vanligtvis på MongoDB Atlas, MongoDB:s molntjänst, så att ingen i ditt team behöver köra säkerhetskopior mitt i natten. Express- och Node-backend körs på Railway, Render, Fly.io eller en vanlig moln-VM, och React-frontend serveras antingen från samma Node-server med SSR, eller som statiska filer från en host som Vercel eller Netlify.
Ett råd om hosting som vi vill ge oavsett stack: välj en plattform vars skalningstak ligger över din tvåårsprognos, inte din sexmånadersprognos. Flipped Normals migrering från Heroku skedde för att det taket nåddes tidigare än någon hade planerat, och att byta plattform för en live-marknadsplats kostar betydligt mer än att välja rätt från början. Vårt molnbaserade plattformsarbete finns till stor del för att det misstaget är så vanligt.
Det är också här som MERN-stacken möter sina yngre utmanare. En Next.js-stack slår ihop React och Node-backend till ett ramverk med inbyggd SSR, och bestämda paket som T3 parar ihop Next.js med end-to-end TypeScript.
För en CTO eller COO handlar valet av MERN-stacken egentligen inte om teknik. Det handlar om hur en stack baserad på ett enda språk påverkar kostnader, hastighet och risk.
Lägre rekryteringsrisk, snabbare onboarding. Hela applikationen är JavaScript, vilket innebär att du rekryterar från en och samma stora talangpool istället för att behöva separata specialister för front-end och back-end. En JavaScript-utvecklare kan arbeta med gränssnittet, API:et och databasen utan att behöva byta fokus, vilket förkortar introduktionstiden och minskar det personberoende som ofta följer med nischade tekniker.
Snabbare tid till marknad. Ett språk och ett dataformat innebär mindre ”limkod” och färre överlämningar. Lotto Billions, byggt på React, GraphQL, Node.js och Express, expanderade till den brasilianska marknaden på två månader. Alicontrol, baserat på Node och React, expanderade till mer än tio länder tack vare sin nya applikation. Ingen av dem är visserligen en renodlad MERN-implementering, då den ena kör MySQL och den andra kombinerar Node med inbyggd mobilteknik. Båda visar dock vad grunden i React och Node gör för leveranshastigheten.
Lägre kostnader. Färre specialistroller innebär ett mindre team för samma resultat. Det är därför MERN och dess nära släktingar ständigt dyker upp i MVP-projekt och hos nystartade företag med begränsad budget.
Låg underhållsrisk. MongoDB, Express, React och Node har alla stora, aktiva open source-communityn, vilket gör att dokumentation, bibliotek och rekryteringsstöd alltid finns nära till hands. Du riskerar inte att bygga din produkt på ett nischat verktyg som kan tappa fart om ett år.
En brasklapp som vi hellre vill lyfta fram än att dölja: Varje fördel ovan är en teamfördel. Ingen av dem kan laga en datamodell som inte är lämpad för en dokumentdatabas. Om den första frågan i vår Stack-Fit Check får fel svar, kommer ingen mängd rekryteringsflexibilitet i världen att rädda projektet. Det innebär bara att du har en större grupp människor tillgängliga för att underhålla en felaktig grund.
Ja. MERN-stacken är fortfarande ett populärt val för fullstack-utveckling med JavaScript, och dess komponenter – särskilt React och Node – toppar ständigt listorna i utvecklarundersökningar. Den är som starkast för startups, MVP:er och innehållsdrivna appar där snabb leverans är högsta prioritet.
Dynamiska webb- och mobilappar: sociala plattformar, instrumentpaneler, e-handel, innehållshanteringssystem och realtidsapplikationer. Den passar produkter som vill ha ett responsivt React-gränssnitt ovanpå en flexibel JSON-databas, där ett och samma team arbetar i ett enda språk.
Välj bort MERN om din data är starkt relationell och transaktionstung; använd SQL istället. Välj bort den om du behöver strikt TypeScript-stöd genom hela stacken; titta då på MEAN. Undvik den för CPU-intensiva arbetsbelastningar som belastar Nodes enkeltrådade modell. För en liten statisk webbplats är en full stack oftast överkurs. Gör vår Stack-Fit Check om du är osäker.
Ibland, om man är noggrann. Företag med komplexa relationella datakrav eller strikta krav på typsäkerhet och styrning föredrar oftast en relationell databas och ett ramverk med TypeScript i fokus. MERN passar bra för kundvända, innehållstunga eller realtidsprodukter där utvecklingshastighet och en enhetlig kompetensbas väger tyngre än krav på tunga transaktionsgarantier.
Utvecklartid är den största kostnaden, och MERN tenderar att sänka den eftersom ett gemensamt språk innebär ett mindre, mer flexibelt team och färre överlämningar. Hostingkostnaderna börjar lågt, då MongoDB Atlas, en Node-värd och en värd för statisk frontend alla har förmånliga eller kostnadsfria instegsnivåer, och de skalar sedan med användningen. Projektets omfattning och teamets erfarenhetsnivå påverkar slutsumman betydligt mer än själva stacken.
Det beror på din marknad och vilken erfarenhetsnivå du behöver, men eftersom MERN bygger på välkänd JavaScript-teknik är utbudet av talanger stort och tjänsterna tillsätts oftast snabbare än för nischade stackar. En utvecklingspartner vi kan korta ner processen ytterligare genom att förse dig med granskade utvecklare utan att du behöver gå igenom en fullständig rekryteringscykel internt.
Mindre produkter kan drivas av generalistiska fullstack-utvecklare inom JavaScript som var och en ansvarar för funktioner från början till slut. I takt med att produkten växer brukar team lägga till en front-end-ansvarig för React-arkitektur och en back-end-ansvarig för API- och databasdesign, samtidigt som man behåller det gemensamma språket så att utvecklare fortfarande kan arbeta över hela stacken.
Front-enden, och endast front-enden. MERN använder React med JavaScript eller JSX. MEAN använder Angular med TypeScript. Angular är ett komplett ramverk med en brantare inlärningskurva och enklare testning och uppgraderingar, medan React är ett mer flexibelt bibliotek som är enklare att lära sig men som förlitar sig på paket du väljer själv.
Next.js slår samman React och en Node-back-end till ett ramverk med inbyggd server-side rendering, och T3-stacken lägger till TypeScript genom hela kedjan. Båda offrar en del av Reacts "bygg-det-själv"-frihet för enklare driftsättning och starkare typning. Vi väljer numera Next.js oftare än klassisk MERN vid nya projekt.
MongoDB är M:et i MERN och den databas stacken är byggd kring, så en äkta MERN-stack använder den. Byter du ut den mot en relationsdatabas som PostgreSQL kör du inte längre MERN, utan en annan JavaScript-stack byggd på React, Express och Node. Vilket, som Game Achievements visar, ofta är det bättre alternativet.
Vi har levererat produkter med React och Node.js inom fintech, hälsoteknik, spel, utbildning och offentlig sektor, och vi arbetar med både dokument- och relationsdatabaser. Det vi däremot inte gör är att se de fyra bokstäverna som ett paket. Valen av frontend och runtime baseras på teamets förutsättningar och leveranskrav, medan databasen utvärderas för sig.
Om du överväger MERN-stacken för din nästa produkt, prata med oss innan du bestämmer dig. Vi kör din idé genom vår Stack-Fit Check, din datamodell, ditt team, din skala och din time-to-value, och ger dig ett ärligt svar på om MERN är rätt grund att stå på eller om något annat skulle tjäna dig bättre.
Tio minuter för en Stack-Fit Check. Det har besparat mer än en kund en migrering som de annars fortfarande hade betalat för två år senare.
Mångsidig och datadriven tillväxtmarknadsförare med fördjupad affärskunskap, uppdaterad med den senaste utvecklingen inom det digitala marknadsföringslandskapet.
Din dagliga webbutvecklare som gillar att gömma sig i backend. Javascript och Ruby är min sylt. Jag fumlar fortfarande med Docker och mina byggnader går sönder ganska ofta.
People who read this post, also found these interesting:
