I identified the most common friction points in a UE5 developer's workflow and build tools that eliminate them.
To inform this, I ran a developer survey distributed through LinkedIn, gathering responses from developers across different specialisms and experience levels. The survey focused on recurring pain points, time-consuming tasks and gaps in existing tooling across areas like asset management, UI setup, character prototyping and more.
The results directly shaped the tool selection, each category in the library maps back to problems real developers identiifed. This meant every tool had a validated reason to exist before a single line of code was written.
Every plugin in the library follows the same two-phase development process:
Phase 1 - Blueprint Prototype
Each tool was first built using Unreal's Editor Utility Widget system. This allowed me to validate the logic, UX and feature set quickly before committing to a C++ implementation.
Phase 2 - C++ Port
Once the Blueprint prototype was validated, the core logic was ported to C++ for performance, reliability and access to APIs not exposed to Blueprints such as UMaterialEditingLibrary for material generation and the content browser API for asset reading.
This approach meant every tool was tested and user-validated before any C++ work began, keeping the development process efficient and the output reliable.
Every plugin is built around a strict set of architectural rules:
Self-contained ✦
No cross-plugin dependencies, each tool installs and runs independently
No unused assets shipped ✦
Only what the end user needs is included in the plugin
Subsystem-based where applicable ✦
GameInstanceSubsystems used over manual Project Settings
configuraiton for automatic registration
Abstract base classes ✦
Shared behaviour defined in C++ base classes, keeping generated assets clean and extensible
These decisions were deliberate and informed by how professional plugin development works in the industry.
Blueprint API limitations
Several features I needed were simply not exposed to Blueprints appropraitely, most notably UMaterialEditingLibrary for Auto Material Setup and the content browser asset reading API. Hitting these walls pushed me to deepen my C++ knowledge and understand where Blueprint ends and C++ begins in a real pipeline.
Self-contained architecture
Keeping every plugin truly self-contained required constant discipline: no shared assets, no cross-references, no assumptions about the user's project structure. Every tool had to work in complete isolation.
Scope management
Building 10 tools to a professional standard solo required rigorous planning. Each tool was scoped, documented and developed in phases with clear milestones to keep the project on track across the full development period.
✦ Where and why to move from Blueprint to C++ in a real development context
✦ How to design developer-facing tools with UX in mind, not just functionality
✦ Plugin architecture patterns used in professional UE5 development
✦ How to scope and manage a large solo technical project from brief to delivery
✦ The importance of self-contained, dependency-free design in distributed tools