Hoe huur je een freelance ontwikkelaar in

De meeste mislukte ontwikkelingsprojecten waren niet slecht gecodeerd. Ze waren slecht gespecificeerd, aangenomen op basis van het verkeerde signaal, en zo onvolledig overgedragen dat de volgende ontwikkelaar opnieuw moest beginnen. Het technische deel is zelden waar het geld verloren gaat.

Dat is goed nieuws voor een niet-technische koper, want het betekent dat de beslissingen die er het meest toe doen, beslissingen zijn die jij gekwalificeerd bent om te nemen. Je hoeft iemands JavaScript niet te beoordelen om goed in te huren. Je moet het probleem nauwkeurig kunnen beschrijven, relevant bewijs herkennen, vragen stellen die moeilijk te bluffen zijn, en aandringen op een overdracht die jou de sleutels in handen geeft. Deze gids behandelt alle vier.

Beslis wat je daadwerkelijk bouwt

Begin met het resultaat, niet met de technologie. "Ik heb een app nodig" is geen briefing; "klanten moeten een plek kunnen boeken en betalen op hun telefoon, en ik moet de boekingen van morgen in één lijst kunnen zien" is dat wel. De tweede versie kan worden geoffreerd, getest en besproken. De eerste niet.

Voordat je met iemand praat, schrijf je vier dingen op:

• De uit te voeren taakWat een gebruiker moet kunnen bereiken wat vandaag niet kan. Eén zin per functionaliteit, in de taal van de gebruiker in plaats van technische taal.
• De must-havesDe paar dingen zonder welke de bouw zinloos is. Als je lijst meer dan zes items heeft, is het een verlanglijstje, geen specificatie.
• Wat er al bestaatHuidige site, hosting, domein, betalingsprovider, CRM, spreadsheets. Elke integratie is werk, en niet-aangegeven integraties zijn waar schattingen misgaan.
• Wie het onderhoudtSoftware is geen aankoop, het is een verbintenis. Beslis nu of je de ontwikkelaar behoudt, iemand anders inhuurt, of het zelf beheert.

Een nuttige discipline: beschrijf de eerste versie als het kleinste ding dat echt nuttig zou zijn. Al het andere komt op een tweede lijst. Ontwikkelaars offreren de eerste lijst; de tweede lijst is wat je financiert zodra de eerste geld oplevert.

Welk type ontwikkelaar je nodig hebt

"Ontwikkelaar" omvat een dozijn verschillende beroepen die niet uitwisselbaar zijn. Het inhuren van de verkeerde is de meest voorkomende en duurste categoriefout in dit proces.

• Front-endWat de gebruiker ziet en aanraakt: lay-out, interactie, responsiviteit, toegankelijkheid. Huur in voor een redesign, een marketingsite of een nieuwe interface op een bestaand systeem. Zie freelance front-end ontwikkelaars.
• Back-endGegevens, logica, API's, authenticatie, betalingen. Huur in wanneer de waarde ligt in wat er gebeurt nadat de knop is ingedrukt. Zie freelance back-end ontwikkelaars.
• Full-stackBeide, tot een werkende standaard. De juiste keuze voor de meeste kleine builds, omdat coördinatie tussen twee specialisten meer kost dan het bespaart op kleine schaal.
• CMS en platformWordPress, Shopify, Webflow en dergelijke. Als aan je vereiste wordt voldaan door een bestaand platform, is het inhuren van een aangepaste ontwikkelaar om het opnieuw te bouwen weggegooid geld. Zie WordPress-ontwikkeling en Shopify-ontwikkeling.
• MobielNative iOS of Android, of cross-platform. Een wezenlijk andere discipline dan web, met zijn eigen app store-review en releasebeperkingen. Zie ontwikkeling van mobiele apps.
• Onderhoud en fixesFoutopsporing, updates, prestaties, beveiliging. Vaak de meest waardevolle aanwinst van allemaal, en degene die kopers het langst uitstellen. Zie website-onderhoud.

Als je echt niet kunt zeggen welke je nodig hebt, is dat op zich een kleine, goedkope, goed gedefinieerde taak: betaal een ervaren ontwikkelaar voor een kort verkennend gesprek voordat je iets in opdracht geeft.

De technologie kiezen vóór de persoon

Je hoeft de taal niet te kiezen. Je moet wel één beslissing nemen: platform of maatwerk. Dit heeft meer invloed op je totale kosten dan welke andere keuze in deze gids dan ook.

Een platformbouw – WordPress, Shopify, Webflow, een no-code tool – betekent dat de meeste software al bestaat en dat je betaalt voor configuratie, ontwerp en de onderdelen die specifiek voor jou zijn. Het is sneller, goedkoper en gemakkelijker over te dragen aan de volgende persoon, omdat duizenden ontwikkelaars het kennen. De beperking is dat je binnen de aannames van het platform leeft.

Een maatwerkbouw betekent dat de software voor jou wordt geschreven. Het past precies, en het kost meerdere malen zoveel om te maken en te onderhouden, omdat alleen de persoon die het heeft geschreven het kent totdat ze het documenteren. Maatwerk is het juiste antwoord wanneer hetgeen je doet het product is; het is het verkeerde antwoord voor een brochuresite of een standaardwinkel.

Twee praktische regels. Ten eerste, als een mainstream platform tachtig procent doet van wat je nodig hebt, begin daar dan en betaal voor de ontbrekende twintig. Ten tweede, wat er ook wordt gekozen, vraag waarom – een ontwikkelaar die de keuze niet kan uitleggen in termen van jouw vereisten, kiest wat hij leuk vindt, niet wat jij nodig hebt. Als je een volledige websitebouw overweegt, beschrijft onze websitekosten gids de prijsklassen.

Een korte briefing schrijven die een ontwikkelaar kan citeren

Een goede technische briefing is kort en specifiek. Het vertelt de ontwikkelaar niet hoe hij moet bouwen; het vertelt hem wat waar moet zijn als hij klaar is.

• Het probleem, in één alinea. Wat er nu gebeurt en waarom het onacceptabel is.
• De user stories. “Als klant kan ik … zodat …”. Vijf tot vijftien hiervan is een echte specificatie.
• De integraties. Noem elk extern systeem bij naam, inclusief de systemen die u als triviaal beschouwt.
• Wat u levert. Tekst, afbeeldingen, ontwerpen, logins, testgegevens. Onverklaarde hiaten worden factureerbare uren.
• Beperkingen. Deadline, budgetbereik, hosting waarop u moet blijven, compliance waaraan u moet voldoen.
• De definitie van voltooid. Waar geïmplementeerd, hoe getest, tot welk niveau gedocumenteerd, overgedragen met wat.

Voeg een budgetbereik toe. Kopers houden het achter in de hoop op een lagere offerte; in de praktijk levert het alleen voorstellen op die gericht zijn op de verkeerde schaal, en verliest u een correspondentieronde om dat te ontdekken. Onze gids voor het schrijven van een projectbriefing die geweldige voorstellen oplevert heeft een uitgebreidere sjabloon, en uurprijs versus vaste prijs legt uit welk prijsmodel uw briefing vraagt.

Een shortlist maken

Streef naar drie tot vijf kandidaten. Minder en u heeft geen vergelijking; meer en u zult de beoordeling bij geen van hen goed uitvoeren.

Er zijn twee richtingen om vanuit te zoeken. Begin bij het werk als je taak goed gedefinieerd is en je iets specifieks wilt kopen — blader door vaste-prijsaanbiedingen onder websiteontwikkeling, softwareontwikkeling of webapplicaties, of per marktplaats bij webdesign, WordPress-ontwikkelaars, ontwikkeling van mobiele apps of Shopify-experts.

Begin vanuit de persoon als het werk discussie behoeft. Blader door ontwikkelaars per discipline of per tool — React, WordPress, PHP, Python of Webflow — of plaats de briefing en laat voorstellen naar u toekomen. Op Zinn Hub is het plaatsen van een project gratis, en u kunt het richten op een specifiek gebied zoals websiteontwikkeling, back-end ontwikkeling of ontwikkeling van mobiele apps.

Filter streng op relevantie en licht op al het andere. Een ontwikkelaar die drie dingen heeft geleverd die lijken op die van u, verslaat bijna altijd iemand met twee keer zoveel ervaring in een ander domein.

Hoe een ontwikkelaarsportfolio te lezen

U kunt iemands code niet controleren, en dat hoeft ook niet. Een portfolio vertelt u nog steeds veel als u weet waar u op moet letten.

• Open de live links. Een screenshot bewijst niets. Laad de site op uw telefoon, gebruik hem, breek hem. Alles wat vandaag kapot is, is kapot goedgekeurd.
• Zoek naar problemen zoals die van u. Niet dezelfde branche — dezelfde vorm. Een boekingsstroom is een boekingsstroom, of het nu gaat om het verkopen van kapsels of helikopters.
• Controleer wat ze hebben gedaan. Vraag bij teamprojecten welke onderdelen van hen waren. “Ik heb eraan gewerkt” kan veel of heel weinig betekenen.
• Test de basis zelf. Laadt de pagina snel? Werkt het op een telefoon? Zijn formulieren bruikbaar met een toetsenbord? Dit zijn ambachtelijke signalen die een niet-technische koper perfect kan lezen.
• Lees de recensies als een geheel van bewijsmateriaal. Eén lovende recensie is ruis. Een patroon over velen, vooral over communicatie en deadlines, is een signaal. Op Zinn Hub vereisen recensies een bevestigde aankoop.
• Vraag wat er misging. Het sterkste antwoord op “vertel me over een project dat slecht ging” is een specifiek, onflatteus, goed geanalyseerd verhaal. Er bestaat geen ontwikkelaar met alleen soepele projecten.

Voor een systematische versie hiervan, doorloop onze 12-stappen checklist voor het screenen van freelancers.

Vragen om te stellen voordat je iemand inhuurt

Het doel is niet om iemand te betrappen. Het is om te horen hoe iemand denkt wanneer het antwoord niet is ingestudeerd.

• Leg een eerdere build uit“Loop me door een van deze projecten en de afwegingen die je hebt gemaakt.” Een goede ontwikkelaar zal iets noemen wat hij heeft gekozen om niet te doen en waarom. Jargon zonder afwegingen is een waarschuwingssignaal.
• Wat baart u zorgen hierVraag wat het meest risicovolle deel van uw briefing is. Iedereen die zegt “niets, het is eenvoudig” heeft het niet goed gelezen.
• Wat ontbreekt er“Wat zou u van mij nodig hebben dat ik niet heb geleverd?” Sterke kandidaten beantwoorden dit onmiddellijk en gedetailleerd.
• Hoe zie ik de voortgangEen staging-link, een wekelijkse update, een gedeeld bord. Elk antwoord is prima; geen antwoord is dat niet.
• Wat gebeurt er na de lanceringBugvenster, ondersteuningsvoorwaarden, documentatie. Spreek dit af voordat u begint, niet wanneer er iets kapot gaat.
• Wie is eigenaar van de codeVraag het direct. Het antwoord moet u zijn, bij levering, schriftelijk, inclusief alles wat nodig is om het uit te voeren.

Test voordat je je vastlegt

De goedkoopste verzekering die een koper kan afsluiten, is een kleine betaalde klus vóór een grote. Geen onbetaalde proef, die goede freelancers weigeren en die u niets vertelt over hoe iemand zich gedraagt als er geld mee gemoeid is — een echte, kleine, betaalde taak.

Een goede testtaak is representatief, op zichzelf staand en in één keer af te ronden: een specifieke bug oplossen, één pagina responsief maken, een formulier toevoegen en aansluiten, een trage pagina verbeteren. Wat u echt beoordeelt, is niet de code. Het is of ze een verhelderende vraag stelden voordat ze begonnen, of ze leverden wat gevraagd werd in plaats van wat ze verkozen, of ze uitlegden wat ze deden, en of de door hen opgegeven tijdschaal de tijdschaal was die u kreeg.

Op Zinn Hub is het natuurlijke formaat een Micro Zinn — een taak met een vaste prijs van $5, $10, $15 of $20. Blader door bugfixes en kleine codetaken of website bugfixes en aanpassingen, of begin met een prijs met $20 Micro Zinns. Onze gids over een freelancer testen voordat u zich vastlegt behandelt hoe u de test structureert en beoordeelt.

Wat het kost en hoe te betalen

De prijzen voor ontwikkeling variëren meer dan in welke andere freelance categorie dan ook, omdat het werk meer varieert. Wat volgt zijn typische marktbanden voor de hele klus, geen Zinn Hub-prijzen, en elke freelancer stelt zijn eigen prijzen vast.

• Kleine taak

  Onder $200

  Een bugfix, een pluginconflict, een formulier, een snelheidspas, een kleine functie op een bestaande build. Het beste te kopen als een taak met een vaste prijs.

• Standaard build

  $500–$2,000

  Een platformgebaseerde site of winkel: themaconfiguratie, verschillende paginasjablonen, formulieren, basisintegraties, lancering.

• Geavanceerd

  $2,000–$8,000

  Aangepaste functionaliteit, accounts en logins, betalingen, integraties van derden, of een op maat gemaakt ontwerp dat vanaf nul is geïmplementeerd.

• Applicatie

  $8,000+

  Een echt softwareproduct: multi-role systemen, dashboards, mobiele apps, alles met zinvolle back-end logica en doorlopende engineering.

Kosten variëren per omvang, complexiteit en ervaring. Gebruik de bandbreedtes om een offerte te controleren in plaats van als tarief – als een getal twee bandbreedtes verwijderd is van waar uw opdracht hoort, is die kloof het gesprek waard.

Op Zinn Hub heeft elke Zinn een prijs die door de Zinner is vastgesteld, kopers betalen geen platformkosten en alle prijzen zijn in USD met een geschatte equivalent in uw eigen valuta. Een bestelling wordt als één geheel betaald en beschermd; er is geen gefaseerde of mijlpaalvrijgave, dus een gefaseerde bouw wordt als afzonderlijke bestellingen geplaatst of als afzonderlijke geprijsde fasen in uw projectbrief overeengekomen. Kies een Platform Protected Zinner en uw betaling wordt door Zinn Hub vastgehouden totdat de bestelling is voltooid; elke terugbetaling wordt volledig op uw Zinn Wallet bijgeschreven, in USD. Zinners die hun eigen PayPal- of Stripe-account koppelen, worden direct bij het afrekenen betaald.

Eigendom, toegang en overdracht

Dit is het gedeelte dat kopers overslaan en later betreuren. Spreek alles schriftelijk af voordat het werk begint, want na levering heeft u geen invloed meer.

• Accounts op uw naam. Domein, hosting en eventuele diensten van derden moeten op uw naam worden geregistreerd, met de ontwikkelaar toegevoegd als gebruiker. Nooit andersom.
• Code-eigendom bij levering. Vermeld duidelijk dat bij de definitieve betaling het werk van u is om te gebruiken, te wijzigen en elders te plaatsen. Vraag naar eventuele componenten van derden met hun eigen licenties.
• Toegang tot de repository. Zelfs als u deze nooit opent, moet u deze aan de volgende ontwikkelaar kunnen geven.
• Inloggegevens, allemaal. Admin-logins, API-sleutels, databasetoegang, implementatietoegang — overgedragen en bevestigd werkend vóór de definitieve betaling.
• Documentatie. Een korte schriftelijke notitie over hoe te implementeren, waar dingen zich bevinden en wat te doen als het kapot gaat. Eén pagina is genoeg; niets is niet.
• Een bugvenster. Een gedefinieerde periode na de lancering waarin echte defecten zonder extra kosten worden verholpen. Dertig dagen is een veelvoorkomende, redelijke vraag.

Auteursrecht- en licentievoorwaarden variëren per land en per contract, dus beschouw dit als algemene richtlijnen in plaats van juridisch advies en vraag professioneel advies over alles wat commercieel significant is.

Fouten die ontwikkelingsprojecten doen mislukken

• Aannemen voordat de opdracht bestaat. Elk uur dat wordt besteed aan specificatie bespaart er meerdere in bouw en herwerk. Niets anders op deze lijst is zo belangrijk.
• Alleen op prijs kiezen. De laagste offerte is vaak degene die het minst begreep, en het verschil komt naar voren als wijzigingsverzoeken.
• Stilzwijgend de scope uitbreiden. Kleine verzoeken tijdens een bouw zijn hoe vaste prijzen geschillen worden. Bundel ze, prijs ze, beslis erover.
• Geen staging-omgeving. Werk pas beoordelen wanneer het live is, is hoe een kapotte site door klanten wordt ontdekt in plaats van door u.
• De mobiele controle overslaan. De meeste van uw bezoekers gebruiken een telefoon. Keur niets goed wat u niet op een telefoon hebt geopend.
• Overdracht tot het einde uitstellen. Het moment om toegang en eigendom af te spreken is vóór de eerste commit, niet tijdens de laatste factuur.
• Geen onderhoudsplan. Software veroudert. Budgetteer vanaf dag één voor updates, back-ups en beveiliging, of betaal later voor een reddingsactie.
• De waarschuwingssignalen negeren. Vage antwoorden, gemiste kleine deadlines en druk om buiten het platform te betalen, worden allemaal behandeld in onze gids over veelvoorkomende freelancer-scams.

Als u nog steeds beslist of een freelancer überhaupt de juiste weg is, vergelijkt freelancer vs. bureau de twee eerlijk voor een kleine bedrijfsbouw.