A partner brought us a problem. We ended up building a product.
Squeeze Reviews started as a question from Brandon Bornancin, founder of Seamless.AI. It ended as software we own, operate, and sell.
This is how that happened, and what was hard about it.
The question
Brandon Bornancin came to us with something that sounded like a marketing problem and turned out to be an engineering one.
A business collects proof from its customers for years. Testimonials, ratings, recommendations. Almost none of it belongs to the business. It lives on someone else’s platform, under someone else’s rules, rendered by someone else’s template. The business cannot move it, cannot own it, and cannot put it on its own site.
The proof exists. The business just doesn’t hold it.
That is not a content problem. That is a systems problem, and systems problems are what we do.
What we built
Squeeze Reviews collects video testimonials and publishes them on the customer’s own website.
A collect link, and nothing to install. A business sends a link. Their customer opens it on a phone, records a video, and submits. No app, no account, no signup. The reviewer never creates a login, and the product is designed around the fact that they never will.
The owner approves, and approval publishes. Nothing appears anywhere until the business owner has seen it and said yes. One action, one state change, one consequence — because a moderation flow with two meanings is a moderation flow nobody trusts.
An embed the business owns. Approved reviews render on the business’s own site through a widget they paste in once. The videos sit on their page, under their domain, inside their design. If they leave us, the proof is still theirs.
Transcription and search, because video is hard to skim. Every submission is transcribed. A wall of video is impressive and useless; a wall of video you can read through is an asset.
The part that’s harder than it looks
The reviewer is anonymous, and that decision reaches all the way down.
Asking a customer to create an account before recording a testimonial loses most of them. So we didn’t. The person recording a review is signed in anonymously, holds no account, and will never come back.
That single product decision propagates into every layer underneath it.
Security rules have to distinguish a first write from a second one. An anonymous stranger must be able to create a review and must never be able to touch one that already exists. Those are not the same permission, and in Firestore they are not as far apart as they look — writing a document with a known id onto a document that already exists counts as an update, not a create. A retry after a dropped connection is indistinguishable from an edit unless the rules are written to tell them apart.
A lost acknowledgement is not a lost review. Phones lose signal mid-upload. The write lands; the confirmation never arrives; the reviewer sees a failure and records the whole thing again. We treat a retry as a question rather than a write: the client asks the server whether the submission already landed, and the server answers from the record instead of guessing. A reviewer who succeeded is told they succeeded.
The published set is a real set, and it has to stay one. A review can be approved, then unapproved. It can be deleted. The widget on a customer’s site reads from one place, and every path that changes a review’s status has to keep that place correct. Getting the happy path right takes an afternoon. Making sure no path anywhere can leave a stale id behind is the actual work, and it is the part a customer would notice.
We store the original and serve the copy. Every upload is transcoded into a smaller version for playback. The original is kept. Storage is cheap; a re-encode you cannot perform because you deleted the source is not.
How we think about proof
A product about credibility has to be careful about the claims it makes for itself.
Squeeze Reviews records who submitted a review and when. It does not claim to have independently verified that person’s identity, and it never presents a collected review as anything more than what it is. That distinction is enforced in the code, not in the marketing.
We took the same position on our own language. Where earlier copy implied a level of validation the system didn’t perform, we removed it — before anyone asked.
If a product’s whole value is that people believe what they see on it, the fastest way to destroy it is to overstate one thing once.
Where it is now
Squeeze Reviews is live and in production. It runs on Next.js and Firebase, with a public marketplace, an embeddable widget, and a Managing Partner directory.
We use it ourselves, across our own businesses, which means we find things before customers do.
See Squeeze Reviews →The pattern
Brandon didn’t ask us to build a product. He asked a good question about something that was bothering him.
That’s usually where the work starts. A partner describes a problem in the language of their business, and somewhere underneath it there’s a system that doesn’t exist yet.