DEV Community: Arpan Sarkar

I built an auction for our FIFA draft night, and a local Gemma bids for the friend who can't be there

Arpan Sarkar — Mon, 05 Oct 2026 00:32:07 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Six of us play FIFA on a PS5. We were setting up a proper tournament, and the part that kept falling apart was picking squads.

We'd always done it with a spreadsheet, which produces exactly the evening you'd expect: someone reads out names, someone else quietly takes all the good ones, and two people spend twenty minutes arguing about whether the list was fair before anyone touches a controller.

An auction fixes that. Everyone gets the same budget, you bid for the players you want, and you live with the squad you built. Nobody can complain about a draft they set the prices in.

Except an auction only works if everyone turns up. And Rohit was going to miss it.

The usual fix is for someone in the room to "bid on his behalf," which means one of two things. Either you bid badly for him because you're busy bidding for yourself, or you quietly build yourself the better squad. Neither is a draft he'd have wanted.

So I built Draft Night: an auction that runs on one laptop over the living room wifi, with the TV showing the lot and everyone bidding from their phones. And anyone who can't be there gets a proxy manager — a local open-weight model that bids for them, live, against everyone in the room, inside their budget, from instructions they wrote in their own words.

Rohit sent me this:

I want pace up front above all else. Get a keeper early so I'm not stuck with whoever is left. Never spend more than 40% of my budget on one player.

That paragraph is the whole input. No sliders, no priority rankings, no config file. He typed a few sentences into a text box and the model bid his draft.

Demo

There's no deployed link, and that's deliberate rather than laziness. The whole thing runs on one laptop over a local network with no internet connection. Hosting it would undo the point of it.

Your phone shows three things: what you've got left, who's on the block, and one big button. That's all anyone can handle while six people are shouting.

Code

iambetaraybill / draft-night

An offline auction draft for a living-room FIFA tournament. Friends bid from their phones; whoever can't make it is represented by a local open-weight model.

Draft Night

An auction draft for a living room full of friends. Everyone bids from their phone, the TV shows the lot on the block, and whoever couldn't make it is represented by a proxy manager: a local open-weight model that bids on their behalf, inside their budget, from instructions they wrote in plain English.

Runs on one laptop over your own wifi. No accounts, no cloud, no internet, no API keys, nothing to pay per bid.

  GK
  Niko Jovic                          Managers
  rated 91 · FC Harbourside           Rohit              148
                                        1 GK · 2 DEF
      42  with Rohit                  Sam  proxy · in     92
                                        2 DEF · 1 FWD
  ████████████░░░░░░░░                Dev                 61
  6.4s left. Any bid puts 7              1 MID · 2 FWD
  seconds back on the clock

Why this exists

Six of us run a FIFA tournament on a PS5. Picking squads used to be a spreadsheet and an argument. An auction…

View on GitHub

Two dependencies, Flask and requests. No build step, no npm, no bundler. Phones need a browser and the URL.

draftnight/
  rules.py     budgets and squad legality. no I/O, no model, no randomness
  agents.py    proxy bidders: model valuations, clamping, heuristic fallback
  room.py      state machine, clock, agent scheduling, event broadcast
  players.py   CSV loading with loose column matching
  server.py    Flask routes and the server-sent event stream
static/
  common.js    shared by both views: escaping, fetch, event stream, clock
  host.html    the TV
  play.html    phones

How I Built It

Gemma running locally through Ollama, with structured JSON output. No API keys, no account, no network.

The design decision the whole project rests on is this one:

A bidding war has a dozen exchanges inside fifteen seconds. On a CPU-only laptop a small model needs one to three seconds for even a short JSON answer. Calling the model on every exchange would either stall the auction dead or force me down to a model too small to actually read a paragraph of strategy.

So the model answers one question per lot — what is this player worth to this manager, and why? — and deterministic code does the bidding up to that ceiling, with a randomised human-feeling pause between raises so the agents don't snipe instantly and make the room feel rigged.

Ollama's structured output takes a JSON schema and constrains generation to it, which is what makes a small model reliable enough to put in a live loop at all:

PLAN_SCHEMA = {
    "type": "object",
    "properties": {
        "want": {"type": "boolean"},
        "max_bid": {"type": "integer"},
        "reason": {"type": "string"},
    },
    "required": ["want", "max_bid", "reason"],
}

The model never touches money. It suggests a ceiling; rules.py decides what's legal. Budgets, bid validity, roster slots, increments and the clock are all plain Python with no model anywhere near them.

That isn't a stylistic preference, it's the thing that makes an unpredictable model safe to hand a wallet. A model that replies max_bid: 99999 produces a legal bid of exactly that manager's cap and a logged clamp:

asked = int(raw.get("max_bid") or 0)
clamped = asked > cap
plan = Plan(
    want=bool(raw.get("want")) and asked >= rules.min_bid,
    max_bid=max(0, min(asked, cap)),   # the model does not get the last word
    ...
)

There's a test for exactly that, because "the model probably won't do that" is not a budget control.

The other rule worth naming is the reserve. Before any bid is accepted, the server checks you can still fill every remaining slot at the minimum price:

def max_bid(self, m: Manager) -> int:
    slots = self.slots_left(m)
    if slots <= 0:
        return 0
    reserve = (slots - 1) * self.min_bid
    return max(0, self.budget_left(m) - reserve)

Without it, somebody spends 95% of their budget on one galactico and fields six empty shirts. The test I care most about spends the maximum allowed on every single lot and checks the squad still completes legally.

Three bugs worth admitting to

The agents sat out the entire first auction. Twenty-four lots, proxy manager bought nothing. The valuations were fine — the model wanted players. My test harness was closing each lot the instant it opened, faster than the agents' deliberately human reaction delay. The bug wasn't in the agent; it was that my timings were hardcoded constants with no way to run fast without also running unfairly fast. Timings are configurable now, and the agents get a guaranteed reaction window once their plans land.

A test passed for the wrong reason, which is worse than failing. I had an assertion that an absurd overbid gets refused. It checked for HTTP 400 and nothing else. In CI it was getting 400 — but for "nothing is up for auction right now," because the host token didn't match and the auction had never started. A test that goes green while the feature is broken is actively harmful. It now asserts the refusal actually mentions the budget limit.

The TV rebuild ate the host's typing. The host screen re-renders once a second to keep the clock honest. If someone joined from their phone while you were halfway through typing a friend's strategy into the textarea, your text vanished. Now only the changed regions get patched, and in-progress input is held across rebuilds.

Tests

36 unit tests, plus an end-to-end run that drives an entire auction over HTTP and asserts every squad ends full and formation-legal, nobody goes negative, and the proxy manager actually wins players. Both run in GitHub Actions across Python 3.10 to 3.13 on every push.

CI also checks the committed sample pool still matches its generator, and that the CSV loader survives a deliberately messy two-thousand-row export.

Why Does Open Innovation Matter?

Three reasons, none of which are about saving money.

It has to work in a flat with bad wifi. The whole thing runs on one laptop. Phones reach it over the local network. If the router loses its uplink mid-draft, nobody notices. A draft night that dies because an API is having an incident isn't a draft night.

A cloud round trip would break the bidding. Valuations have to be ready before the hammer falls. That means inference on the same machine as the auction clock, which means a model I can actually hold.

My friends' instructions are theirs. "Don't let Rohit get a keeper" is a daft thing to ship to someone else's server, and there's no reason to. Nothing leaves the room.

There's a fourth thing I didn't expect, and it's the one that convinced me. The project ships with --no-llm, a heuristic fallback that bids on ratings alone so the app still works with no model installed. It was meant as a graceful degradation path.

It turned into the control group.

The heuristic can read a rating. It cannot read "get a keeper early so I'm not stuck with whoever's left." It cannot read "don't let Rohit get a striker." Running both over the same pool, with the same budgets, is the clearest possible demonstration of what the open model is actually contributing — and I could only build that comparison because swapping the model out is a one-line change and running it a hundred times costs nothing.

Closed APIs give you a better model. Open weights gave me a model I could put inside the thing, on the critical path, in a living room with the internet off, and then run the whole evening again with it removed to see what it was worth.

Prize Categories

Gemma — Gemma runs locally through Ollama as the proxy bidders' judgement layer, with schema-constrained JSON output.

Permission Based Authorization in Angular (PBAC)

Arpan Sarkar — Wed, 12 Feb 2025 18:36:11 +0000

Authorization is a critical part of any Angular application, ensuring that users can only access the parts of the application they are permitted to.
In most applications, users have assigned roles.
We can enforce access control in Angular routes by using route guards.

In many applications, role based access control (RBAC) alone is not enough. Users may need fine grained permissions beyond just roles. For example:

Admin - Can manage users and edit settings.
Editor - Can edit articles but not manage users.
Viewer - Can only view content.

In this article, we’ll see how in Angular to include

Permission Based access control (PBAC)

Step 1: Setting Up the Angular Application

Start by creating a new Angular app if you don’t have one

ng new angular-pbac --routing

Step 2: Create an Auth Service for Dynamic Permissions

This service will store user roles with associated permissions, retrieve them dynamically from an API (mocked for now) and provide authentication authorization methods.

auth.service.ts

import { Injectable } from '@angular/core';
import { Router } from '@angular/router';

@Injectable({
  providedIn: 'root',
})
export class AuthService {
  private user: { role: string; permissions: string[] } | null = null;

  private rolePermissions: Record<string, string[]> = {
    admin: ['manage-users', 'edit-settings', 'view-dashboard'],
    editor: ['edit-articles', 'view-dashboard'],
    viewer: ['view-dashboard'],
  };

  constructor(private router: Router) {}

  login(role: string): void {
    const permissions = this.rolePermissions[role] || [];
    this.user = { role, permissions };
    localStorage.setItem('userPermissions', JSON.stringify(permissions));
    this.router.navigate(['/dashboard']);
  }

  logout(): void {
    this.user = null;
    localStorage.removeItem('userPermissions');
    this.router.navigate(['/login']);
  }

  getUserPermissions(): string[] {
    return JSON.parse(localStorage.getItem('userPermissions') || '[]');
  }

  hasPermission(permission: string): boolean {
    return this.getUserPermissions().includes(permission);
  }
}

For now using mock roles and permissions which normally is retrieved from a backend - rolePermissions
Here we are doing simple login method without setting user role or checking if authenticated or not. Just to keep it simple we are avoiding that

Step 3: Create a Permission Based Route Guard

In Angular, Route guards help protect routes based on authentication and roles.
Now, we need a route guard to check for both roles and permissions before allowing access.

permission.guard.ts

import { Injectable } from '@angular/core';
import { CanActivate, ActivatedRouteSnapshot, Router } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable({
  providedIn: 'root',
})
export class PermissionGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}

  canActivate(route: ActivatedRouteSnapshot): boolean {
    const requiredPermission = route.data['permission'];

    if (!this.authService.hasPermission(requiredPermission)) {
      this.router.navigate(['/unauthorized']);
      return false;
    }

    return true;
  }
}

Step 4: Define Routes with Permission Based Access

Now, we will apply our new permission-based guard to specific routes.

app.config.ts

import { provideRouter, Route } from '@angular/router';
import { LoginComponent } from './login/login.component';
import { DashboardComponent } from './dashboard/dashboard.component';
import { UnauthorizedComponent } from './unauthorized/unauthorized.component';
import { PermissionGuard } from './permission.guard';


const routes: Routes = [
  { path: 'login', component: LoginComponent },
  { path: 'dashboard', component: DashboardComponent },

  // Permission based routes 
  { path: 'edit-settings', component: DashboardComponent, canActivate: [PermissionGuard], data: { permission: 'edit-settings' } },
  { path: 'manage-users', component: DashboardComponent, canActivate: [PermissionGuard], data: { permission: 'manage-users' } },

  { path: 'unauthorized', component: UnauthorizedComponent },
  { path: '', redirectTo: '/login', pathMatch: 'full' },
];

export const appConfig = {
  providers: [provideRouter(routes)],
};

Step 5: Setup Login Component to Handle Dynamic Roles

Now, users can log in as different roles dynamically, and permissions will be applied accordingly.

login.component.ts

import { Component } from '@angular/core';
import { AuthService } from '../auth.service';

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html'
})
export class LoginComponent {
  constructor(private authService: AuthService) {}

  loginAs(role: string) {
    this.authService.login(role);
  }
}

login.component.html

<h2>Login</h2>
<button (click)="loginAs('admin')">Login as Admin</button>
<button (click)="loginAs('editor')">Login as Editor</button>
<button (click)="loginAs('viewer')">Login as Viewer</button>

Step 6: Display logged in user Permissions in Dashboard

Now, let’s display permissions dynamically on the dashboard.

dashboard.component.ts

import { Component } from '@angular/core';
import { AuthService } from '../auth.service';

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html',
})
export class DashboardComponent {
  permissions: string[];

  constructor(private authService: AuthService) {
    this.permissions = this.authService.getUserPermissions();
  }
}

dashboard.component.html

<h2>Dashboard</h2>
<p>Hey</p>
<p>Your Permissions:</p>
<ul>
  <li *ngFor="let permission of permissions">{{ permission }}</li>
</ul>

Step 7: Handling Unauthorized Access

If a user lacks permissions, they will be redirected to an Unauthorized Page.

unauthorized.component.ts

import { Component } from '@angular/core';

@Component({
  selector: 'app-unauthorized',
  template: '<h2>Unauthorized Access</h2>',
})
export class UnauthorizedComponent {}

Conclusion: Building a Fortress of Access Control

In this guide, We seen Angular authorization system by:
✅ Implementing dynamic permissions.
✅ Protecting routes based user permissions.
✅ Automatically handling unauthorized access with redirection.

Authorization in Angular is not just about opening and closing doors - it is about building a fortress with layers of security. Roles and Permissions define the broad gates users can pass through, while permissions act as the keys unlocking specific chambers within. By implementing permission based access control (PBAC), we create a system that is both scalable and adaptive, which ensures users only access they need.

As your application grows, this structured approach will become your architectural blueprint, guiding security while maintaining flexibility.

Did you learn something new today? Let me know in the comments below! 👇