Faut-il créer votre propre WishKit ?
Tableau de demandes de fonctionnalités et de votes facile à intégrer aux applications, avec un SDK SwiftUI natif et un backend hébergé.
Le modèle de données se résume ici à quatre tables et une fonction de tri : demandes, votes, commentaires et statuts. Un agent peut produire l'ensemble du tableau web et une API REST en une seule session, et le résultat conviendra parfaitement à un projet personnel. Le véritable travail commence après : un widget natif intégré à l'application pour chaque plateforme sur laquelle vous la distribuez, une identité anonyme par appareil pour qu'un même utilisateur ne puisse pas voter cinquante fois, la gestion du spam et des propos grossiers, et un endpoint qui reste disponible pour les personnes ayant déjà installé votre binaire. Rien de tout cela n'est difficile ; c'est simplement un vrai backend dont vous êtes désormais responsable pour toujours. Construisez-le si vous aimez en avoir la charge, payez si votre tableau de feuille de route n'est pas ce pour quoi vous voulez assurer une astreinte.
EN → FRAnalyse traduite automatiquement de l’anglais. Prompt original conservé en anglais.
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.Le prompt s’ouvre prérempli dans votre agent. Relisez-le avant de l’exécuter. · ce prompt est généré à partir du plan de construction · améliorez-le via une PR
Comment créer votre propre version ?
Fait fonctionner un tableau auto-hébergé de demandes de fonctionnalités avec votes, commentaires, étiquettes de statut et vue d'administration, exposé par une petite API REST que votre application peut appeler depuis un widget intégré.
Ce dont vous aurez besoin
- Un hébergement pour un petit service Node avec disque persistant
- Un domaine ou sous-domaine que votre application distribuée peut appeler
- Xcode si vous voulez compiler et tester le widget SwiftUI
- Une limitation basique du débit ou un proxy devant les endpoints d'écriture
Parce qu'un tableau de demandes de fonctionnalités n'est pas le produit : c'est une corvée qui l'accompagne. Payer transforme un endpoint que vous devez garder en vie, corriger et protéger du spam en une ligne de dépense, et vous donne un widget natif adapté à la plateforme sans vous obliger à écrire une UI qui ne vous intéresse pas. Les développeurs indépendants achètent surtout le SDK et la disponibilité, pas le CRUD.
xUn SDK maintenu par plateforme : chaque nouveau client devient donc du code à écrire et à versionner vous-même
xUne protection contre les abus déjà réglée par quelqu'un d'autre : votes en double, déferlantes de spam, soumissions sans intérêt
xUne disponibilité dont vous n'avez pas à vous soucier pour les utilisateurs d'une ancienne version de votre application
xDes notifications par e-mail ou push lorsqu'une demande pour laquelle ils ont voté est livrée
xLa fusion des doublons, l'étiquetage et les autres fonctions de gestion du tableau qui ne deviennent utiles qu'une fois les demandes comptées par centaines
Rien qui mérite d’être cité. C’est pour cela que le prompt existe.
Combien coûte WishKit ?
- Facturation mensuelle
- 15 $US/mois15 $US/mois
- Par an
- 180 $US/an180 $US/an
- Avec une carte brésilienne, IOF de 3,5% inclus
- 78,39 R$/mois941 R$/an
Enregistré dans Ma liste. Un avis s’affichera ici si le prix change.
Vous finalisez l’achat sur le site de WishKit. Vibe Radar ne gère aucun paiement.
Construire ou s’abonner à WishKit ?
Ajustez les chiffres : heures de développement, taux horaire, coûts d’exploitation et prix de l’abonnement.
Sur 24 mois, l’abonnement coûte moins cher.
Heures estimées d’après l’analyse (un week-end). Ne chiffre pas ce que vous perdez (support, intégrations, sécurité).
Puis-je recréer WishKit ?
En partie. Le cœur de WishKit se construit en un week-end avec le prompt de cette page, mais il reste de vraies lacunes : Un SDK maintenu par plateforme : chaque nouveau client devient donc du code à écrire et à versionner vous-même, Une protection contre les abus déjà réglée par quelqu'un d'autre : votes en double, déferlantes de spam, soumissions sans intérêt. Lisez la liste ci-dessus avant de vous lancer.
Combien coûte WishKit ?
WishKit coûte environ 15 $US/mois (Premium, vérifié le 20/10/2026), soit 180 $US par an.
Que perd-on en remplaçant WishKit ?
Honnêtement : Un SDK maintenu par plateforme : chaque nouveau client devient donc du code à écrire et à versionner vous-même; Une protection contre les abus déjà réglée par quelqu'un d'autre : votes en double, déferlantes de spam, soumissions sans intérêt; Une disponibilité dont vous n'avez pas à vous soucier pour les utilisateurs d'une ancienne version de votre application; Des notifications par e-mail ou push lorsqu'une demande pour laquelle ils ont voté est livrée; La fusion des doublons, l'étiquetage et les autres fonctions de gestion du tableau qui ne deviennent utiles qu'une fois les demandes comptées par centaines. Si l’un de ces points compte pour vous, continuez à payer.
Existe-t-il une alternative open source à WishKit ?
Aucune alternative open source mature à recommander, et c’est précisément pour cela que le prompt de cette page existe.