xHow to choose a Django development agency: 12 questions to ask
Most failed software projects were in trouble before the first line of code. These twelve questions separate agencies that will ship your Django application from the ones that will learn on your budget.
- Ask to see Django work in production, and to meet the people who will build yours.
- Good agencies estimate after a short discovery, not from a one-page brief.
- You should own the code and the hosting accounts from the first day.
- Working software every two weeks is the best early warning system you can buy.
Before you start shortlisting
Write down three things before you speak to anyone: the business outcome you need (not the feature list), a budget band you are comfortable with, and the date that actually matters. Agencies give much better answers to "we need to cut onboarding from two weeks to two days by March" than to a forty-page specification.
Experience and team
1. Can you show us Django projects like ours that are live today?
Case studies are marketing. Live applications are evidence. Ask for a link, what the agency built, and how long it has been running. A good answer names the problem, the result and the stack, and offers a client you can speak to.
2. Who exactly will work on our project?
Many agencies sell with seniors and deliver with juniors. Ask for names, roles and how much of their week is yours. If the people in the sales meeting will not be in your repository, you are buying a different team from the one you met.
3. Which Django and Python versions do you build on?
The answer should be a current long-term support release, such as Django 5.2 LTS on a supported Python. An agency that starts new work on an old release is handing you an upgrade bill on day one.
Process and estimates
4. How do you estimate, and how accurate are you?
Look for a range that narrows over time, with assumptions written down. A precise fixed price from a short brief means either a large hidden contingency or a fight about change requests later.
5. What happens in the first two weeks?
The best answer is a paid discovery: workshops with your users, a review of existing systems and data, an architecture decision and a working prototype. You learn whether the agency understands your business before you commit to the whole build.
6. How often will we see working software?
Every two weeks at most, on a real environment you can click through. Status reports and burn-down charts are not a substitute for software you can use.
7. How do you handle changes in scope?
Scope always changes once users see the product. Good agencies fix time and budget per cycle and let you reprioritise what goes into the next one, rather than raising change requests for every new idea.
Quality and risk
8. How do you test, and when do tests run?
Automated tests should run on every change in continuous integration, and nothing should reach production without passing them. Ask to see a test report from a current project.
9. How do you handle security and UK GDPR?
Listen for specifics: dependency updates, secrets kept out of the code, least-privilege access, personal data minimised and logged, and an independent penetration test before launch when the data is sensitive.
10. How do you approach accessibility and performance?
If you serve the public sector, WCAG 2.2 AA is a requirement, not a nice-to-have. For everyone else, Core Web Vitals affect search rankings and conversion. Both are far cheaper to build in than to bolt on later.
Ownership and exit
11. Who owns the code, the repository and the hosting?
You should, from the first commit. The repository should sit in your organisation and the cloud accounts should be in your name, with the agency invited as a guest. Anything else is lock-in.
12. What happens if we part ways?
A confident agency has a clear answer: a short notice period, documentation and runbooks kept up to date as they go, and a handover to your team or another supplier. If this question makes them uncomfortable, take note.
Red flags
| Red flag | Why it matters |
|---|---|
| A fixed price for a complex build from a short brief | The risk is priced in or pushed back on you |
| No access to the code until the end | You cannot check progress or quality |
| The team you meet is not the team who builds | Seniority drops after the contract is signed |
| Hosting only on the agency's own servers | Moving away becomes expensive |
| No automated tests or CI | Every change risks breaking something else |
| Vague answers about who owns what | Disputes later are slow and costly |
Agency, freelancer or in-house?
An agency is not always the right answer. A single well-defined task may suit a freelancer, and a long-lived core product eventually needs an in-house team. We compare the three, with real UK costs, in in-house, freelancer or agency?
Shortlisting agencies for a Django project? We are happy to answer all twelve questions on a 30-minute call, with no obligation. Send us a brief or get a cost estimate first.
Questions
How many agencies should I speak to?
Three is usually enough. More than five and the comparison becomes about price alone, which is rarely what decides whether a project succeeds.
Should I pick a specialist Django agency or a generalist?
If Django is central to your product, a specialist will move faster and avoid common mistakes. Generalists suit projects where the framework is not decided yet.
Does an agency need to be in the UK?
Not necessarily, but working-hours overlap, UK GDPR knowledge and familiarity with UK procurement make a real difference, especially for public-sector and regulated work.