Lohnt sich dein eigenes WishKit?
Direkt integrierbares Board für Funktionswünsche und Abstimmungen in Apps, mit nativem SwiftUI-SDK und gehostetem Backend.
Das Datenmodell besteht hier aus vier Tabellen und einer Sortierfunktion: Wünsche, Stimmen, Kommentare, Status. Ein Agent kann das gesamte Web-Board samt REST-API in einer Sitzung erstellen, und für ein Nebenprojekt wird es gut funktionieren. Die eigentliche Arbeit kommt danach: ein natives In-App-Widget für jede Plattform, auf der du veröffentlichst, anonyme Geräteidentität, damit derselbe Nutzer nicht fünfzigmal abstimmen kann, Umgang mit Spam und beleidigenden Inhalten sowie ein Endpunkt, der für Menschen mit bereits installiertem Programm erreichbar bleibt. Nichts davon ist schwierig, es ist einfach ein echtes Backend, für das du ab jetzt dauerhaft verantwortlich bist. Baue es, wenn du diese Verantwortung gern übernimmst; bezahle, wenn dein Roadmap-Board nicht das ist, wofür du Bereitschaftsdienst leisten möchtest.
EN → DERecherche automatisch aus dem Englischen übersetzt. Original-Prompt auf Englisch beibehalten.
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.Der Prompt öffnet sich vorausgefüllt in deinem Agenten. Prüfe ihn vor dem Ausführen. · dieser Prompt wurde aus dem Bauplan erzeugt · per PR verbessern
Wie sähe deine eigene Version aus?
Betreibt ein selbst gehostetes Board für Funktionswünsche mit Abstimmungen, Kommentaren, Statuskennzeichnungen und einer Admin-Ansicht, zugänglich über eine kleine REST-API, die deine App aus einem eingebetteten Widget aufrufen kann.
Was du brauchst
- Ein Hosting-Platz für einen kleinen Node-Dienst mit dauerhaftem Datenträger
- Eine Domain oder Subdomain, die deine veröffentlichte App aufrufen kann
- Xcode, wenn du das SwiftUI-Widget kompilieren und testen möchtest
- Einfache Ratenbegrenzung oder ein Proxy vor den Schreibendpunkten
Weil ein Board für Funktionswünsche nicht das Produkt ist, sondern eine lästige Aufgabe rund um das Produkt. Bezahlen macht aus einem Endpunkt, den du am Leben halten, aktualisieren und gegen Spam verteidigen musst, einen Kostenposten. Außerdem bekommst du ein natives Widget, das zur Plattform passt, ohne eine UI schreiben zu müssen, die dir eigentlich egal ist. Gerade Indie-Entwickler kaufen das SDK und die Verfügbarkeit, nicht das CRUD.
xEin gepflegtes SDK pro Plattform, sodass du jeden neuen Client selbst schreiben und versionieren musst
xBereits von jemand anderem abgestimmten Missbrauchsschutz: doppelte Stimmen, Spamfluten, unbrauchbare Einreichungen
xVerfügbarkeit für Nutzer einer alten App-Version, um die du dich nicht kümmern musstest
xE-Mail- oder Push-Benachrichtigungen, wenn ein Wunsch umgesetzt wird, für den sie gestimmt haben
xZusammenführen von Duplikaten, Tags und andere Funktionen zur Board-Pflege, die erst bei Hunderten Wünschen wichtig werden
Nichts, worauf sich verweisen ließe. Deshalb gibt es den Prompt.
Was kostet WishKit?
- Monatliche Zahlung
- 15 $/Mon.15 $/Mon.
- Pro Jahr
- 180 $/Jahr180 $/Jahr
- Mit brasilianischer Karte, inkl. 3,5% IOF
- 78,39 R$/Mon.941 R$/Jahr
In Meine Liste gespeichert. Bei einer Preisänderung erscheint hier ein Hinweis.
Du schließt den Kauf auf der Website von WishKit ab. Vibe Radar wickelt keine Zahlungen ab.
WishKit selbst bauen oder abonnieren?
Passe die Zahlen an: Stunden zum Bauen, dein Stundensatz, Betriebskosten und der Abopreis.
Über 24 Monate ist das Abo günstiger.
Startwerte aus der Analyse geschätzt (ein Wochenende). Nicht eingerechnet ist, was dir fehlt (Support, Integrationen, Sicherheit).
Kann ich WishKit nachbauen?
Teilweise. Den Kern von WishKit baust du mit dem Prompt auf dieser Seite an einem Wochenende, aber es gibt echte Lücken: Ein gepflegtes SDK pro Plattform, sodass du jeden neuen Client selbst schreiben und versionieren musst, Bereits von jemand anderem abgestimmten Missbrauchsschutz: doppelte Stimmen, Spamfluten, unbrauchbare Einreichungen. Lies die Liste oben, bevor du loslegst.
Was kostet WishKit?
WishKit kostet etwa 15 $/Mon. (Premium, geprüft am 20.10.2026), also 180 $ pro Jahr.
Was fehlt mir, wenn ich WishKit ersetze?
Ehrlich gesagt: Ein gepflegtes SDK pro Plattform, sodass du jeden neuen Client selbst schreiben und versionieren musst; Bereits von jemand anderem abgestimmten Missbrauchsschutz: doppelte Stimmen, Spamfluten, unbrauchbare Einreichungen; Verfügbarkeit für Nutzer einer alten App-Version, um die du dich nicht kümmern musstest; E-Mail- oder Push-Benachrichtigungen, wenn ein Wunsch umgesetzt wird, für den sie gestimmt haben; Zusammenführen von Duplikaten, Tags und andere Funktionen zur Board-Pflege, die erst bei Hunderten Wünschen wichtig werden. Wenn dir davon etwas wichtig ist, zahl weiter.
Gibt es eine Open-Source-Alternative zu WishKit?
Es gibt keine ausgereifte Open-Source-Alternative, auf die sich verweisen ließe, und genau deshalb gibt es den Prompt auf dieser Seite.