Why Django suits internal tools
Internal systems need users, roles, permissions, forms, an administrative interface and reporting. Django provides all of them conventionally, which means the project starts from the business logic rather than from the plumbing.
For an internal tool, the admin interface alone frequently saves several weeks of building screens that would be used twice a month.
What we typically build
- Job and project tracking shaped around your actual stages
- Approval workflows matching your real authority levels
- Scheduling that understands your constraints
- Quoting tools with your pricing rules encoded
- Operational reporting that produces the numbers people use
Build the smallest useful version
The most common mistake in internal tools is building everything anyone mentioned. The version people actually use is usually a fraction of the original specification.
Build what the process requires today, get it in front of the people doing the job, and extend from what they tell you.
It has to be faster than the spreadsheet
- Fewer clicks than what it replaces
- Keyboard-usable for anything done repeatedly
- Sensible defaults so common cases are quick
- No mandatory fields that are usually empty
- Fast enough not to interrupt the flow of work
An internal tool competes with a spreadsheet people already know. If it is slower, it will not be adopted regardless of its other merits.
The economics
| Per-seat product | Custom tool | |
|---|---|---|
| Initial | Low | £8,000–£30,000 |
| Per user | Ongoing forever | None |
| Fit to process | Approximate | Exact |
| Changes when you change | Wait for the vendor | When you need |
| Maintenance | Included | 15–25% annually |
At twenty users on a per-seat product, custom frequently pays for itself within two to three years, before counting the process fit.