Akteora started with a small, annoying problem: getting a short video from a happy client is much harder than it should be. This is how we built a tool to fix that with a very small team, and the handful of decisions that mattered most.
The problem we wanted to solve
Asking someone to record a video is awkward. If they say yes, they have to find a quiet moment, record it, work out how to send a large file, and you have to chase them. Most of the time it never happens. When it does, the raw clip sits in a folder because nobody has time to edit it.
So the product had to be simple from the customer’s side:
- The business sends one link.
- The customer opens it on their phone and records video, voice or text. No app, no account.
- The business approves it, shows it on their website and turns the best ones into short captioned clips.
Everything below follows from keeping that loop short.
1. We wrote it down before writing code
Before the first line of code there was an architecture document and a set of decision records, each explaining one big choice and why we made it. Then the whole product was split into about twenty small work orders, each with a clear goal and a list of what “done” means.
This sounds slow. It was the opposite. When a question came up halfway through a feature, the answer was usually already written down, so we did not have to decide the same thing twice.
2. AI types, people decide
Most of Akteora’s code was written with an AI coding assistant. But the assistant never chose the architecture. It got one work order at a time, every change was reviewed, and nothing was merged until the tests, the type checks and the build passed.
AI made typing cheap. It did not make decisions cheap. The written decisions and the tests are what kept the codebase consistent as it grew.
3. Boring infrastructure
Akteora runs on one server with Docker, PostgreSQL and Redis. No Kubernetes, no microservices. It is one application split into clear modules, plus a separate worker for slow jobs like processing video.
For a small team, the real risk is not “it couldn’t scale”. It is “month eight and still not shipped”. A single server is easy to understand, cheap to run and easy to back up, and the modules can be split out later if they ever need to be.
4. Video never touches our servers
Video is the expensive part of a testimonial tool, so we designed around it from day one. The recording page uploads straight from the customer’s browser to storage, in small pieces, while they are still talking. By the time they press stop, most of the file has already arrived.
Our API only signs the upload and records that it finished, a couple of tiny requests per video however large the file is. Finished videos are served from a CDN, not from our servers either.
5. The recording page has a strict budget
The page a customer opens is the one place where speed decides whether a testimonial exists at all. Someone tapping a link on a phone will not wait.
So that page is built and deployed on its own, with a hard limit of 40 KB of compressed JavaScript. Today it is about 24 KB. It cannot import anything from the dashboard, any UI framework beyond a tiny one, or any analytics script, and the build fails if it grows past the limit.
6. The website widget is a file, not a server
When a business shows testimonials on their site, every visitor would normally call our API. Instead, each widget is published as a small static file on a CDN, rebuilt a few seconds after anything in it changes.
A customer’s page can get a burst of traffic and it costs our servers nothing. If our API is down for maintenance, their widget keeps working.
7. Trust is built into the data, not a policy page
Testimonials are only worth something if they are real, and in the US the FTC’s rule on reviews and testimonials now bans fake and AI-written ones. So the rules are part of how data is stored:
- Original recordings and words are never edited or overwritten.
- The consent the customer agreed to is saved word for word with their testimonial.
- An audit log records what happened to each testimonial, and it can only be added to.
- The AI that makes highlight reels picks moments. It never writes words.
We wrote a separate post about that last one: why our AI is not allowed to write.
What we would tell another small team
- Check your payment provider before you build billing. We rebuilt our billing once because the first provider we planned around did not approve the account. The provider shapes your webhooks, pricing page and subscriptions, so confirm it first.
- Describe your product precisely. Payment providers and app stores treat “software that does X” very differently from “a service that does X for you”.
- Give the slowest, most fragile path the most attention. For us that was a customer on a phone with a weak connection. Everything else can be a little slower.
- Ship before it feels finished. A free product with real users teaches you more than another month of building.
Where Akteora is now
Akteora is live. You can collect video, voice and text testimonials with one link, approve them, show them on your website with a widget or a public page, export them, and build captioned reels. There is a free plan and a public API for anyone who wants to build on top of it.
If testimonials matter to your business, try it free and tell us what is missing. Or read how to get video testimonials from customers who hate cameras.