I did not start out trying to build something impressive.
If I am being honest, I just wanted to build something that actually worked… without trying to squeeze money out of people for basic features.
I had used a few teleprompter apps before. Some were fine at first. Then slowly, things would disappear behind paywalls. Adjusting speed. Saving scripts. Even simple usability features. It just did not sit right with me.
So I decided to build one myself.
I did not realise how much work that would turn into.
It looked simple, until it wasn’t
At the beginning, the idea felt straightforward.
Display text. Scroll it. Add controls. Done.
But once I started building it properly, I realised a teleprompter is not just a UI problem. It is a timing problem. It is a reading problem.
If the scroll stutters, you lose rhythm.
If the speed feels off, you lose confidence.
That is when I knew I needed more than just a simple animation.
The architecture I chose
I built Cuevora using:
React + TypeScript
Vite
Capacitor (to extend to mobile)
The goal was simple: one core codebase across web and mobile.
The hardest part of this app was not platform specific UI. It was making sure the behaviour stayed consistent across devices. Using a single codebase made that much easier to manage.
Local-first by design
One decision I am really glad I made was keeping the app local-first.
No account required
No forced sign-in
Scripts and settings stored locally
This made the app immediately usable without friction.
Of course, this comes with trade-offs. Data can be cleared. There is no automatic sync. So I had to support things like backup and restore.
But for this type of product, it felt like the right trade-off.
The hardest part: the scroll engine
The most important part of Cuevora is the teleprompter itself.
I avoided simple CSS animations and instead built a scroll engine using requestAnimationFrame.
Each frame:
calculates time elapsed
converts speed into pixels per second
updates scroll position dynamically
This allowed:
smooth scrolling
real-time speed adjustments
better control over timing
It took some iteration, but this is the part that made the app feel reliable.
Thinking about real usage
Once the core worked, I started focusing on how people actually use a teleprompter.
That led to features like:
focus line for reading comfort
mirror mode for camera setups
countdown before scrolling starts
adjustable spacing and font size
These are small things, but they make a big difference when someone is using the app under pressure.
Multiple ways to interact
Not everyone uses apps the same way.
So Cuevora supports:
keyboard shortcuts
touch gestures
voice commands (where supported)
One lesson here was to respect platform limitations.
For example, voice recognition is not reliable everywhere, so I chose to disable it in some environments instead of forcing it.
Recording changed everything
Adding camera and recording support introduced new challenges.
Recording has different needs from reading:
permissions
media formats
file handling
So I separated it into its own mode.
That made both the code and the experience cleaner.
What I learned
This project changed how I think about building software.
It is not just about using modern tools.
It is about:
building something people can rely on
understanding real user situations
making deliberate trade-offs
Cuevora is not perfect. There is still more to improve.
But it was built with intention.
And for me, that matters.
Top comments (0)