The engine only the scientists could run

The situation

A research team at Syngenta had built something genuinely valuable: an engine that predicted crop growth stages and other agricultural outcomes. It worked. The problem was that using it meant asking them.

Business users inside the company wanted those predictions, and so did clients outside it. Every request reached the research team as a message and left as a hand-prepared answer. So the scientists spent their days servicing requests instead of doing research, and everyone else waited on a specific group of people to be free. A capability that could have been a product was operating as a favour.

What I did

I was lead developer alongside one other engineer, working with the product manager, the research scientists and the engine’s own developer.

The service ran serverless on AWS: API Gateway in front of C#/.NET Core Lambda functions that validated incoming requests, invoked the predictive engine and returned structured JSON forecasts, with IAM-based authentication controlling which consumers could reach what.

The infrastructure was the straightforward part. The work that mattered was defining the contract — the endpoints, the request and response schemas, what an error means and what the caller should do about it — precisely enough that someone could build against it without asking a human a question.

That is the entire difference between a service and a favour. A capability people have to request is not available; it is rationed by whoever answers.

The one piece I would look at again is how I handled the business rules. I built something engine-like to hold them, and it worked, but it is the part of the design I am least confident was the simplest answer available.

Why this one went smoothly

Most productisation projects fail at the seam between the people who built the thing and the people packaging it. This one did not, and the reason is unglamorous: everyone who needed to agree was in the conversation. The product manager, the scientists who understood what the predictions actually meant, and the developer who knew the engine’s behaviour were all reachable while the contract was being defined, rather than consulted after it was designed.

The genuine difficulty was not technical. I joined in January 2020, and about two months later everyone went home. The company moved from working in the office — one nominal remote day a week, which I had never used — to fully remote, overnight, while people dealt with illness and family at the same time. The work still had to ship.

Some collaborating teams were in India, and access to shared resources occasionally became a bottleneck in a way it had not been when everyone sat in one building.

I would rather say that plainly than invent a technical drama. The engineering went well. The circumstances were the hard part, and the project delivered anyway.

What changed

The manual request process ended. Consumers inside and outside the company called the API and got structured forecasts back, and the research staff got their time returned for the work only they could do.

The service ran in production for at least five years, from 2020 through to at least 2025. The team has since been disbanded and I have not kept in touch, so I cannot say whether it is still running today.

Why this still matters

Almost every organisation has one of these — something valuable that only works when a particular person is available. It looks like a staffing problem. It is usually an interface problem: the capability is fine, it simply has no way in that does not involve interrupting someone.

Finding those, and giving them a front door, is a large part of what I now do.