Het eerlijke antwoord: het hangt af van de scope. Maar scope is precies wat de meeste ondernemers niet volledig gedefinieerd hebben wanneer ze de vraag stellen - wat de reden is dat de doorlooptijden die ze ontvangen in de offertefase vaak weinig overeenkomst vertonen met de werkelijkheid.
Dit artikel splitst de echte drivers van doorlooptijd bij Shopify custom builds uit, geeft je een praktische referentie per projecttype, en legt uit wat je kunt doen om sneller te gaan zonder kwaliteit op te offeren.
De vijf fasen van een custom Shopify build
Elke custom Shopify build - of het nu een eenvoudige webhook-integratie of een volledig B2B-portaal is - doorloopt dezelfde vijf fasen. De duur van elke fase varieert per projectcomplexiteit, maar geen enkele kan worden overgeslagen zonder gevolg.
Fase 1: Discovery en scoping
Wat er gebeurt: vereisten worden gedetailleerd in kaart gebracht, elk verbonden systeem wordt gedocumenteerd, het datamodel wordt gedefinieerd, randgevallen worden geïdentificeerd, en een technische specificatie wordt opgesteld.
Waarom het belangrijk is: deze fase bepaalt of de build het juiste probleem oplost. Onvoldoende discovery is de primaire oorzaak van scope creep, budgetoverschrijdingen en herstelwerkzaamheden na livegang.
Typische duur: 1 tot 3 weken voor eenvoudige integraties, 2 tot 5 weken voor complexe builds.
Fase 2: Architectuur en technisch ontwerp
Wat er gebeurt: de technische architectuur wordt gedefinieerd - hoe de app verbinding maakt met Shopify's API's, hoe het dataflow, foutafhandeling, herhaalpogingen en schaalbaarheid verwerkt. Admin UI-schetsen worden gemaakt en goedgekeurd indien van toepassing.
Waarom het belangrijk is: architectuurbeslissingen die hier worden genomen, beïnvloeden de onderhoudbaarheid en betrouwbaarheid van de app voor jaren. Het overslaan van deze fase produceert apps die aanvankelijk werken maar breekbaar worden naarmate vereisten evolueren.
Typische duur: 1 tot 2 weken.
Fase 3: Ontwikkeling
Wat er gebeurt: de app wordt gebouwd in gestructureerde sprints. Werkende functionaliteit wordt gedemonstreerd aan het einde van elke sprint. Geautomatiseerde tests worden naast de code geschreven.
Waarom het belangrijk is: sprint-gebaseerde oplevering biedt regelmatige controlepunten om te bevestigen dat de build de goede kant op gaat. Het brengt ook integratieproblemen vroeg aan de oppervlakte - wanneer ze goedkoper te repareren zijn.
Typische duur: 2 tot 24 weken afhankelijk van complexiteit.
Fase 4: Testen en QA
Wat er gebeurt: functionele tests, randgevaltests, integratietests met alle verbonden systemen, en prestatietests onder gesimuleerde belasting.
Waarom het belangrijk is: voor apps die checkout of orderverwerking raken, voorkomt deze fase incidenten die veelvouden van de oorspronkelijke bouwkosten kunnen kosten aan gederfde omzet.
Typische duur: 1 tot 4 weken.
Fase 5: Deployment en overdracht
Wat er gebeurt: productie-deployment, monitoring-opzet, documentatie en teamtraining.
Typische duur: 3 tot 7 dagen.
Doorlooptijd per projecttype: een realistische referentie
| Projecttype | Realistische totale doorlooptijd |
|---|---|
| Eenvoudige webhook-integratie of datasynchronisatie | 1 tot 3 weken totaal (discovery t/m deployment) |
| Single-functie storefront-app (geen externe integratie) | 2 tot 6 weken totaal |
| App met een externe systeemintegratie (ERP, WMS, PIM) | 4 tot 12 weken totaal |
| App met custom admin-UI en multi-systeemintegratie | 14 tot 24 weken totaal |
| Volledig B2B-portaal of complexe platform-app | 20 tot 40 weken totaal |
| Alleen Shopify Functions-aanpassing | 2 tot 5 weken totaal |
Deze doorlooptijden gaan uit van duidelijke, stabiele vereisten, snelle feedback van de ondernemer tijdens reviewcycli, en geen grote scopewijzigingen nadat de ontwikkeling is begonnen. Elk van deze aannames, wanneer hij breekt, voegt tijd toe.
Wat de doorlooptijd werkelijk bepaalt - en wat niet
Wat de doorlooptijd bepaalt: scope en integratiecomplexiteit
De grootste driver van doorlooptijd is het aantal systemen waarmee de app moet integreren, en de kwaliteit van documentatie en API-toegang beschikbaar voor die systemen. Een integratie met een goed gedocumenteerde REST-API kost een fractie van de tijd van een integratie met een legacy SOAP-systeem dat reverse-engineering vereist en geen sandbox-omgeving heeft.
Wat de doorlooptijd bepaalt: de kwaliteit van de vereisten
Projecten met duidelijk gedefinieerde, stabiele vereisten verlopen aanzienlijk sneller dan projecten waarbij vereisten tijdens de ontwikkeling worden ontdekt. Elke verduidelijking van een vereiste die tijdens een sprint plaatsvindt, kost tijd. Elke wijziging van een vereiste die al is gebouwd, kost twee tot drie keer meer dan in de discoveryfase.
Wat de doorlooptijd bepaalt: feedback- en reviewcycli
Elke sprint eindigt met een review- en goedkeuringscyclus. Als de ondernemer niet binnen twee tot drie dagen feedback kan geven, wordt de volgende sprint vertraagd. Bij een project van twaalf sprints voegen feedbackvertragingen van drie tot vier dagen per sprint vier tot zes weken toe aan de totale doorlooptijd.
Wat de doorlooptijd niet bepaalt zoals mensen verwachten: teamgrootte
Het verdubbelen van het ontwikkelteam halveert de doorlooptijd niet. Coördinatieoverhead, code-reviewvereisten en de sequentiële aard van bepaalde bouwfasen betekenen dat meer ontwikkelaars op een project vaak minder snelheid toevoegen dan verwacht.
De snelste projecten zijn niet die met de grootste teams. Het zijn de projecten met de duidelijkste vereisten en de meest responsieve klanten.
Hoe je sneller kunt gaan zonder kwaliteit op te offeren
Investeer in discovery voordat je een ontwikkelaar inschakelt
Hoe duidelijker je kunt definiëren wat de app moet doen - inclusief randgevallen, foutstaten en integratievereisten - voor de ontwikkeling begint, hoe minder tijd er wordt besteed aan verduidelijking tijdens de build. Een gedetailleerd briefingsdocument bespaart in de meeste projecten twee tot drie weken.
Faseer de oplevering
Definieer een MVP-scope die eerst kernfunctionaliteit levert. Lanceer hem. Valideer dat hij het probleem oplost. Bouw dan fase twee met het voordeel van echte gebruiksdata. Deze aanpak verlaagt de totale tijd tot waarde zelfs als de totale bouwtijd vergelijkbaar is.
Zorg dat API-toegang en documentatie klaar zijn voor de ontwikkeling begint
Voor integraties met externe systemen zijn vertragingen bij het verkrijgen van API-credentials, sandbox-toegang of documentatie van de externe vendor veel voorkomende oorzaken van tijdoverschrijdingen. Zorg dat alles beschikbaar is voor de ontwikkelingsfase begint.
Commit aan snelle feedbackcycli
Blokkeer tijd in je agenda voor sprint-reviews. Behandel ze als kritieke padactiviteiten. Een vertraging van twee dagen bij elke sprint van een project van twintig sprints voegt zes tot acht weken toe aan je doorlooptijd.
Een noot over vaste-prijs offertes met gedefinieerde doorlooptijden
Bureaus die vaste-prijs offertes aanbieden met gegarandeerde doorlooptijden voor de discovery is voltooid, prijzen risico in hun marge in - of plannen om agressief scope te controleren wanneer vereisten evolueren. Geen van beide uitkomsten dient je goed.
Een realistisch contractmodel: tijd-en-materiaal of gecapped-tijd-en-materiaal voor discovery, gevolgd door een vaste prijs of gefaseerd vasteprijscontract zodra de technische specificatie compleet is en de scope werkelijk bekend is.
Elk bureau dat je precies kan vertellen hoe lang het duurt en wat het kost voor ze jouw vereisten gedetailleerd begrijpen, vertelt je wat je wilt horen.
De Store Audit produceert een gescopede, gefaseerde technische aanbeveling met realistische doorlooptijden - voor enige ontwikkelcommitment wordt gemaakt. Het is het juiste startpunt voor elke custom build van betekenisvolle complexiteit.