Jobylon is an applicant tracking system built for enterprise hiring across brands and markets. We speak to Alex Tidgård, Chief Product Officer at Jobylon, about why candidate self-scheduling has run on Cronofy, white-labeled, and why it has never come back onto the build list.

The problem:

Scheduling looks like a feature until 100 customers each want it differently

Jobylon sells into enterprise recruitment, where customers have firm views about how interviews get booked and say so, which makes scheduling an unusually expensive thing to own.

Scheduling is very complicated. If you talk to 100 different customers, they're going to have very different views on what scheduling should be. 'Group interviews, this person needs to be in interviews, these three optional, but it can maximum be two people.' That is complicated for us to even consider all of those thousands of edge cases.

Alex weighs any build against what the same engineers would otherwise be shipping, and puts that alongside the raw cost.

What would it take us to build this ourselves? We have the cost of the developer doing it. We also have the opportunity cost of what we're not building as a result of building this versus buying it.

He has the counterexample in front of him in the job board integrations Jobylon maintains across every market it operates in, an upkeep he describes in terms no product team wants applied to a core workflow.

Then we're going to be like the Golden Gate Bridge, right? As soon as you paint it, you need to repaint it.

The solution:

A white-labeled scheduling layer Jobylon's users never see

Jobylon runs candidate self-scheduling as its own feature, with Cronofy underneath and out of sight.

We say it's our scheduling function. Our self-scheduling function. Here it is. It's based on Cronofy, but we don't really expose it.

The technical fit was only half of the decision, because a vendor sitting this deep in the product is a long-term commitment, and Alex tests for that before signing anything.

Every time we do this, we want to approach it as a partnership. We feel like we can go into customer meetings with you to help people adopt. Some people might say, 'Oh, it's just a transactional thing.' I personally don't think so. I think a partnership is so much more valuable.

Before cost, Alex asks whether the thing belongs to Jobylon at all.

Is it super close to our IP? Should we definitely own this on our own? This is almost the first question I ask.

Scheduling came out on the other side of that line. The edge cases Alex lists belong to interview scheduling specifically, and solving them for HR Tech platforms is what Cronofy has done for over a decade, with zero breaking changes and no API ever deprecated.

The result:

One API version, zero migrations

The API Jobylon first integrated against is the API it runs on today.

Forced migration is a standing tax on everything else Jobylon integrates with.

There's a constant 'this one's deprecated,' 'this one goes down,' 'we have these new things, you need to upgrade.' And then the customer comes to us like, hey, we want to be able to use this feature. And then we need to put time and effort into upgrading the integration with the new API calls. Constant worry, constant struggle.

The scheduling layer built with Cronofy has not once appeared on that list.

That leaves the team free for what it is building next. Jobylon is opening up the front of the candidate journey, nurturing candidates before they ever reach the ATS, and rebuilding its platform experience around AI rather than adding it on top. An ATS's AI is only as good as the record beneath it, and interviews booked and moved outside the platform leave holes in that record. Booking them inside Jobylon keeps the record whole.

People sprinkle AI on top of a human-built process a lot of the time and then expect crazy results. What we've been trying to do is really think about it as a tool, and see where does that fit into our process.

Watch the full conversation with Alex: