Edge cases are the problem when it comes to infrastructure

Infrastructure needs a different approach. Edge cases can't be ignored. Bugs can't be left unfixed.

Most engineering wisdom treats these as trade-offs. Ship now, fix later. Cover the common case, defer the rest. That's rational for most products. It's the wrong approach for infrastructure, where the edge case is the product, and the bug isn't an inconvenience — it's the layer beneath you not working.

We didn't start with a use case at Cronofy. We started with a data problem. Temporal information was locked away inside the systems teams already used to coordinate, calendars in the main, in formats that didn't talk to each other. Interesting questions couldn't be asked because you couldn't see all the context at once. Before you could build anything useful on top, you had to do the unglamorous work of getting the data into one place, in a shape that let you inspect it.

With the root cause identified, we worked the problem. How hard could it be? That work, of course, took longer than we expected.

Roughly six months later, we looked at what we'd built and realized very few SaaS teams could justify the same investment. The same fragmentation we'd been wrestling with for our own product showed up everywhere. Time is one of the few constructs no one can escape. Same problems, different nouns. Every platform that needed to coordinate time was either pretending the problem was simpler than it was, or sinking months of engineering effort into solving it badly.

We packaged what we'd had to build anyway, and turned it into something other teams could use. The API wasn't a pivot. It was our investment, made reusable.

What changed at that point was how we thought about what we were building. The mission was the same one we'd started with: saving people time. But the way we could most effectively help teams manage their time turned out to be by helping the builders whose products those teams already used every day. Cronofy stopped being a product with users and started being infrastructure with builders. The teams were still the point. The builders were the route.

Specifically, the time we wanted to save was the time spent on work that shouldn't have to be done manually. Recruiters chasing availability, developers implementing the wiring of calendar integration, anyone whose week is being filled by coordination overhead that can be solved by the system.

The time a developer spends building a calendar integration matters. The time they spend thinking about it matters too. Most of the value we provide isn't visible. It's the absence of work the customer's team would otherwise have to do.

If you're not committed to solving the underlying problem, edge cases look like bugs. They're inconvenient but not critical. You can defer them, scope them out, mark them as "advanced" and ship without them. The product still works for the majority of people the majority of the time.

When building infrastructure you are committed. Edge cases stop being a separate category. They're just evidence you've not fully solved the problem. The data isn't unified until it's unified across every system that holds it. The availability isn't correct until it accounts for every calendar a person actually uses. Saying "we handle the common case" is just another way of saying the problem isn't solved yet.

This is what infrastructure means. Not just that you've built something powerful, but that you've refused to compromise at the edges.

We take pride that our API is still on V1. We didn't ship a first version and then a fixed version and then a real version. We did, and do, the work to make it right before we put it in front of a customer. We design for extensibility and long-term support from the start.

We have a principle called "no known bugs." If we know about it, we fix it. We don't have a backlog of known issues that get triaged forever and quietly accepted as the cost of moving fast. We think of bugs as ballast: they slow you down, and the longer you carry them, the harder it gets to put them down. We've had this policy from day one. It's the kind of thing that's almost impossible to introduce later, because a mature system without it has accumulated too much weight to ever clear the backlog. You either build that way from the start or you don't.

No known bugs can result in a can of worms exploding on your desk. Like when you see an Exchange server that allows you to register for change notifications but never sends them, because a firewall drops the callbacks. You intervene in a way that you can control: initially forcing that customer toward polling. Then you build the processes that notice the silence and automatically fall back to polling for anyone going forward. You also intervene more holistically by reconfiguring infrastructure to provide fixed IPs for admins to permitlist. And then a few weeks later you get back to the enhancement you were working on.

As that demonstrates, none of this is free. Committing to V1 means moving slower in the short term. No known bugs means engineers stop what they're doing to fix things that, on another team, would sit politely in a backlog. For most products, that's the wrong trade. If the edge case is affecting a small fraction of users on one feature of a broader platform, it's rational to defer it. You have other things to build with higher potential value, and the math works out.

But when you're building infrastructure and the edge case is your product, the thing not working for one person in a team is the same thing as not working for the whole team. The people it doesn't work for are unable to do their job. Through that lens it isn't an edge case. It's just the product, failing. Worse, there is often someone maintaining a system in the middle who cannot fix the problem directly.

The discipline isn't perfectionism. It's the only sensible response to what you're actually building.

The highest compliment we hear from customers is that we're their most boring point of integration. They don't think about us. They build something on top of Cronofy, it works, it keeps working, and the conversation moves on.

Exciting to integrate with, then boring. That's the goal.

The most concrete of edge cases that it would be rational for most to ignore today is on-premise Exchange. It's a minority as a cohort, and each member can bring new variations to the mix. We've had the privilege of discovering them for a decade.

The migration to cloud is real, but it isn't finished. A meaningful portion of business calendars still live on-prem, and the teams running them tend to be in regulated industries — financial services, healthcare, large enterprise. They're not going to migrate first. They'll migrate last, if at all.

You can address the vast majority of your customer base and miss a disproportionate amount of the revenue. But it's not really about revenue. Those teams still need to schedule things. They're no different from other teams. The fact that their calendar lives behind a different protocol doesn't change the underlying need. If you're building infrastructure for time, and you've quietly decided that on-prem Exchange isn't your problem, then you've decided some teams don't count.

It's a coherent product decision to deprioritize Exchange support. It's just not infrastructure.

Every team building anything that depends on time eventually arrives at the same decision. Declare the data layer done and ship: most of the customers, most of the time, good enough. Or keep going until it works across every system the teams who depend on it use.

On temporal infrastructure, we just keep going. The next edge case isn't an interruption to the work. It is the work.