BetNawak: virtual bets among friends
BetNawak is a mobile web app, installable without app stores, for organising virtual bets among friends with points of no real value, in invitation-only teams.
Status: under development. The specification is written; no application code has been delivered yet.
Context and need
The project starts from a brief: let a group of friends challenge each other through bets, with nothing financial at stake. Points are an internal unit with no real value that cannot be converted.
Each team is closed: people join only by email invitation. In the first version, a team has a single administrator, who configures it, invites, moderates and settles disputes.
Access model: access to the service by annual subscription, taken out by the administrator; players never pay. Two tiers are planned (Starter: up to 3 administered teams; Pro: unlimited teams, advanced statistics and export of the team’s data), with prices communicated at opening. Virtual points have no value, cannot be converted and there is no monetary gain; no price depends on the number of points.
Planned behaviour
- Progressive web app designed mobile-first, installable without going through app stores.
- Teams, single-use invitations, administrator and member roles.
- A team points ledger, visible to its members, in which no point is created or destroyed.
- Resolution of a bet, reporting, dispute with rollback to the previous state and an audit log.
- Real-time updates and a team chat.
Planned technical choices
- Stack: TypeScript, Next.js 16, Tailwind CSS 4, Drizzle, PostgreSQL, Redis and a real-time service, orchestrated by Docker Compose behind the proxy shared by the applications.
- Pure domain first: the point calculation rules, the split when a member leaves the team and the states of a bet are written and tested by invariants before the interface.
- Authentication without a library: passwords hashed with Node 24’s native Argon2id (about 25 ms measured), hashed tokens, uniform responses, protection against repeated attempts, tests inspired by the ASVS standard; a documented fallback exists, and an external review of the authentication is planned.
- Isolation between teams checked by cross tests, GDPR (hosting in the European Union, data export and deletion, 30-day freeze then purge on inactivity) and a legal opinion planned.
- Quality: standardised commits, secret detection, local checks.
Difficulties and lessons learned
- Deciding before coding: the first version of the specification had 18 open points, all settled and recorded in a decision log; nine new points arising from those decisions remain to be settled.
- Edge cases first: a member leaving mid-game, a disputed result, a dispute with no decision, rollback to the previous state. These cases are specified before the first screen.
- A deliberate working order: the pure domain and the ledger before the interface, because that is where mistakes cost the most.
- A deliberate choice: writing authentication yourself is more demanding than using a library; the specification therefore provides a fallback and an external review.
Honest status
Today: repository initialised with its tooling (commit hooks, standardised commits), brief, specification v1.1 written and a ten-milestone plan. The first milestone (application foundation) is in progress; the pure domain, accounts, ledger, real time, PWA and the rest remain to be done.
There is therefore no demo and no link: this page presents a design, not a delivered product.
What this shows about my work
- Scoping a project before coding: brief, split specification, traced decisions.
- Reasoning with invariants and edge cases on calculation logic.
- Choosing what must be hand-written (authentication) and what should stay simple, while documenting the fallback.
- Working in milestones, with an honest progress report.
A project to scope?
Describe your idea and I will help turn it into a precise need, then into an application.