Introduction
I work as a Software Architect and Technical Instructor, and a big part of my job is explaining technical concepts to other people.
Architecture diagrams. Code. Software demos. APIs. System behavior.
While presenting on a Mac, I often find myself needing to do things like:
- Draw directly on top of a slide, browser, or IDE
- Point out exactly where people should look
- Sketch a diagram when the prepared slides aren't enough
- Bring an existing image or PDF into the explanation
- Keep what I created and reuse it in another session
There are already great tools that solve each of these problems individually.
But during an actual technical session, I don't want to think about which tool I need next.
I want to stay in the explanation.
The problem wasn't the lack of annotation tools. It was the interruption of the explanation flow.
That's one of the reasons I started building a Mac app called TeacherPalette.
Rather than simply introducing the app, I wanted to share the problem I was trying to solve and why I designed the workflow this way.
First, here's TeacherPalette in 30 seconds
I recently made a short preview showing the current experience:
https://www.youtube.com/watch?v=IlkBNHuxX_A
There are no subtitles or narration.
It starts with drawing directly on screen, moves into tools for guiding attention, expands into a Whiteboard, and then brings existing images and PDFs into the same explanation flow.
The individual features matter, but connecting them is what I care about more.
1. Draw directly on any screen
Prepared slides rarely contain everything I need during a technical session.
Imagine I'm showing an architecture diagram and saying:
The request enters here.
Only this part is asynchronous.
These two components communicate with each other.
Sometimes adding an arrow or highlighting a component is much faster than trying to explain its position verbally.
TeacherPalette therefore lets me draw over almost anything displayed on my Mac using tools such as Pen, Highlighter, Arrow, and Shapes.
That could be a presentation, browser, IDE, online meeting, diagram, or software demo.
The thing I'm already showing becomes the canvas.
2. Guide attention without drawing everywhere
Drawing isn't always the right answer.
During a software demo, for example, I may simply want everyone to look at one button without leaving permanent marks all over the interface.
So I added another set of tools:
- Spotlight
- Laser Pointer
- Magnifier
- Cursor Highlight
- Click Highlight
Magnifier was particularly important to me.
Instead of zooming the entire display, it enlarges only the area I want to show while preserving the surrounding context.
That can be useful when explaining a dense UI, a small piece of code, or a complex architecture diagram.
The goal isn't to add visual effects for their own sake.
Each tool should answer the same question:
How can I make it immediately obvious where the audience should look?
3. When the slide isn't enough, move to a Whiteboard
At some point during a technical explanation, I often say something like:
This might be easier if I draw it.
That's where the Whiteboard comes in.
TeacherPalette includes a multi-page Whiteboard where I can quickly sketch something like:
Client → API → Service → Database
and continue onto another page when I need more space.
But I didn't want the Whiteboard to be a temporary canvas that disappears after the session.
Whiteboards are saved so I can return to them later, continue working, or reuse something I created in another training session.
For me, that distinction is important.
A useful explanation shouldn't necessarily disappear when the meeting ends.
4. Bring existing material into the Whiteboard
I also don't want to recreate everything inside TeacherPalette.
Often I already have an architecture diagram, screenshot, or another piece of material that I want to discuss.
So images can be dragged and dropped directly into the Whiteboard.
From there I can:
- Highlight an important area
- Draw an arrow
- Add a note
- Continue the explanation around the existing material
The idea is simple:
Don't rebuild your material for the Whiteboard. Bring your material into the explanation.
5. Keep PDFs and Whiteboards in the same flow
PDFs are another common part of technical training.
Documentation, worksheets, specifications, training materials, and exported slide decks often arrive as PDFs.
TeacherPalette can import a PDF into the Whiteboard so I can work directly on its pages.
The workflow can then look like this:
My own Whiteboard
↓
Add an existing PDF
↓
Explain and annotate the PDF
↓
Return to my own Whiteboard
This is a small interaction, but it represents something important about the direction of the product.
I don't want using a Whiteboard and working with a PDF to feel like two completely separate activities.
They're both part of the same explanation.
Why put all of this into one app?
There are already excellent Mac apps for drawing on screen.
There are excellent Whiteboard apps.
There are PDF annotation tools.
So the problem I'm trying to solve with TeacherPalette isn't:
"How do I draw a line on my Mac screen?"
The problem I personally kept running into was:
Context switching while I'm trying to explain something.
Draw on the screen.
Guide attention.
Sketch something new.
Bring in existing material.
Explain a PDF.
Keep what I created.
Come back to it later.
Technically, these are separate features.
But from the perspective of someone teaching or presenting, they're often parts of one continuous activity.
That's why I think of TeacherPalette less as a screen annotation app and more as a presentation toolkit for people who explain things on their Mac.
I'm still building it — and I'd genuinely like feedback
TeacherPalette is an indie project, and I'm continuing to improve it after launch.
Feedback from early users has already influenced changes such as drag and drop in the Whiteboard, improvements to the PDF/Whiteboard workflow, and smaller UX refinements.
I'm also working on localization beyond simply translating the interface.
TeacherPalette currently supports nine languages, and I'm updating the App Store experience so screenshots and product messaging feel natural for users in markets such as Japan and Korea as well.
But the product itself is still evolving.
And that's one reason I wanted to share it here on DEV.
A lot of people here explain technical things regularly:
- Live coding
- Architecture reviews
- Product demos
- Developer workshops
- Online training
- Pair programming
- Conference talks
So I'd genuinely like to hear what you think.
If you try TeacherPalette and find something awkward, tell me.
If there's a feature you'd expect in a technical presentation workflow, tell me.
If something feels unnecessary, I'd like to hear that too.
"I wouldn't use this because..." is just as useful to me as "I like this."
As an indie developer, that kind of feedback can directly influence what I build next.
Giving 1% back to education
TeacherPalette grew out of my own experience teaching and explaining technology.
If the product grows, I'd like part of that success to go back into education.
That's why I've committed to donating 1% of TeacherPalette's profit to initiatives working to reduce educational inequality.
It's still a very small indie project.
But I'd like the relationship to be simple:
More people find TeacherPalette useful → TeacherPalette grows → a small part of that growth helps create learning opportunities for someone else.
It's a small commitment today, but one I want to maintain as the product grows.
Try TeacherPalette
🌐 Official website
https://teacherpalette.com/
🍎 Mac App Store
https://apps.apple.com/app/teacherpalette/id6783567350?mt=12
Eligible new subscribers can try all TeacherPalette features free for 7 days with a monthly or annual subscription.
If you give it a try, I'd really appreciate your feedback — either here in the comments or through TeacherPalette's website.
Thanks for reading.
Teach. Demo. Present. Create.
