¿Puedo vibecodear WishKit?

PARCIAL · un fin de semana
precio $15/mesahorrarías $180/añotiempo de build un fin de semanacategoría 🔬 investigación de usuarioreemplazada por 0 personas

The data model here is four tables and a sort function: wishes, votes, comments, statuses. An agent can produce the whole web board plus a REST API in a single sitting, and it will work fine for a side project. The part that is actually work is everything after that: a native in-app widget for each platform you ship on, anonymous device identity so the same user cannot vote fifty times, spam and profanity handling, and an endpoint that stays up for people who already installed your binary. Nothing there is hard, it is just a real backend you now own forever. Build it if you like owning it, pay if your roadmap board is not the thing you want to be on call for.

el prompt
Build a self-hosted feature request board with a small public API, meant to be embedded in my own apps.

Stack, no substitutions: Next.js 15 with the App Router and TypeScript, SQLite via better-sqlite3 with Drizzle ORM, Tailwind for styling. No auth provider, no analytics, no telemetry, no external services.

Data model: projects (id, name, api_key), wishes (id, project_id, title, description, status, created_at, author_device_id), votes (wish_id, device_id, unique together), comments (id, wish_id, device_id, body, created_at). Statuses: pending, approved, in_progress, completed, rejected.

Public REST API, all scoped by an X-Api-Key header mapped to a project:
- GET /api/wishes?sort=votes|new returns approved, in_progress and completed wishes with vote counts and whether the calling device already voted
- POST /api/wishes creates a wish with status pending
- POST /api/wishes/:id/vote and DELETE /api/wishes/:id/vote, idempotent per device_id
- GET and POST /api/wishes/:id/comments
Device identity is a client-generated UUID sent as X-Device-Id. No accounts. Reject bodies over 2000 characters and rate limit writes to 10 per device per hour using an in-memory token bucket.

Admin UI at /admin behind a single ADMIN_PASSWORD from .env, checked with a signed httpOnly cookie: list all wishes including pending, change status, delete, merge a duplicate into another wish (moves votes, dedupes by device_id).

Public web board at /b/[projectId]: sortable list, vote button, detail page with comments, submit form. Mobile-first, plain and fast, no animations.

Also generate a minimal SwiftUI package in ./ios-sdk: one WishBoardView that lists, votes and submits against the API, device UUID persisted in UserDefaults, base URL and api key passed in at init. Keep it under 300 lines and do not add dependencies.

Out of scope: email or push notifications, multi-tenant signup, billing, roadmap columns, OAuth, i18n.

Secrets in .env: ADMIN_PASSWORD, COOKIE_SECRET. Ship a seed script that creates one project and ten sample wishes, plus a README with curl examples for every endpoint.

$ ábrelo en tu agente (prompt listo, tú das enter) o cópialo crudo

Se puede en parte

Ahorro de referencia: US$180/año si dejas de pagar WishKit.

Quiero que lo armen →
por qué la gente sigue pagando

Because a feature request board is not the product, it is a chore attached to the product. Paying converts an endpoint you have to keep alive, patch, and defend from spam into a line item, and it gets you a native widget that matches the platform without you writing UI you do not care about. Indie developers in particular are buying the SDK and the uptime, not the CRUD.

qué pierdes

xA maintained SDK per platform, so every new client is your code to write and version

xAnti-abuse that someone else already tuned: duplicate votes, spam floods, garbage submissions

xUptime you did not have to think about for users running an old build of your app

xEmail or push notifications when a request they voted for ships

xDuplicate merging, tagging and the other board hygiene features that only matter once you have hundreds of wishes

arte previo · úsalo en vez de construir, si prefieres

Nada que valga la pena señalar. Por eso existe el prompt.

compartir en X ↗"Acabo de reemplazar WishKit ($15/mes) con un prompt"
preguntas
¿Puedo vibecodear WishKit?

Parcial. El núcleo de WishKit se arma en un fin de semana con el prompt de esta página, pero hay huecos reales: A maintained SDK per platform, so every new client is your code to write and version, Anti-abuse that someone else already tuned: duplicate votes, spam floods, garbage submissions. Lee la lista honesta arriba antes de comprometerte.

¿Cuánto cuesta WishKit?

WishKit cuesta unos $15/mes (Premium, revisado 2026-08-18), o sea $180 al año.

¿Qué pierdo si reemplazo WishKit?

Con honestidad: A maintained SDK per platform, so every new client is your code to write and version; Anti-abuse that someone else already tuned: duplicate votes, spam floods, garbage submissions; Uptime you did not have to think about for users running an old build of your app; Email or push notifications when a request they voted for ships; Duplicate merging, tagging and the other board hygiene features that only matter once you have hundreds of wishes. Si alguno de esos te sostiene el negocio, sigue pagando.

¿Hay una alternativa open source a WishKit?

No hay una alternativa open source madura que valga señalar. Por eso existe el prompt de esta página.

Cada semana mueren más suscripciones.

Veredictos nuevos, prompts nuevos, las apps más condenadas de la semana.
Un correo. Te sales en un clic.

gratis para siempre · sin spam · el prompt se queda en el sitio, las muertes te llegan a ti

$semanal: qué recibió veredicto, qué murió.