Python, Django & AI

Overview

Python is the right tool when the problem involves data, automation or machine learning, and Django is a genuinely productive way to put a real application around it. Its admin interface alone frequently removes weeks of internal-tooling work that would otherwise be built from scratch.

On AI specifically, our position is deliberately unglamorous. A large share of what businesses actually need is document processing, classification, extraction and search — problems with measurable accuracy and clear value — rather than a chatbot. We build what will pay for itself.

Django

• The ORM with select_related and prefetch_related used properly, because Django makes N+1 queries particularly easy to write without noticing.
• Django REST Framework for APIs, with serialisers, permission classes and throttling.
• Celery with Redis or RabbitMQ for background work — report generation, imports, scheduled jobs, anything that must not run inside a request.
• The admin customised into a genuinely usable internal tool rather than left as a raw database editor.
• Migrations reviewed before they run, since a careless one locks a large table in production.
• Security defaults left on: CSRF, XSS escaping, SQL parameterisation, clickjacking protection, plus HTTPS enforcement, secure cookies and correct ALLOWED_HOSTS.

Data engineering

Most "AI projects" are data projects wearing a costume. We build the ingestion, cleaning, validation and storage that has to exist first: pandas and Polars for transformation, scheduled pipelines with retries and alerting, schema validation at ingestion so bad data fails loudly instead of quietly corrupting a dataset, and reproducible processing so a result from three months ago can be regenerated.

Practical AI

Document intelligence

Invoices, purchase orders, contracts and forms extracted into structured data with OCR and layout-aware models, with a confidence threshold and a human review queue for anything uncertain. This is where the clearest return usually is — it replaces measurable hours of manual data entry.

Retrieval-augmented generation

Search and question answering over your own documents. The engineering that determines whether it works is in the retrieval, not the model: sensible chunking, good embeddings, a vector store sized to the corpus, hybrid keyword-plus-semantic search, and reranking. We ground answers in retrieved sources and cite them, so a user can verify rather than trust.

Classification and prediction

Routing support tickets, scoring leads, flagging anomalies, forecasting demand. Often a well-tuned classical model beats an LLM here on cost, latency and accuracy together, and we will use one when it does.

Computer vision

Defect detection, quality inspection and object counting with PyTorch or TensorFlow, deployed at the edge where latency or connectivity requires it.

Building LLM features responsibly

The gap between a demo and production is where these projects fail. What we insist on:

• Evaluation before rollout. A test set with expected outputs and a measured accuracy number. "It looked good when we tried it" is not a result.
• Cost and latency budgets. Token costs scale with usage in ways that surprise people; we model them before launch and cache aggressively.
• Hallucination handling. Ground responses in retrieved data, cite sources, and design the interface so the model is visibly assisting rather than deciding.
• Prompt injection defences where the model sees untrusted input, and no tool with real-world consequences invoked without confirmation.
• Data governance. Explicit decisions about what leaves your infrastructure, with self-hosted open models where the data cannot.
• A fallback path for when the provider is down or rate-limits you, because it will happen.

Deployment

Applications containerised and deployed with Gunicorn or Uvicorn behind a reverse proxy, dependencies pinned and reproducible, GPU inference only where the workload actually justifies the cost, and model versions tracked so a change in output can be traced to a change in the system.

How we work

1. Start with the business metric the project is supposed to move.
2. Check the data honestly — most projects are constrained by data quality, not model choice.
3. Build the smallest version that can be evaluated, and evaluate it.
4. Put it in front of real users with a human in the loop where the cost of being wrong is high.
5. Monitor accuracy, cost and latency in production, because model behaviour drifts.

What you get

• A Django application with the admin built into a tool your team will actually use.
• Data pipelines with validation, retries and alerting.
• AI features with a measured accuracy figure and a modelled running cost.
• Clear documentation of what leaves your infrastructure and what does not.
• An honest answer when a simpler approach would work better than AI.

Most AI projects are data projects. If the data is inconsistent, no model choice will rescue the result.