Project case study
Resource Generator
A personal Django and Bootstrap utility created to make software demo preparation faster, more realistic and easier to repeat.
The Resource Generator is a project built to make software demos easier to prepare, repeat and maintain.
In transport management software, a good demo depends on realistic data. The screens, workflows and product capability all matter, but the demo only feels credible when the underlying data looks like something an operator, planner, administrator or customer would actually recognise.
Creating that data manually is time-consuming. It is also easy to make it inconsistent, incomplete or obviously artificial.
The Resource Generator was built to reduce that friction.
It helps generate realistic demo resources quickly, so that product demonstrations can focus on the value of the software rather than the manual preparation of test data.
Why I Built It
Product demonstrations often need believable examples of operational setup data.
That may include resources such as:
- Drivers
- Tractor units
- locations
- trailers
For a demo to work well, this information needs to be coherent. The data does not need to represent a real customer, but it does need to feel operationally plausible.
Poor demo data creates several problems:
- The demo feels artificial
- The user journey becomes harder to explain
- Screens look empty or unfinished
- Workflows do not join together properly
- The conversation shifts away from product value
- Time is wasted manually fixing setup issues
The Resource Generator was created to make demo preparation more repeatable and less dependent on manual spreadsheet work.
What It Generates
The tool creates realistic demo resource data, including:
- Realistic driver names
- Tractor registration numbers
- Demo-safe phone numbers
- Locations with the correct latitudes and longitudes derived from the lat and long
- Resource records suitable for demo scenarios
The phone numbers are deliberately generated using reserved number ranges commonly used for television, film and other fictional examples. This avoids accidentally using real personal phone numbers while still making the demo data look realistic. The lats and longs are calculated from the postcode ensuring that any maps display correctly That matters because demo data should feel credible, but it should never expose real customer, employee or personal information.
Project Purpose
The purpose of the project is simple:
Make it easier to create realistic demo resources for transport software scenarios.
This is not a production implementation tool. It is not intended to expose commercially sensitive system design. It is not a replacement for a live customer setup process.
It is a personal utility for creating demo-friendly data that supports better storytelling, better product walkthroughs and faster preparation.
What It Helps With
The Resource Generator supports the preparation of consistent demo data by helping create structured resource records that can be used in demonstration environments.
It is useful when preparing demos for:
- New product functionality
- Operational setup walkthroughs
- Customer-facing product conversations
- Training-style demonstrations
The main benefit is speed and consistency. Instead of rebuilding demo data manually each time, the tool helps create a more repeatable starting point.
Technology Stack
The project is built using:
| Area | Technology |
|---|---|
| Backend | Django |
| Front end | Bootstrap |
| Data preparation | Structured form and spreadsheet-driven inputs |
| Output style | Reviewable demo-ready resource data |
The stack was chosen deliberately.
Django is a strong fit for this type of project because it allows a working data-driven application to be built quickly without unnecessary overhead. It provides routing, forms, data modelling, validation patterns and admin capability out of the box. That makes it well suited to small internal-style tools where the value is in the workflow, not in building infrastructure from scratch. Python was used because of the Pandas library which is ideal for dealing with large volumes of tabular data
Bootstrap was used for the front end because the interface does not need to be visually complex. It needs to be clear, usable and quick to extend.
The aim was not to create a large product platform. The aim was to build a useful, maintainable utility while also giving me more practical experience developing with Django.
Why Django Was the Right Choice
This was also a personal development decision.
Most of my recent development work has focused on backend systems, product tooling and transport software concepts. Building this utility in Django gave me a practical reason to deepen my experience with a different web framework while still solving a real problem.
Django was useful because it allowed me to:
- Build a working web application quickly
- Focus on the demo preparation workflow
- Use a structured backend without excessive boilerplate
- Keep the project simple enough for personal development
- Create forms and outputs without over-engineering the front end
- Learn by building something with practical value
For a personal utility, Django gives a good balance between speed, structure and maintainability.
Process Overview
flowchart LR
A[Demo Scenario] --> B[Enter or Upload Resource Inputs]
B --> C[Generate Demo Resources]
C --> D[Review Output]
D --> E[Use in Demo Environment]
The process is intentionally straightforward.
The user starts with a demo scenario, enters or uploads the required resource information, generates the data, reviews it, and then uses it to support the demonstration.
Why Demo Data Matters
Demo data is often underestimated.
A product demo is not just a tour of screens. It is a narrative. The data needs to support that narrative.
For example, if a demo is showing depot planning, then the supporting resources need to look like they belong to a depot. If the demo is showing vehicle allocation, the vehicles and drivers need to make sense. If the demo is showing shift-based working, the shift information needs to feel realistic enough for the audience to trust the example.
Good demo data helps the audience understand:
- What problem the software solves
- How the workflow fits together
- Why the feature matters
- How the product would work in a real operation
- What value the user would get from the process
The Resource Generator exists to support that.
Realistic but Safe Data
A key design principle is that the generated data should be realistic, but not real.
That means the tool can create names, vehicle registrations and contact details that make a demo feel more credible, while avoiding the use of live operational or personal information.
flowchart TD
A[Need Demo Data] --> B[Generate Driver Names]
A --> C[Generate Tractors]
A --> D[Generate Trailers]
A --> E[Generate Locations]
B --> F[Credible Demo Resource Set]
C --> F
D --> F
E --> F
F --> G[Use in Product Demonstration]
The distinction is important.
Using real customer or employee data in demos creates unnecessary risk. Using obviously fake data can make the demonstration feel weak. The Resource Generator sits between those two extremes.
It creates data that looks operationally credible without relying on sensitive real-world records.
Product Thinking
This project came from a practical product management problem.
Preparing demos can involve a lot of hidden work. The visible part is the presentation, but the invisible part is the setup: creating believable resources, making sure the data joins together and ensuring the scenario does not fall apart halfway through the walkthrough.
The product thinking behind the tool was based on a few simple questions:
- What preparation work is repeated?
- Which parts of demo setup slow things down?
- Where does poor data make a demo less convincing?
- What can be standardised safely?
- What should remain flexible?
- How can the process be made faster without exposing sensitive design details?
The result is a focused utility that supports demo preparation without trying to become a wider implementation or project management platform.
Scope Control
The Resource Generator deliberately avoids becoming too broad.
It is not designed to manage every aspect of a demo. It does not replace product knowledge, customer discovery or good storytelling.
Its role is narrower:
Generate useful, realistic supporting resource data so that demos are easier to prepare.
That boundary is important.
The tool should support the demo process, not become the demo process.
Example Use Case
A product manager needs to demonstrate a planning workflow.
To make the demo credible, they need a set of supporting resources. These may include drivers, tractor units, shifts and depot references.
Without a tool, this data may be created manually, copied from old examples or built inconsistently across different demos.
With the Resource Generator, the same type of data can be generated more quickly and reviewed before use.
flowchart TD
A[Need to Demo Planning] --> B[Define Demo Scenario]
B --> C[Generate Data]
C --> D[Review Demo Data]
D --> E[Load data]
E --> F[Run Demo]
The value is not just that the data is generated faster. The value is that the demo becomes easier to prepare, easier to repeat and easier to explain.
Commercial Sensitivity
This project description intentionally avoids detailed implementation logic, internal data structures and system-specific design rules.
The purpose of the portfolio entry is to explain the product problem and the reasoning behind the utility, not to expose commercially sensitive information.
The key point is the product outcome:
Better demo preparation through faster, safer and more consistent creation of realistic resource data.
Trade-offs
Practicality over complexity
The project favours a simple Django and Bootstrap approach rather than a complex architecture.
That keeps the tool easy to understand, quick to change and appropriate for its purpose.
For a personal utility, simplicity is a strength.
Realistic, not real
The generated data is intended to be realistic enough for demonstration purposes. It is not intended to represent real customer data.
That distinction matters.
Demo data needs to feel credible, but it should avoid exposing live operational details or sensitive customer information.
Using reserved fictional phone number ranges is part of that approach. It allows the demo to look natural without creating privacy risk.
Flexible enough for different demos
Different demos need different narratives.
A rigid data generator would be less useful because product demos often need to be adapted for different audiences.
The Resource Generator therefore supports repeatability while still allowing the demo scenario to guide the final data.
Current Status
The current version is a working personal utility focused on supporting software demo preparation.
It provides a structured way to create realistic resource data and reduce the manual effort required before a demo.
The front end is intentionally simple, using Bootstrap to provide a clear and usable interface without unnecessary design overhead.
Future Improvements
Future improvements are possible, for example automatically generating orders , however at the moment this is not needed.
Outcome
The Resource Generator demonstrates a practical product management principle:
Good software demonstrations depend on good preparation.
The project reduces the time and effort needed to prepare realistic demo data. It helps make product walkthroughs more consistent, more credible and easier to repeat.
It also shows an important product skill: identifying a repeated operational pain point and building a focused tool to remove friction.
The value is not in exposing complex technical detail. The value is in recognising that demo preparation is a real workflow, and that improving that workflow can improve the quality of product conversations.
Summary
The Resource Generator is a personal Django and Bootstrap project designed to make software demo preparation easier.
It helps create realistic supporting resource data for transport software demonstrations, including driver names, tractor registrations and demo-safe phone numbers.
The project is intentionally focused, commercially safe and practical. It does not expose sensitive design details or attempt to become a full implementation platform.
Its purpose is simple:
Make better demos easier to prepare.