Codebase overname
React-app laten overnemen zonder opnieuw te beginnen
Je vorige ontwikkelaar reageert niet meer. De documentatie ontbreekt. De app werkt gedeeltelijk, maar niemand weet welke onderdelen veilig aangepast kunnen worden. Ondertussen blijven fouten, gebruikersvragen en nieuwe features liggen.
Dimensa is een webstudio. Wij nemen React- en Next.js-code over en onderzoeken eerst wat bruikbaar is. Je krijgt dus niet automatisch het advies om alles opnieuw te bouwen. Eerst moet duidelijk zijn hoe de app lokaal draait, waar de data doorheen gaat, wat Vercel uitvoert en welke problemen echt opgelost moeten worden.
Kort antwoord: je hoeft niet opnieuw te beginnen
- Een bestaande React- of Next.js-app kan bijna altijd worden overgenomen, ook als de vorige ontwikkelaar niet meer reageert.
- Eerst onderzoek, dan een keuze: draait de app lokaal, wat doet de build, waar gaat de data heen, en welke toegang ontbreekt.
- Herbouwen is de uitzondering, niet de standaard. Alleen een onderdeel dat te veel risico geeft, wordt vervangen.
- Wat je klaarlegt: de repository, de live URL, toegang tot Vercel of je hosting, en de laatste foutmelding. Geen wachtwoorden per e-mail.
Wat overgenomen kan worden
Wij onderzoeken bestaande React- en Next.js-code en ontwikkelen die verder. Dat kan gaan om pagina's en componenten, API-routes, formulieren, authenticatie, databases en koppelingen met externe diensten. Ook Vercel-deployments, environment variables, buildproblemen en AI-functionaliteit kunnen onderdeel van de overname zijn.
De app hoeft niet door ons gebouwd te zijn. Wij kijken naar de repository, de huidige werking en de technische afhankelijkheden. Werkende onderdelen blijven staan waar dat verstandig is. Een volledige herbouw is geen automatische aanname en ook geen verborgen onderdeel van de intake. Eerst bepalen wij welke code bruikbaar is, welke delen risico geven en welke wijziging het gewenste resultaat oplevert.
Eerst grip op de codebase
Wij beginnen met een technische intake. Daarvoor hebben wij de repository nodig, plus de informatie die beschikbaar is over de lokale setup, Vercel en gekoppelde diensten. Wij starten de app waar mogelijk lokaal en controleren de React- of Next.js-versie, package manager, lockfile en dependency-versies.
Daarna bekijken wij het buildproces en de deploymentlogs. Wij controleren hoe environment variables worden gebruikt, welke API-routes en datastromen belangrijk zijn, en waar formulieren, authenticatie en databasebewerkingen hun gegevens verwerken. Ook leggen wij openstaande fouten, ontbrekende toegang, verouderde pakketten en verschillen tussen lokaal, preview en productie vast.
Je krijgt vervolgens geen algemeen oordeel, maar een overzicht van bevindingen, risico's en mogelijke vervolgstappen. Daaruit volgt een concreet voorstel: gericht repareren, onderdelen verder ontwikkelen, de overname gefaseerd uitvoeren of een beperkte herbouw plannen. Die keuze maken wij pas nadat de codebase is onderzocht.
Waar wij verborgen problemen op controleren
Een 3D-hero leek niets te renderen. In plaats van direct de camera, point size of shader te veranderen, hebben wij de live WebGL-context geïnstrumenteerd. Door drawArrays en readPixels te patchen, konden wij echte draw calls en pixeloutput loggen. Daaruit bleek dat er iedere frame 30.912 punten werden gerenderd. De oorzaak zat niet in het renderen, maar in de zichtbaarheid: de "low"-kleur uit de fragment shader, #33445a, lag visueel te dicht bij de achtergrondkleur #0b1017. De scene werkte, maar was bijna niet te zien.
Bij een andere site zakte de framerate naar 29fps, terwijl 60fps verwacht werd. De 3D-scene leek de logische verdachte, maar wij hebben de lagen één voor één uitgezet om de oorzaak te isoleren. De boosdoener was backdrop-blur-md op een vaste header. Die blur berekende de achtergrond met het animerende canvas erachter opnieuw op iedere frame. Eén CSS-class verwijderen verdubbelde de framerate.
Ook een stil formulierprobleem kwam pas naar voren door de hele datastroom te volgen. De bezoeker kreeg "success", maar de API-route logde de aanvraag alleen naar de console en sloeg niets op. Daardoor gingen alle aanvragen stil verloren. Wij hebben de succesmelding afhankelijk gemaakt van een daadwerkelijke persistente opslag.
Overnemen versus opnieuw bouwen
Een bestaande app hoeft niet opnieuw te beginnen omdat de vorige ontwikkelaar is gestopt. Werkende pagina's, componenten, API-routes en koppelingen kunnen blijven staan als ze begrijpelijk en onderhoudbaar genoeg zijn. Wij veranderen niet zomaar delen die geen verband houden met het probleem of de gewenste feature.
Soms blijkt uit het onderzoek dat een onderdeel zo sterk verweven, verouderd of onbetrouwbaar is dat een beperkte herbouw verstandiger is. Dat betekent niet automatisch dat de hele app opnieuw moet. Wij benoemen welk onderdeel vervangen moet worden, waarom dat risico wegneemt en wat kan blijven staan. De beslissing volgt uit de repository, logs en datastromen, niet uit een vooraf gekozen aanpak.
Kosten en wat niet inbegrepen is
Voor web-app- of AI-werk begin je met een betaald consult. Daarna volgt een voorstel met een vaste prijs. Het consult is bedoeld om de vraag en de technische richting scherp te krijgen; implementatie zit er niet automatisch in.
Bij een acute deployment- of productie-storing begint het met een diagnose tegen een vaste prijs, met maximaal één uur onderzoek. Daarna krijg je een vaste prijs voor de reparatie. Je ontvangt binnen 12 uur een schriftelijk antwoord, ook 's avonds en in het weekend. Dit is geen 24/7-storingsdienst.
Nieuwe features, een volledige rewrite, grote migraties en werk buiten de afgesproken scope zijn niet automatisch inbegrepen. Hosting, domeinen, databases, AI-gebruik en andere externe kosten betaal je afzonderlijk, tenzij dit vooraf anders is afgesproken.
Zo houd je controle na de overname
Wij houden wijzigingen bij in de repository en leggen belangrijke technische keuzes kort vast. Dat maakt zichtbaar wat is aangepast, waarom een oplossing is gekozen en welke punten later nog aandacht nodig hebben.
Ontbrekende toegang tot Vercel, databases, externe API's of domeinbeheer benoemen wij expliciet. Je weet daardoor welke toegang nodig is, wat nog niet gecontroleerd kon worden en welke onderdelen van de app nog afhankelijk zijn van anderen. Zo blijft de codebase overdraagbaar, ook na deze overname.
Aan de slag
Stuur de repository of beschikbare code, de live URL, informatie over het Vercel-project, de foutmelding, de laatst werkende versie en het gewenste eindresultaat. Vermeld ook welke toegang nog ontbreekt.
Wij bekijken eerst of de app lokaal en technisch te onderzoeken is. Daarna laten wij weten welke informatie nog nodig is, of een diagnose volstaat en welk voorstel past bij de overname. Deel nooit wachtwoorden per e-mail; gebruik een veilige manier om toegang te verlenen.
Veelgestelde vragen
Veelgestelde vragen
Kunnen jullie een React-app overnemen die jullie niet zelf hebben gebouwd?
Ja. Wij onderzoeken eerst de bestaande repository, dependencies, build en datastromen. De code hoeft niet door ons geschreven te zijn om ermee verder te kunnen werken.
Kunnen jullie een Next.js-app overnemen als de vorige ontwikkelaar niet meer reageert?
Ja. Wij werken met wat er beschikbaar is: de repository, deploymentinformatie, logs, accounts en de laatst werkende versie. Ontbrekende toegang of documentatie zetten wij apart op een lijst, zodat duidelijk blijft wat wel en niet gecontroleerd is.
Moet onze bestaande React-app helemaal opnieuw worden gebouwd?
Nee. Een volledige herbouw is niet de standaard. Wij laten werkende onderdelen staan waar dat verantwoord is en adviseren alleen een beperkte of volledige herbouw wanneer het onderzoek laat zien dat doorbouwen te veel risico of onderhoudsschuld geeft.
Wat hebben jullie nodig om onze bestaande codebase te onderzoeken?
Idealiter ontvangen wij de repository, de live URL, informatie over de lokale setup, Vercel-projectinformatie, deploymentlogs en de relevante foutmeldingen. Ook de laatst werkende versie, gebruikte externe diensten en beschikbare environment-variable-informatie helpen. Stuur geen geheime waarden of wachtwoorden per e-mail.
Kunnen jullie ook Vercel, de database en API-koppelingen overnemen?
Ja, wij nemen de deploymentconfiguratie, API-routes, databaseflows en externe koppelingen mee in de technische overname. Daarvoor zijn de juiste toegangen en documentatie nodig. Hosting- en externe servicekosten blijven afzonderlijke kosten.
Wat kost het om een bestaande React-app te laten overnemen?
Dat hangt af van de app. Voor web-app- of AI-werk begint het met een betaald consult, gevolgd door een offerte met een vaste prijs. Bij een acute storing begint het met een diagnose van maximaal één uur, tegen een vaste prijs. Nieuwe features, een volledige rewrite en externe kosten staan apart in de offerte.