Hoe kiest u een nearshore softwarepartner
Kies een nearshore partner op twee dingen: wie de code daadwerkelijk schrijft, en hoe snel u de persoon bereikt die verantwoordelijk is voor de levering. Een kleine, door de oprichter geleide partner geeft u mensen die bij de rol passen en directe toegang tot die persoon. Een groot bureau geeft u diepte in de personeelspool en dekking rond de klok, met meer lagen tussen u en de ontwikkelaars.
Geschreven voor het moment in de zoektocht waarop elke leverancierssite hetzelfde zegt en u ze uit elkaar moet zien te houden.
Wat u controleert voor u tekent
Vijf punten die u in de eerste twee gesprekken helder krijgt. Elk heeft een antwoord dat goed klinkt en een antwoord dat de vraag echt beantwoordt.
- 1
Wie de code schrijft
Vraag naar namen en senioriteit van de mensen die op uw project komen, niet naar een bedrijfsgemiddelde. Wie antwoordt met een personeelsaantal beschrijft een bank, niet uw team.
- 2
Stappen tot een beslisser
Tel de mensen tussen u en iemand die de scope kan wijzigen, een ontwikkelaar kan vervangen of een factuurgeschil kan oplossen. Eén stap is een ander traject dan vier, en dat merkt u bij het eerste probleem, niet bij de eerste demo.
- 3
Wie in dienst neemt, wie aanstuurt, wie het risico draagt
Deze drie kunnen bij drie verschillende partijen liggen. De verdeling bepaalt hoeveel dagelijkse controle u werkelijk heeft en wie aansprakelijk is als het misgaat.
- 4
Bewijs dat u kunt controleren
Klanten met naam, projecten met naam, en een referentiegesprek dat u kunt inplannen. Een muur met logo's zonder namen is geen bewijs, en een geanonimiseerde case evenmin.
- 5
Exitvoorwaarden
Opzegtermijn, overdracht van rechten, en wat er met de code en de mensen gebeurt als u stopt. Vraag het voor u tekent — dezelfde vraag is achteraf veel lastiger beantwoord te krijgen.
Boutique of groot bureau
Geen van beide is in het algemeen beter. Ze falen op verschillende punten, en het juiste antwoord hangt af van de vorm van uw programma, niet van de omvang van de leverancier.
| Dimensie | Kleine, door de oprichter geleide partner | Groot bureau |
|---|---|---|
| Bemensing | Per klant samengesteld — mensen passend bij de rol | Uit een bestaande bank, gemengde senioriteit |
| Toegang | Direct naar de oprichter of delivery lead | Accountmanager, dan delivery manager, dan de ontwikkelaars |
| Opstarttijd | Weken — begrensd door werving, niet door beschikbaarheid | Dagen, als de bank uw stack al heeft |
| Dekking | Eén tijdzone, kantooruren | Overdracht rond de klok tussen vestigingen |
| Schaalplafond | Een handvol teams | Tientallen teams, meerdere landen tegelijk |
Wanneer het grote bureau de juiste keuze is
Dit zijn geen randgevallen. Staat uw situatie op deze lijst, dan is een kleine partner het verkeerde gereedschap — en wie u iets anders vertelt, verkoopt.
- •U hebt volgend kwartaal dertig engineers nodig. Een bank kan dat; werving niet.
- •U hebt 24/7-dekking nodig of een echte overdracht tussen tijdzones.
- •Het programma loopt over meerdere landen en vraagt in elk land een lokale entiteit.
- •Inkoop eist formele certificeringen, verzekeringsdekking en een contractuele vervangingsgarantie die een klein bedrijf niet kan dragen.
Vijf vragen aan elke nearshore leverancier
De antwoorden doen er minder toe dan hoe snel ze komen. Aarzeling bij een van deze vragen is zelf al de bevinding.
Wie schrijft precies de code, en kan ik hen interviewen?
Namen, cv's, en ja. Een weigering betekent meestal dat het team nog niet staat of gedeeld wordt met andere klanten.
Wie neemt de ontwikkelaars in dienst, en onder welk contract?
Eén helder antwoord. Liggen dienstverband, aansturing en facturatie bij drie partijen, vraag dan wie van hen aansprakelijk is als een deadline of een privacyverplichting wordt gemist.
Wat gebeurt er als een ontwikkelaar halverwege vertrekt?
Een benoemde opzegtermijn en een vervangingsproces met overlap voor overdracht. "We vinden wel iemand" is geen proces.
Wie is eigenaar van de code, en wanneer gaan de rechten over?
De rechten gaan schriftelijk op u over bij betaling, per oplevering — niet bij eindacceptatie maanden later.
Kan ik een klant spreken voor wie u geleverd hebt, zonder u erbij?
Ja, met naam en introductie. Terughoudendheid hier weegt zwaarder dan welke case op de website ook.
Hoe Jezda is opgebouwd
Jezda Solutions is een door de oprichter geleid softwarebedrijf in Smederevo, Servië, opgericht in 2018 door CEO Zoran Jezdimirović. Getoetst aan de checklist hierboven betekent dat in de praktijk het volgende — inclusief waar die checklist tegen ons uitvalt.
- ✓De persoon die verantwoordelijk is voor de levering is de persoon met wie u praat. Er zit geen accountlaag tussen u en het werk.
- ✓Teams worden per klant samengesteld in plaats van op een bank gehouden, dus mensen passen bij de rol — maar de opstarttijd meet u in weken, niet in dagen.
- ✓Ontwikkelaars zijn lokaal in Servië in dienst en worden dagelijks door u aangestuurd. Dienstverband, salarisadministratie en compliance blijven bij ons.
- ✓Servië draait op Midden-Europese tijd, dus de werkdag overlapt volledig met Duitsland, Nederland en Polen — maar het is één tijdzone, geen ploegendienst rond de klok.
Veelgestelde vragen
Wat opdrachtgevers vragen voor ze een nearshore partner kiezen
Wilt u deze vragen aan ons stellen?
Stel ze direct. U krijgt de antwoorden van de persoon die verantwoordelijk is voor de levering, niet van een accountmanager.
Begin het gesprek