The situation
Teelor is a staffing agency that matches professionals with companies across the Netherlands. Their business ran on Bullhorn — a CRM platform built for recruitment — but after years of growth, the gap between what Bullhorn could do and what Teelor needed had become a daily operational drag.
Consultants were copy-pasting candidate information between Bullhorn, email templates, and spreadsheets. Status updates happened manually across three systems. Invoice generation required someone to cross-reference timesheets in one tool with rates stored in another. Every month, the back-office team spent days on reconciliation that a well-integrated system would handle in minutes.
The founder understood the problem but had no way to evaluate the solution. Should they invest in Bullhorn customization? Build a middleware layer? Replace Bullhorn entirely? Each option carried different costs, timelines, and risks — and no one in the organization had the technical depth to make that call.
Teelor had tried hiring a freelance developer once before. The result was a set of scripts that worked when the original developer was available and broke when he wasn't. No documentation, no tests, no deployment process. The founder didn't need another developer — he needed someone who could assess the technical landscape, make architectural decisions, and then build.
How we embedded
We started with a Technical Lead embedded for the first three weeks before any engineering began. This wasn't an external assessment delivered as a PDF — the Lead sat with the operations team, mapped their actual workflows (not the documented ones), and built a technical strategy based on what the business genuinely needed versus what it thought it wanted.
The conclusion: Bullhorn should stay as the system of record, but Teelor needed a custom back-office layer that automated the repetitive work around it. The Bullhorn API was capable but underused. A middleware approach — syncing Bullhorn data into a purpose-built application with workflow automation — would deliver the most value with the least organizational disruption.
Once the strategy was set, we scaled to a six-person Mino. The Technical Lead stayed throughout, maintaining continuity between the assessment and the execution. Engineers joined the team already understanding the architectural decisions and the reasoning behind them — because the same person who made those decisions was leading the build.
The DevOps Engineer embedded from week one, not added later as an afterthought. CI/CD pipelines, automated testing, and deployment infrastructure were built alongside the application, not bolted on after the fact. This is a non-negotiable part of how we work — engineering discipline isn't a phase, it's a practice.
What we built and why
Bullhorn as source of truth, not as UI. Rather than replacing Bullhorn (expensive, disruptive) or building a full wrapper around it (duplicating functionality), we built a focused back-office application that consumed Bullhorn's API for candidate and client data but handled workflow automation independently. Teelor's operational team works in the new application for daily tasks; Bullhorn remains the canonical data store for compliance and reporting purposes.
ChatGPT-powered candidate matching. Teelor's consultants spent significant time reading job descriptions and mentally matching them against candidate profiles. We integrated OpenAI's API to automate the initial matching — surfacing relevant candidates based on skills, experience, and availability. The system suggests matches; consultants review and refine. This reduced the time-to-shortlist from hours to minutes for most roles while keeping human judgment in the loop.
Automated status synchronization. The most immediate pain point: status updates that lived in three places. We built bi-directional sync between Bullhorn, the back-office application, and email notifications. When a consultant updates a candidate status in one place, it propagates everywhere. No more Monday morning reconciliation sessions.
We pushed back on real-time dashboards. The initial request included executive dashboards with real-time KPIs. We assessed the actual decision-making cadence — weekly team meetings, monthly board reviews — and recommended daily batch-processed reports instead. Real-time dashboards for weekly decisions add complexity without value. The simpler approach shipped faster and uses fewer resources.
The evidence
0% change failure rate across six months. The previous development setup had no automated tests, no CI pipeline, and no staging environment. Changes went from a developer's laptop directly to production, with the founder manually verifying each deployment. We established a complete delivery pipeline: automated tests (unit, integration, and API contract tests), a staging environment mirroring production, and automated deployments triggered by pull request merge. In six months of weekly deployments — over 25 production releases — zero caused a customer-facing incident.
2-day lead time to production. Under the old process, getting a change into production took two to three weeks. The delay wasn't development time — it was coordination overhead: scheduling a deployment window, getting the founder to approve, manually running the deployment, and then manually verifying the result. With automated CI/CD, a pull request merged on Monday is deployed to production by Wednesday, fully tested, with automatic rollback capability.
What we left behind
Teelor now has a functioning back-office platform, a reliable deployment pipeline, and a clear technical architecture that any competent engineering team can extend. But more importantly, they have a technical strategy.
Before our engagement, technical decisions at Teelor were reactive — someone had a problem, someone else suggested a tool, and ad-hoc solutions accumulated. The Technical Lead's assessment and the architectural decisions made during the build created a framework Teelor now uses to evaluate new technical investments: Does it fit the existing architecture? Does it reduce manual work or just move it? Can the team maintain it?
We trained two of Teelor's operations team members on the deployment process and basic application monitoring. They now handle routine deployments and first-line issue triage. For more complex engineering work, Teelor has hired a part-time developer who inherited a codebase with full test coverage, documented APIs, and deployment automation — the opposite of the "works on my machine" scripts they inherited from their previous freelancer.
The ChatGPT integration is modular by design. When Teelor wants to experiment with different models or adjust matching criteria, they change configuration — not code. This is a conscious architectural choice: AI capabilities evolve fast, and coupling business logic to a specific model creates technical debt that compounds quickly.