Abeer Choubey abeerchoubey

┌─ ABOUT ───────────────────────────────────┐
│                                           │
│  I build the part of the product most     │
│  people never see.                        │
│                                           │
│  Routes, jobs, queues, data layers,       │
│  and tools that make space for people     │
│  to do their real work.                   │
│                                           │
│  Currently running Veylox — a software    │
│  practice focused on internal tooling,    │
│  workflow automation, and systems that    │
│  outlast the sprint they were built in.   │
│                                           │
└───────────────────────────────────────────┘

┌─ CAPABILITIES ────────────────────────┐
│                                       │
│  backend       reliable apis, data    │
│  systems       models, hard problems  │
│                                       │
│  infra         containers, proxies,   │
│  structure     self-hosted services   │
│                                       │
│  auto          workflows that remove  │
│  mation        repetitive work        │
│                                       │
│  ai            agent systems with     │
│  products      constraints & purpose  │
│                                       │
└───────────────────────────────────────┘

`$ cat stack.yml`

languages:
  primary:    [go, typescript]
  secondary:  [python, c++]
  markup:     [html, css, sql]

frameworks:
  backend:    [node.js, GO, supabase]
  frontend:   [react, next.js, vite]
  animation:  [gsap, framer-motion, lenis]

databases:
  relational: [postgresql, sqlite]
  patterns:   [append-only-log, event-sourcing]

infrastructure:
  containers: [docker, kubernetes]
  networking: [nginx, wireguard, tailscale]
  monitoring: [uptime-kuma, portainer]
  tunneling:  [cloudflare-tunnel]
  vcs:        [gitea, github]

`$ cat philosophy.md`

# design principles

1. design for failure
   failures are features. build systems
   you can debug at 3am.

2. simplicity
   the simplest system that solves the
   real problem is the right one.

3. ownership
   if you can't explain every layer,
   you don't own the system.

4. documentation
   an undocumented system is a liability
   to your future self.

# approach

start with a systems audit.
understand the workflow before writing
a single line of code.

the same team that scopes the project
builds it.

┌─ CURRENTLY ─────────────────────────────────────────────────────────────────────────────┐
│                                                                                         │
│  building    nigel — ai orchestration layer for agents, tools, and decision routing     │
│  running     veylox.com — software practice for internal tooling & automation           │
│  exploring   event-driven architectures · queue-backed job processors · state machines  │
│  reading     distributed systems papers · simulation design · railway signaling         │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

────────────────────────────────────────────────────────────

abeer.lol · veylox.com · linkedin · sentinel.loqs@proton.me

────────────────────────────────────────────────────────────

_{systems don't need to be loud to be good.}

Navigation Menu

Abeer Choubey abeerchoubey

Organizations

Block or report abeerchoubey

`$ cat stack.yml`

`$ cat philosophy.md`

Pinned Loading

Uh oh!