Can Feedspace be vibe coded?
Collects text, video and audio reviews, imports existing ones, embeds them anywhere
The form, the queue, the wall and the embed widget are a focused implementation, as the two tools here show. What is not: 150+ sources with 120+ on auto-sync, on an extraction engine Feedspace owns in-house, and widgets that fill themselves from curation rules. Only collecting written reviews through your own form? Build it. Want the ones you have elsewhere kept current? Don't.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
medium editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- A public form collects a written, video or audio review, you approve it, and saved filters decide which approved reviews appear on each embeddable widget and hosted wall page.
- Collect, moderate, and embed short customer quotes with consent.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- 150+ review sources with 120+ on auto-sync, on an extraction engine Feedspace owns and runs in-house
- the upkeep · sources change and keeping the fetching working is someone else's job
- rule-based curation · matching new reviews join a widget or wall page by themselves, so the embed never goes stale
- in-browser video and audio recording that works on mobile without an app, and the media pipeline behind it
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- Reliability at the vendor's scale is an operations problem, not a prompt.
Build, switch, or keep paying
Narrower, with trade-offs
A public form collects a written, video or audio review, you approve it, and saved filters decide which approved reviews appear on each embeddable widget and hosted wall page.
Use the build brief ↓1 checked option
- Shosay ↗Unlimited text, video and audio proof, imports, walls and 25-plus widgets; the bill is zero, the tiny Powered by pill is not.
$29/mo
Because the hand-built version decays. A wall you assemble yourself is accurate the week you build it and stale three months later, the newest review sitting in an inbox nobody pasted from. Here neither end stays manual: reviews arrive on their own, rules decide what reaches the widget. Rebuilding it means owning the fetching, not just the form.
Visit Feedspace ↗Why people still pay
Because the hand-built version decays. A wall you assemble yourself is accurate the week you build it and stale three months later, the newest review sitting in an inbox nobody pasted from. Here neither end stays manual: reviews arrive on their own, rules decide what reaches the widget. Rebuilding it means owning the fetching, not just the form.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
Reliability at the vendor's scale is an operations problem, not a prompt.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Feedspace
Context
Feedspace — Collects text, video and audio reviews, imports existing ones, embeds them anywhere. It currently costs $29/mo.
The form, the queue, the wall and the embed widget are a focused implementation, as the two tools here show. What is not: 150+ sources with 120+ on auto-sync, on an extraction engine Feedspace owns in-house, and widgets that fill themselves from curation rules. Only collecting written reviews through your own form? Build it. Want the ones you have elsewhere kept current? Don't.
This brief describes a focused, single-operator replacement for the part of Feedspace that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
A public form collects a written, video or audio review, you approve it, and saved filters decide which approved reviews appear on each embeddable widget and hosted wall page.
Collect, moderate, and embed short customer quotes with consent.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
A small always-on host.
Somewhere to keep uploaded video and audio.
Ffmpeg to convert recordings into a web-playable file.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
Build me a testimonial system for my own site where the wall keeps itself up to date. Requirements:
Python 3 with FastAPI, SQLite via sqlite3, Jinja2 for server-rendered HTML, and local disk for
uploads. Single process, no Docker, no signup flow, no tenants. It serves one site: mine.
Collection page: a shareable link taking a star rating, a written quote, and optionally a video
or audio take recorded in the browser. Ask for name, role, company and a photo, let me mark which
of those are required, and stop recordings at three minutes.
Re-encode recordings to MP4 with a thumbnail in a worker off the request path, keeping the
original. If ffmpeg is absent, store the upload and flag it rather than failing the submission.
Moderation screen at /inbox behind an .env password: newest first, approve or bin, plus free-text
labels I can attach to a review.
Now the part I actually care about. A display is either a hand-picked list or a saved filter. A
filter can require a minimum rating, a media type, a photo on the reviewer, a job title, a named
company, one of my labels, a phrase that must appear, and a phrase that must not.
When a review is approved, every filter it satisfies picks it up immediately, with no republish
step. Each display shows whether it is filtered or hand-picked and how many reviews it resolves to.
Let me override a filtered display by pinning up to three reviews to the front of it.
Embedding: a one-line script tag plus an empty div. Attach a shadow root and inject markup the
server already rendered, so the host theme cannot restyle it and the quotes sit in the response.
Three presentations: a masonry grid, a swipeable row, and a slow vertical ticker. Theme, accent
and radius come off data- attributes.
A standalone wall at /wall with my logo, a call to action, and Review plus AggregateRating
structured data emitted from the same query that renders the cards.
A score badge: rounded average and total count, recalculated whenever a review is approved or removed.
Public endpoints get a per-IP throttle and an invisible decoy field, since anything with a form
attracts bots.
README covering the embed snippet, the .env keys, and running it behind nginx with a TLS cert.
Not building: fetching reviews I already have on Google, Trustpilot, G2, Yelp or an app store, or
polling them for new ones. That is a parser per platform plus someone maintaining them, which is
not a focused implementation. Teammates and outbound review-request email are out too.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
150+ review sources with 120+ on auto-sync, on an extraction engine Feedspace owns and runs in-house.
The upkeep · sources change and keeping the fetching working is someone else's job.
Rule-based curation · matching new reviews join a widget or wall page by themselves, so the embed never goes stale.
In-browser video and audio recording that works on mobile without an app, and the media pipeline behind it.
Aggregate rating badges that stay accurate because the auto-syncs keep feeding them.
What you still own after launch
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Maintain every third-party integration as APIs and OAuth rules change.
Risk
Operational risk. The code is achievable; dependable data, integrations, and ongoing operations are the real cost.
Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.
Existing alternatives
Before building, compare these checked options:
Shosay — Unlimited text, video and audio proof, imports, walls and 25-plus widgets; the bill is zero, the tiny Powered by pill is not
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/feedspace
You still own the product
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.
Projects built from this idea
No reviewed implementation has been linked for Feedspace yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Feedspace?Submit the project as evidence for this report.
Before you start
Can Feedspace be vibe coded?
Partly, if you narrow it. The form, the queue, the wall and the embed widget are a focused implementation, as the two tools here show. What is not: 150+ sources with 120+ on auto-sync, on an extraction engine Feedspace owns in-house, and widgets that fill themselves from curation rules. Only collecting written reviews through your own form? Build it. Want the ones you have elsewhere kept current? Don't.
What can an AI coding agent reproduce from Feedspace?
A public form collects a written, video or audio review, you approve it, and saved filters decide which approved reviews appear on each embeddable widget and hosted wall page. Collect, moderate, and embed short customer quotes with consent. A responsive interface with real empty, loading, success, and error states.
What will a DIY Feedspace replacement still be missing?
150+ review sources with 120+ on auto-sync, on an extraction engine Feedspace owns and runs in-house; the upkeep · sources change and keeping the fetching working is someone else's job; rule-based curation · matching new reviews join a widget or wall page by themselves, so the embed never goes stale; in-browser video and audio recording that works on mobile without an app, and the media pipeline behind it; Connectors, OAuth flows, and vendor API changes require constant upkeep.; Reliability at the vendor's scale is an operations problem, not a prompt.
What do I still own after building a Feedspace alternative?
Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss. Maintain every third-party integration as APIs and OAuth rules change.