D&D Homebrew Subclass Creation Part 3: Creating the Subclass
- Apr 24
- 4 min read
Updated: 5 days ago

You have your D&D homebrew subclass theme.
You picked the base class.
Now it is finally time to create the abilities.
Whether you are designing for 2014 D&D 5e or the 2024 rules, my approach is basically the same:
Make the ability fun first. Then figure out how to make it work.
My 3-Step Homebrew Subclass Process
Find the theme
Choose the right class
Create and balance the features ← You are here
Start With the Base Class
Before creating abilities, I look at what the class already gives me.
For example:
Bard: Bardic Inspiration, skills, spellcasting
Monk: Ki Points in 2014 / Focus Points in 2024, Martial Arts, movement
Fighter: Action Surge, attacks, durability
Then I ask:
How can my subclass make those mechanics more interesting?
I would rather use a resource the player already tracks than give them another pile of charges to remember.
That is why my Talisman Monk uses the Monk's existing resource instead of something like "Talisman Charges."
Create the Fun Part First
I normally start with what sounds fun.
Then I worry about the numbers.
For example, my Otaku Bard can eventually perform what is basically a giant anime energy attack dealing 14d6 damage.
Is that ridiculous?
Yes.
And that is kind of the point.
At that level, I want abilities to feel huge.
But once I created it, I had to balance it. So using that attack also comes with exhaustion.
The fun idea came first. The restriction came second.
Compare It to Official D&D Abilities
Once I have the idea, I start checking numbers.
The first things I usually look at are:
Damage
Number of uses
How many creatures it affects
Resource cost
Similar official abilities
I learned this while creating my Monstrosity Barbarian.
One version gained dragon-related powers that could be used three times the character's proficiency bonus.
Then I looked at official classes.
They were not giving players nearly that many uses.
So I reduced it.
Sometimes you do not realize something is too strong until you compare it against what already exists.
Powerful Is Fine. Annoying Is Not.
Something can be balanced and still be frustrating to use.
I once created a Fighter with a burn effect.
The problem was not necessarily the damage.
The problem was tracking it.
When does the burn happen again?
How long does it last?
Which enemies are still burning?
How much damage does each one take?
It quickly became annoying.
That taught me that balance is not just about numbers.
The DM and player also need to be able to actually run the ability.
If Nobody Uses It, It Is Not a Good Feature
I have also created abilities that sounded fine but nobody cared about.
My Commander Fighter had an ability where their intimidation could gain advantage if their Strength was higher than the target's.
It worked.
My players just did not care.
That matters.
A feature can be perfectly balanced and still be boring.
If nobody wants to use it, I need to rethink it.
Do Not Forget Non-Combat Features
I actually like designing non-combat features because they are often simple and surprisingly useful.
Things like:
Advantage on Performance checks
Gaining proficiency in a skill
Tool proficiencies
Exploration bonuses
Social advantages
Not everything needs to explode.
Sometimes a small ability gives players more opportunities to interact with the campaign than another combat attack would.
Example: My Otaku Bard
The Otaku Bard is one of my favorite examples because I intentionally hurt something Bards are normally great at.
They lose proficiency with many Charisma-based skills.
That sounds terrible for a Bard.
But in exchange, they can use Charisma for certain Strength- and Dexterity-based checks.
That supports the theme:
They are socially awkward, but their obsessive knowledge lets them imitate the heroes they love.
That is what I want a subclass feature to do.
Change how the class plays while still supporting the fantasy.
Complicated Themes Create Complicated Features
My Toon Bard was difficult for exactly this reason.
The idea was:
What can an immortal cartoon character actually do?
That question opens up way too many possibilities.
Eventually I created an ability where, after failing a saving throw, they could use Bardic Inspiration and potentially redirect damage.
Getting there took a lot of work because the theme itself was so broad.
That reinforced one of my biggest rules:
If a feature is longer than a paragraph or needs too many limits, I probably need to simplify it.
Higher-Level Abilities Should Feel Insane
At high levels, I want subclass abilities to feel powerful.
The player worked hard to get there.
Let them do something ridiculous.
Fight gods.
Fire the giant anime beam.
Control the battlefield.
Do something they could never do at level 3.
But there is still one limit:
Your subclass feature should not overshadow the base class's level-20 identity.
Big is good.
Replacing the entire class is not.
Quick Test: Is Your Homebrew Feature Ready?
Before I keep an ability, I ask:
Is it fun?
Would I actually want to use this?
Does it fit the theme?
Every ability should reinforce the subclass fantasy.
Does it work with the base class?
Do not fight against the character's normal abilities.
Is it easy to track?
Ongoing effects and extra resources can become annoying fast.
Would players actually use it?
Balanced does not automatically mean interesting.
Is it longer than a paragraph?
If yes, I start looking for ways to simplify it.
How does it compare to official subclasses?
Check damage, uses, targets, and resources.
Then Playtest It
You will not catch everything while writing.
Something that looks incredible on paper may never get used.
Something that looks reasonable may become absurd at the table.
So:
Build it.
Play it.
Change it.
That is part of homebrew.
The Full D&D Homebrew Subclass Process
Step 1: Find the fantasy.
Step 2: Find the class whose mechanics support it.
Step 3: Create fun features, compare them to official designs, and simplify them until they work at the table.
That is the process I use when creating my own D&D homebrew subclasses.


Comments