About us

Our founders Jake and Tommy met as Head of IT and Lead Developer at Exponential-e and worked together to spearhead the rollout of best practices across the organisation.

They developed truly innovative, industry-leading techniques as they assisted in redefining and standardising processes in order to adopt automation. Realising that others would value their experience, and with the full support of Exponential-e, they created JDLT and began expanding their team and its approach.


Microsoft Gold Partner
AWS Select Consulting Partner
Cisco Partner
Cisco Meraki Partner

JDLT are cloud-native.

We find that using and creating solutions in the cloud allow us to focus on what we're good at; developing and supporting high-quality business software and applications.

We are also cloud agnostic; we don't mind which cloud provider we use to host the solutions we build.
However, we recognise that companies often have pre-existing relationships with certain cloud providers and are often more comfortable expanding those relationships than using a new provider.

As such JDLT have partnered with with all three major public cloud providers:

In order to provide best-in-class IT solutions JDLT have also partered with Cisco & Meraki.


What is your outlook on technology?

We see technology as a tool.

Investing in the right technology and tooling allows our team to work smarter and make fewer mistakes.

Which technologies do you use?

We use React (via create-react-app) for the UI and node.js (via Serverless Framework and AWS Lambda) on the back-end.

We use Webpack and Babel across our stack, enabling us to code in the very latest language features.

We have a preference for MongoDB databases but are familiar with and use all sorts others.

For a full list of the technologies we use, take a look at our Stackshare page

Why do you use AWS Lambda/Serverless?

We really like Serverless (it's the future!).
It allows us to rapidly develop and deploy code which means we can collect useful feedback ASAP.

How do you integrate systems?

We build and maintain ecosystems of microservices.

When we want to integrate a new system we write a new microservice to talk with that system (via API, direct DB access, or in system-native language).
Then we wrap that functionality in a GraphQL API.

This allows us to pull and push data via a user interface (or another microservice) in a consistent manner.

That sounds like a lot of complicated work?

It's really not.

Between common code we inherit from a shared repository, the simplicity of Serverless Framework and the power of ES6 we often find we barely have to write any code at all.

What technologies are you considering for the future?

We integrated GraphQL some time ago, recently introduced Hooks to our React projects and promoted our ES6 to TypeScript so we're pretty forward thinking.

We're also implementing Message Queues to handle millions of microservice requests and increase the performance, reliability and scalability of our ecosystems.

Do you have a strict set of coding rules/coding style guide?

All of our projects run ESLint and Prettier, automatically enforcing our rules and standards.

In fact, you can't even make a commit if the rules aren't met and tests don't pass.

How do you approach design?

Until recently we used Semantic UI within React. We've now moved across to using Tailwind CSS as it's much more flexible and the Semantic React team got jobs at Microsoft!

This means we barely ever have to touch HTML or CSS and that even us programmers can make decent-looking user interfaces. That said, if your project has a particular design requirement, we have access to plenty of fantastic designers.

What databases do you use?

When we need to create a new database we use MongoDB (via Mongoose in code).

We like how it manages to combine simplicity and flexibility whilst still being very powerful.

Often though we'll be integrating into an existing system.
We already have integrations in place that access data using Microsoft SQL Server, MySQL and PostgreSQL as well as REST and SOAP APIs.

Are there any particular adages you work to as a team?

We write code for the next developer - we think code should be written with clarity for the next developer as the number one concern.

The best code is sometimes no code - code is just a tool and sometimes one that doesn't need to be used.
More generally this also refers to how simple code is usually the best.

Why reinvent the wheel when a third-party library exists (or the language already does it)?