Design and review
Claude
Where a design gets argued with before it is built. It reads a whole plan at once, pushes back on the weak assumption, and drafts the tedious middle so my attention goes to the decisions that are actually load-bearing.
Abik MaharjanBackend DeveloperKathmandu
Built at the edge.
Made to hold.
I build backend systems on Cloudflare: Workers at the front, Queues between them, Durable Objects where the state has to be authoritative, and Postgres behind Hyperdrive. Many small services instead of one large one — each with a single job, an explicit failure mode, and no server to keep alive. I care about the parts nobody sees, because those are the parts that fail at three in the morning.
Background
About
I build backend systems on Cloudflare, and I am most useful on the parts of a system that are hard to see.
That means distributed services rather than one application: Workers at the edge, Queues between them, Durable Objects where something has to be authoritative, R2 and KV for the state that suits them, and Postgres behind Hyperdrive as the system of record. Dozens of small deployments, each with one job, each replaceable without a migration plan.
Most of what I care about is unglamorous: a consumer that can be retried without doing the work twice, a webhook whose signature is checked before anything else happens, a secret that lives in a store rather than in a deploy, and a failure that surfaces as a dead-letter message instead of a silence. Delivery semantics, idempotency, and the authorization boundary are decisions I want made deliberately and written down, because the alternative is discovering them during an incident.
I work from Kathmandu, remotely, across time zones.
- Focus
- Backend — distributed services on Cloudflare
- Primary
- Workers · Queues · Durable Objects · Postgres
- Also
- JavaScript, Go, TypeScript, Web Crypto, OAuth
- Timezone
- UTC+5:45 · remote, async-friendly
What I build with
The Stack
Five primitives, one per layer of a request's life, chosen because the failure modes are knowable and the shape they push you towards is the right one. Each entry says what it actually does in the systems I build, not what its landing page claims.
Runtime
Cloudflare Workers
Every service is a Worker: an ESM module with a fetch handler, no framework underneath it, and a dependency list short enough to read in full. Code runs in the data centre the request arrived at, starts in a millisecond, and has no container, no image, and no idle instance behind it.
No cold-start tax and no server to keep alive means a service can be small enough to have exactly one job.
Messaging
Cloudflare Queues
The seam between accepting work and doing it. Producers acknowledge fast and get out of the request path; consumers process in batches, retry on their own terms, and drop what they cannot handle into a dead-letter queue instead of a log file. Delivery semantics are a decision made per lane, not a default inherited.
A slow dependency should back up a queue, never a request the caller is still waiting on.
Coordination
Durable Objects
Where the system needs one authoritative copy of something and the guarantee that only one thing is touching it. Single-threaded, addressable by name, with SQLite storage and alarms that let an object wake itself up later — scheduling, sequencing, and any invariant that a race would otherwise destroy.
Strong consistency at a known address is worth more than a distributed lock you have to get right.
Data
Postgres via Hyperdrive
The system of record: real constraints, real transactions, real migrations. Hyperdrive is what makes it reachable from a runtime with no long-lived connections — pooling and caching in front of the database so a Worker can query it without exhausting it.
Serverless compute is not a reason to give up the relational guarantees that outlive every service in front of them.
Composition
Service bindings
How the services find each other. Most of them have no public route at all: they are reachable only through a binding, worker to worker, without leaving Cloudflare's network. The public edge is one service that verifies the caller, and everything behind it can assume it has already been checked.
A private-by-default network makes the authorization boundary a place you can point at.
Selected projects
Work
The production work is private, so what is here is the public half: tools I build for myself and keep using, plus a couple of apps. Every entry is a repository you can open and read — no screenshots standing in for code.
- gopullOne command to bring every repository on the disk up to date.
- claude-ssh-daemonAn MCP server that lends a coding agent a persistent SSH session.
- fcleanScaffolds Flutter Clean Architecture features so you stop typing the same twelve folders.
- JatraA living almanac of the great Newar festivals of the Kathmandu Valley.
- Rick & Morty BrowserA typed React Native client for a public API, built to be read.
The full surface
Platform
The stack above is the spine. This is everything else the runtime provides that I reach for by name, grouped by the problem it solves — primitives and what they are for, with the systems they happen to run left out on purpose.
Compute
Code that runs where the request lands
Small single-purpose Workers rather than one large service. No framework underneath them — a fetch handler, a router I can read in one screen, and a dependency list short enough to audit.
- Cloudflare Workers
- fetch, queue, and scheduled handlers on the ESM runtime, with nodejs_compat where a Node API is genuinely the right tool.
- Smart Placement
- Moves the database-heavy workers next to the data instead of next to the user, which is the correct trade when a request makes several round trips.
- Cron Triggers
- Scheduled handlers for the work that has to happen whether or not anyone made a request — token refreshes, sweeps, reconciliation.
- Wrangler
- Every binding, route, compatibility date, and migration declared in the config file next to the code that depends on it.
Composition
Services that are private by construction
Most workers have no public route and no workers.dev subdomain at all. They are reachable only through a service binding, which makes the authorization boundary a single edge on the graph rather than a check repeated in twenty places.
- Service bindings
- Worker-to-worker calls that never leave Cloudflare's network — no public hostname, no egress, no second TLS handshake to pay for.
- Custom domains and routes
- Public surface area declared explicitly, one hostname per service that is meant to be reachable, nothing exposed by default.
- Fan-out aggregation
- One request bound to several downstream services in parallel, merged with an explicit degraded flag so a partial answer is labelled rather than silently short.
Messaging
Work that survives the thing that was doing it
Ingestion and processing are separate deployments with a queue between them. The producer's job is to accept and acknowledge; the consumer's job is to be retried safely. Neither one can take the other down.
- Cloudflare Queues
- Producer and consumer bindings, batch size and timeout tuned per lane, so a slow downstream backs up in the queue instead of in a request.
- Delivery semantics
- Chosen per lane and written down: at-most-once with retries off where a duplicate is worse than a loss, at-least-once with idempotent consumers where it is not.
- Dead-letter queues
- The messages that exhausted their retries land somewhere inspectable rather than disappearing into a log line.
- Webhook fan-out
- A router that verifies the signature once and splits an inbound event into per-type lanes, each with its own consumer and its own failure blast radius.
State and storage
One place per kind of state
Each store is picked for the shape of the data, not out of habit: strongly consistent coordination in one, hot lookups in another, bytes in a third, and the system of record in Postgres.
- Durable Objects
- Single-threaded coordination points with SQLite-backed storage and alarms, addressed cross-script from sibling workers — scheduling and anything else that needs one authoritative copy.
- Workers KV
- Reads that are hot, global, and tolerant of a moment's staleness: configuration, rule sets, short-lived flow state.
- R2
- Object storage with a public custom domain and no egress bill, fronted by Cloudflare's image and media transformations so derivatives are computed on request instead of stored.
- Hyperdrive
- Pooled, cached access to Postgres from a runtime that has no long-lived connections to give it — the reason a relational database is still the system of record here.
Identity and secrets
Credentials that live outside the code
Nothing authenticates by comparing strings it was deployed with. Secrets resolve at runtime from a store the deployment pipeline cannot read, and every inbound request proves who it is before it reaches anything that matters.
- Secrets Store
- Account-level secrets bound by name, shared across the fleet and rotated in one place rather than re-deployed into thirty.
- JWT and JWKS verification
- Asymmetric tokens verified in the worker against a remote key set, so the signing key is never a thing the service has to hold.
- Web Crypto
- Constant-time signature verification for inbound provider webhooks, PKCE challenges, and encryption of tokens at rest.
- OAuth 2.0 with PKCE
- Authorization-code flows against third-party providers, with the transient state kept in KV and refresh handled on a schedule rather than on the critical path.
Operations
Deployments that are boring on purpose
A change is tested, deployed, and observable without anyone opening a dashboard to make it happen. The interesting part of a system should be the design, not the ritual around shipping it.
- Workers Observability
- Invocation logs and traces enabled on every service, because the alternative is guessing which of the small services was the slow one.
- Vitest
- Unit tests over handlers and their bindings, run on every push, gating the deploy rather than decorating the repository.
- GitHub Actions
- Tests on pull request, wrangler deploy on merge, and runtime secrets deliberately absent from CI — the pipeline ships code and never learns a credential.
Roughly forty of these services are in production, each one a deployment of its own. The count is not the point — the point is that a service small enough to hold in your head is a service you can reason about at three in the morning, and the platform makes that shape cheap enough to actually commit to.
How the work gets made
Tooling
I use AI tooling daily and would rather say so plainly than pretend otherwise. It is leverage on the mechanical parts — drafting, refactoring, arguing with a design before it is built. The architectural decisions, the trade-offs, and the responsibility for what ships are mine.
Implementation
Cursor
In-editor work with the codebase in context: multi-file refactors, renames that hold across a project, and the mechanical edits that would otherwise break concentration. Fast enough to stay in the loop rather than around it.
Get in touch
Contact
Open to work and interesting problems.
Email is the fastest way to reach me. If you would rather read code than a CV, the public repositories are there — open one and tell me where it is weak. If you want to talk about the production work, ask and I will walk you through the architecture.
Common questions
These are canned answers to the questions people usually ask. The panel in the corner reads from this same list — it is a script, not a language model.
- Who is Abik Maharjan?
- A backend developer based in Kathmandu, Nepal, working remotely. He builds distributed systems on Cloudflare: Workers serving the requests, Queues carrying the work between them, Durable Objects holding the state that has to be authoritative, and Postgres behind Hyperdrive as the system of record. The public half of his work is developer tooling, mostly in Go.
- What does Abik actually build?
- Fleets of small backend services on Cloudflare Workers: HTTP APIs, queue consumers, scheduled jobs, OAuth flows against third-party providers, webhook ingestion with signature verification, and Durable Object schedulers that wake themselves up on an alarm. Most of those services are private by construction — no public route at all, reachable only through a service binding. The production code is not public; the platform section says exactly which primitives it is built on.
- Why Workers, Queues, Durable Objects, and Postgres?
- Because together they make a small service cheap enough to be worth building. Workers have no cold-start tax and no instance to keep alive, so a service can have exactly one job. Queues put a seam between accepting work and doing it, which is what stops a slow dependency from becoming a slow request. Durable Objects give one authoritative copy of state at a known address, so a race does not have to be solved with a distributed lock. Postgres stays the system of record because relational guarantees outlive every service in front of them, and Hyperdrive is what makes it reachable from a runtime with no long-lived connections.
- Which project is worth looking at first?
- The production work is private, so start with the platform section — it names every primitive the systems are built on. In the public repositories, claude-ssh-daemon is the closest thing to the way he thinks about boundaries: the human holds the SSH session and the daemon only borrows it, so the agent never touches a credential. gopull is the same instinct at a smaller scale — one job, one static binary, no runtime to install.
- Does he use AI to write his code?
- Yes, daily, and he would rather say so plainly than pretend otherwise. Claude for design review and drafting, Cursor for in-editor refactors. It is leverage on the mechanical parts. The architecture, the trade-offs, and the responsibility for what ships are his.
- Where is Abik based, and does he work remotely?
- Kathmandu, Nepal, on UTC+5:45. He works remotely and is used to async collaboration across time zones — that offset means overlap with Europe in his afternoon and with Asia-Pacific in his morning.
- How do I get in touch?
- Email, listed in the contact section at the bottom of this page. He is open to work and to interesting problems. If you would rather read code than a CV, the GitHub profile is public — open a repository and tell him where it is weak. He would rather have that than a compliment.
- How was this site built?
- Next.js with the App Router, deployed on Vercel. The portfolio pages are prerendered at build time and read nothing at runtime; the writing section is server-rendered from a Supabase Postgres database and cached, which is why this is no longer a pure static export. The project list is real: it is pulled from the GitHub API by a script, committed as a snapshot, and read from disk at build time, so the build never depends on the network. There is no analytics and there are no trackers — the blog counts views and claps per post, and that is the whole of it. This panel is a script with a fixed number of answers, not a language model.