De situatie
Teelor is een uitzendbureau dat professionals koppelt aan bedrijven in heel Nederland. Het bedrijf draaide op Bullhorn, een CRM-platform voor recruitment. Maar na jaren van groei was het gat tussen wat Bullhorn kon en wat Teelor nodig had een dagelijkse rem op de operatie geworden.
Consultants kopieerden kandidaatgegevens heen en weer tussen Bullhorn, e-mailtemplates en spreadsheets. Statussen werden in drie systemen met de hand bijgewerkt. Voor elke factuur moest iemand de urenregistratie in de ene tool naast de tarieven in een andere leggen. Elke maand was het backofficeteam dagen bezig met afstemmen. Een goed gekoppeld systeem doet dat in een paar minuten.
De oprichter begreep het probleem, maar kon de oplossing niet beoordelen. Investeren in maatwerk binnen Bullhorn? Een middleware-laag bouwen? Bullhorn helemaal vervangen? Elke optie had andere kosten, doorlooptijden en risico's — en niemand in de organisatie had de technische diepgang om die keuze te maken.
Teelor had al eens een freelance developer ingehuurd. Dat leverde een verzameling scripts op die werkten zolang die developer beschikbaar was, en braken zodra hij dat niet was. Geen documentatie, geen tests, geen deploymentproces. De oprichter had geen nieuwe developer nodig. Hij had iemand nodig die het technische landschap kon doorgronden, architectuurbeslissingen kon nemen en daarna kon bouwen.
Hoe we onderdeel werden van het team
We begonnen met een tech lead die de eerste drie weken meedraaide, nog voordat er ook maar iets gebouwd werd. Dit was geen extern rapport dat als pdf werd opgeleverd. De tech lead zat bij het operationele team, bracht de echte workflows in kaart (niet de gedocumenteerde) en stelde een technische strategie op. Gebaseerd op wat het bedrijf echt nodig had, niet op wat het dacht te willen.
De conclusie: Bullhorn moest het leidende systeem blijven, maar Teelor had een eigen backofficelaag nodig die het repetitieve werk eromheen automatiseerde. De API van Bullhorn kon veel, maar werd te weinig benut. Een middleware-aanpak — Bullhorn-data synchroniseren naar een applicatie op maat met workflowautomatisering — zou de meeste waarde opleveren met de minste verstoring van de organisatie.
Toen de strategie stond, schaalden we op naar een Mino van zes mensen. De tech lead bleef de hele tijd aan boord en zorgde voor continuïteit tussen analyse en uitvoering. Engineers stapten in met kennis van de architectuurbeslissingen en de redenen erachter. Logisch, want degene die die beslissingen had genomen, leidde ook de bouw.
De DevOps-engineer zat er vanaf week één bij, niet pas later als sluitpost. CI/CD-pipelines, geautomatiseerde tests en deployment-infrastructuur bouwden we tegelijk met de applicatie, niet achteraf eraan vastgeplakt. Daar onderhandelen we niet over. Engineeringdiscipline is geen fase, het is een manier van werken.
Wat we bouwden en waarom
Bullhorn als leidende bron, niet als interface. Bullhorn vervangen was duur en ingrijpend. Er een volledige schil omheen bouwen betekende functionaliteit dupliceren. Daarom bouwden we een gerichte backofficeapplicatie die kandidaat- en klantdata via de API van Bullhorn ophaalt, maar de workflowautomatisering zelf afhandelt. Het operationele team van Teelor doet het dagelijkse werk in de nieuwe applicatie. Bullhorn blijft de leidende databron voor compliance en rapportage.
Kandidaatmatching op basis van ChatGPT. De consultants van Teelor waren veel tijd kwijt met vacatureteksten lezen en die in hun hoofd naast kandidaatprofielen leggen. We integreerden de API van OpenAI om die eerste matching te automatiseren. Het systeem haalt relevante kandidaten naar boven op basis van vaardigheden, ervaring en beschikbaarheid. Het stelt matches voor, consultants beoordelen en verfijnen. Voor de meeste functies ging de tijd tot een shortlist van uren naar minuten, terwijl het menselijk oordeel in het proces bleef.
Automatische synchronisatie van statussen. Het meest acute knelpunt: statussen die op drie plekken stonden. We bouwden een tweerichtingssynchronisatie tussen Bullhorn, de backofficeapplicatie en e-mailnotificaties. Past een consultant ergens de status van een kandidaat aan, dan wordt die overal bijgewerkt. Geen afstemsessies meer op maandagochtend.
We raadden realtime dashboards af. Het oorspronkelijke verzoek bevatte managementdashboards met realtime KPI's. We keken naar het ritme waarin echt beslissingen vielen — wekelijkse teamoverleggen, maandelijkse bestuursvergaderingen — en adviseerden dagelijkse rapportages via batchverwerking. Realtime dashboards voor wekelijkse beslissingen voegen complexiteit toe zonder waarde. De eenvoudigere aanpak stond sneller live en verbruikt minder resources.
Het bewijs
0% change failure rate over zes maanden. De oude ontwikkelomgeving had geen geautomatiseerde tests, geen CI-pipeline en geen stagingomgeving. Wijzigingen gingen direct van de laptop van een developer naar productie, en de oprichter controleerde elke deployment met de hand. Wij zetten een complete delivery-pipeline neer: geautomatiseerde tests (unit-, integratie- en API-contracttests), een stagingomgeving die productie spiegelt en automatische deployments na het mergen van een pull request. In zes maanden wekelijks deployen — meer dan 25 productiereleases — veroorzaakte geen enkele release een incident voor klanten.
2 dagen doorlooptijd naar productie. In het oude proces duurde het twee tot drie weken voordat een wijziging in productie stond. De vertraging zat niet in het ontwikkelen, maar in de coördinatie: een deploymentmoment plannen, goedkeuring van de oprichter krijgen, de deployment handmatig uitvoeren en het resultaat handmatig controleren. Met geautomatiseerde CI/CD staat een pull request die op maandag wordt gemerged op woensdag in productie, volledig getest en met automatische rollback.
Wat we achterlieten
Teelor heeft nu een werkend backofficeplatform, een betrouwbare deployment-pipeline en een heldere technische architectuur waar elk competent ontwikkelteam op kan voortbouwen. Maar belangrijker: ze hebben een technische strategie.
Vóór onze samenwerking waren technische beslissingen bij Teelor reactief. Iemand liep tegen een probleem aan, iemand anders stelde een tool voor, en losse oplossingen stapelden zich op. De analyse van de tech lead en de architectuurbeslissingen tijdens de bouw vormen nu een kader waarmee Teelor nieuwe technische investeringen beoordeelt: Past het in de bestaande architectuur? Haalt het handmatig werk weg of verplaatst het dat alleen? Kan het team het onderhouden?
We leerden twee mensen uit het operationele team van Teelor het deploymentproces en de basis van applicatiemonitoring. Zij doen nu de routinematige deployments en de eerstelijns triage van issues. Voor complexer engineeringwerk heeft Teelor een parttime developer aangenomen. Die kreeg een codebase met volledige testdekking, gedocumenteerde API's en geautomatiseerde deployments — het tegenovergestelde van de “works on my machine”-scripts die ze van hun vorige freelancer hadden geërfd.
De ChatGPT-integratie is modulair opgezet. Wil Teelor experimenteren met andere modellen of de matchingcriteria aanpassen? Dan passen ze de configuratie aan, niet de code. Dat is een bewuste architectuurkeuze. AI-mogelijkheden ontwikkelen zich snel, en bedrijfslogica vastknopen aan één specifiek model levert technische schuld op die snel oploopt.