About
Hired for the problem, not for a seat licence
PostQL is a service-based technology consultancy. Our specialism is machine learning, AI, data science and NLP; our job is to apply it to something specific in your business and then hand it over.
We are a consultancy, not a platform
PostQL is a service-based technology consultancy. We do not sell a product or a seat licence. We are hired to solve a specific problem, and the engagement ends when your team can run what we built without us.
Our centre of gravity is machine learning, AI, data science and NLP. That specialism is the reason clients call, but very few problems arrive as a clean modelling exercise. Most of what we deliver is the surrounding work that makes a model matter: the pipelines that feed it, the workflow it plugs into, and the application someone actually opens.
Specialisation
Machine learning, AI, data science and NLP form the technical centre of the practice, applied to forecasting, scoring, extraction, classification and search.
Delivery
Custom workflows and business process automation, Webex collaboration integrations, and Android and iOS device applications built for the field.
Sectors
Proven delivery in healthcare, manufacturing, banking and fintech, and FMCG. Each carries its own constraints on data, audit and pace.
Delivery philosophy
How we work, and why
These are the four commitments that shape every engagement. They exist because each one addresses a specific way consulting projects tend to fail.
01
Scope before code
Every engagement opens with a discovery phase. We would rather tell you in week three that the data will not support the outcome you want than find out together in month six.
02
Production is the finish line
A model that works in a notebook has not been delivered. We take responsibility for deployment, monitoring and retraining, because that is where most machine learning projects quietly fail.
03
Your team leaves knowing how it works
We build with your engineers rather than around them, and hand over documentation, runbooks and the reasoning behind the decisions. A repository on its own is not a handover.
04
Measured against a baseline
We capture what the process costs before we change it. Improvements we claim afterwards are a number you can check, not a case study adjective.
A model that nobody in your organisation can retrain, explain or roll back is not an asset. It is a dependency on us, and we do not want to be that.
Cloud & partner ecosystem
The stack we deliver on
We do not ask clients to adopt a platform to work with us. Azure and AWS are both first-class delivery clouds, Databricks carries the data and ML workloads on either, and everything ships containerised.
Microsoft Azure
Cloud partner
Our default landing zone for regulated workloads: Azure ML for training and deployment, AI Language for text workloads, and the identity and compliance controls enterprise clients already run on.
AWS
Cloud partner
Where clients are already invested in AWS we deliver natively on it: SageMaker for the model lifecycle, Bedrock for language workloads, and the surrounding data services.
Databricks
Data & ML platform
Our data engineering and ML workload platform of choice on both clouds. Lakehouse for the pipeline, MLflow for tracking and the model registry, Spark where the volume warrants it.
Snowflake
Cloud data platform
Where the warehouse is the centre of gravity rather than the lakehouse. We build the modelling layer and the pipelines feeding it, and read from it directly for the ML workloads rather than copying the data somewhere else first.
Kubernetes
Deployment & MLOps
Every model and service we deliver ships as a workload your platform team can run, scale and roll back without us in the room.
Docker
Containerised delivery
Reproducible builds from the first sprint. What runs on a developer's machine is the same image that runs in your production cluster.
AI & technology
Models and technologies we build on
Model choice is a benchmark result on your data rather than a house preference, so we work across the frontier providers and run open weights on your own estate where the data cannot leave it.
OpenAI
GPT models
Our default for general reasoning and extraction work, and usually the baseline a task is measured against before we look at anything cheaper or more specialised.
Claude
Anthropic models
Where long documents and careful instruction-following matter. The large context window earns its place on contract, policy and clinical-document work.
Grok
xAI models
Evaluated alongside the others rather than assumed. Model choice is a benchmark result on your data, not a house preference.
Google Vertex AI
Google Cloud AI platform
The managed path for clients already on Google Cloud: Gemini models, training and endpoints inside the project and IAM boundary they already administer.
PyTorch
Model training
What we reach for when a problem needs a model trained rather than an API called. Fine-tuning, custom architectures and anything that has to run on your own hardware.
Hugging Face
Open models and tooling
Open-weight models for the workloads that cannot leave your estate, plus the tokenisers, datasets and evaluation tooling the rest of the work is built on.
What handover actually looks like
Outcomes we have delivered
- 32% reduction
- fewer mid-campaign stockouts
- FMCG
- 46% improvement
- of routine enquiries handled without a call
- Healthcare
- 4 sites delivered
- consolidated onto one patient record
- Healthcare
- 27% improvement
- lift in qualified-lead conversion
- Banking & Fintech
How an engagement runs
- 1DiscoveryAudit the data, agree the metric that matters
- 2DeliveryFortnightly increments, your engineers in the room
- 3HandoverRunbooks, retraining schedule, monitoring
Shipped on
- Microsoft Azure
- AWS
- Databricks
- Snowflake
- Kubernetes
- Docker
Work with us
Start with a scoping conversation
No engagement begins with a proposal. It begins with a call where we work out together whether there is a problem here worth solving, and whether we are the right people to solve it.
We reply to every enquiry within one business day.