DEV Community: Pukar Khanal

I spent three months building Stripe for Nepal, alone

Pukar Khanal — Sat, 22 Aug 2026 10:18:07 +0000

Stripe does not operate in Nepal. Neither does anything with its shape. If you run a business here and want a customer to pay you the same amount every month without thinking about it, your options are to ask them nicely, or to build the thing yourself.

So I built the thing myself. Recurring billing, a prepaid wallet, a double-entry ledger, KYC tiers, an AML reporting pipeline, a merchant dashboard, a hosted checkout, and a back-office console for staff. Roughly 2,500 commits across seven repos between mid-May and early August. The backend is about 46,000 lines of TypeScript across 22 NestJS modules, 31 migrations, 259 test files.

None of that is the interesting part. The interesting part is that almost every hard problem I hit came from the country, not from the code.

Why Stripe doesn't work here, specifically

The obvious answer is "Nepal isn't on the supported countries list." The real answer is more annoying.

Card penetration is low. Most people pay with a mobile wallet, and in practice that means eSewa or Khalti. Neither of them can charge a customer again next month. They do exactly one thing. You send the user to a hosted page, they approve one payment, you get a callback. That is a checkout, not a subscription.

Which means recurring billing in Nepal cannot be built on top of the payment rails. It has to be built beside them. The customer tops up a prepaid wallet through eSewa or Khalti, and the subscription bills against the wallet balance. The wallet is the recurring instrument. The wallet is also the thing that turns you into a regulated entity, which is where the fun starts.

Prepaid balance held on behalf of the public is Nepal Rastra Bank's business. NRB is the central bank and it regulates payment service providers directly. The moment you hold customer funds you inherit balance caps, load-frequency caps, KYC tiers, transaction reporting obligations, and audit retention rules.

I did not choose to build a regulated fintech. I chose to build recurring billing, and the market handed me a regulated fintech.

The law is a scanned PDF

Here is the sequence I actually went through.

I needed the wallet balance cap. Not a rough number, the real one, because the number goes into a database and it decides whether a top-up succeeds. I went looking for it.

NRB publishes a document called the Unified Directive on Payment Systems. It is in Nepali. The version I needed was a scan, meaning no text layer, meaning no grep, no copy-paste, no search. A picture of a legal document.

I ended up running the pages through an image-understanding model to pull the tables out, then corroborating each number against what eSewa and Khalti publish as their own customer-facing limits. A licensed PSP will not advertise a limit above what the law allows, so their published numbers are a useful check on mine.

What came out, from Directive 5/079 section 3:

Flow	Per day (NPR)	Per month (NPR)
Bank account to wallet	200,000	1,000,000
Wallet to bank account	200,000	1,000,000
Wallet to wallet	50,000	500,000

Plus a limit of ten loads per day per person, and an end-of-day balance ceiling of NPR 50,000 that I could corroborate from two licensed PSPs but never read in the amended primary text.

That last gap is the whole lesson. I had a number I was fairly sure about and could not fully verify. The instinct is to hardcode it and move on. That instinct is wrong, and not because of some abstract principle about magic numbers. It is wrong because NRB revises these figures roughly annually, with each new Bikram Sambat year's directive, and whoever updates that number next may not be me.

So caps are rows, not constants:

export const walletCapConfig = pgTable('wallet_cap_config', {
  id: text('id').primaryKey(),
  tier: text('tier', { enum: ['basic', 'standard', 'enhanced', 'all'] }).notNull(),
  flow: text('flow', {
    enum: ['wallet_to_wallet', 'bank_to_wallet', 'wallet_to_bank',
           'overnight_balance', 'per_load_count', 'approval_threshold'],
  }).notNull(),
  capPaisa: moneyPaisa('cap_paisa').notNull(),
  // provenance travels with the number
  directiveCitation: text('directive_citation'),
  confidence: text('confidence').notNull(),
  needsOfficialConfirmation: boolean('needs_official_confirmation').notNull(),
  effectiveFrom: timestamp('effective_from', { withTimezone: true }).notNull(),
  effectiveTo: timestamp('effective_to', { withTimezone: true }),
});

Every cap row is effective-dated and carries where it came from and how sure I am. A row that sits above the NRB overnight ceiling is only valid if it carries a directive citation, and a service-level check enforces that. Raising a cap is itself a privileged action that needs a second person to approve it.

If you build for a regulated market, put the provenance next to the number. A cap with no citation is a cap nobody can safely change.

Money is a bigint or it's wrong

This one is not Nepal-specific but the currency made it sharper. Nepal uses NPR, and NPR subdivides into 100 paisa. Everything internal is integer paisa. No floats, anywhere, ever.

The part people get wrong is not the decision, it's the enforcement. It is very easy to write Money as a class, feel good, and then have someone six weeks later do Number(row.amount_paisa) because the types allowed it.

Two things made it stick. First, pg returns BIGINT columns as JavaScript strings by default, to avoid silent precision loss past 2^53. Correct behavior, and also a trap, because a string flows through arithmetic without complaining and produces garbage. So the constructor accepts the string shape explicitly and validates it:

static paisa(amount: bigint | number | string): Money {
  if (typeof amount === 'bigint') return new Money(amount);
  if (typeof amount === 'number') {
    if (!Number.isInteger(amount)) throw new Error('Money.paisa requires integer input');
    return new Money(BigInt(amount));
  }
  if (!/^-?\d+$/.test(amount)) {
    throw new Error(`Money.paisa: invalid integer string "${amount}"`);
  }
  return new Money(BigInt(amount));
}

Second, the class has no escape hatch. No .toNumber(). No scalar multiply. No "split this into three equal parts" helper, because that helper is where the rounding bug lives. There are unit tests that assert those methods do not exist. A CI script rejects any money column declared outside the one custom Drizzle type that handles the bigint conversion.

Negative-existence tests feel silly to write. They are the only thing that stops a well-meaning future contributor from adding the convenience method that loses a paisa on every invoice.

eSewa's duplicate transaction UUID

Now the integration war story, because every payments post needs one.

eSewa's ePay v2 flow is a signed form POST. You build the fields, sign them, and the user's browser posts them to eSewa's form URL. The signature is HMAC-SHA256 over a specific comma-joined string, base64 encoded:

total_amount=100.00,transaction_uuid=<uuid>,product_code=<code>

The obvious server-side implementation is to POST that form from your backend, follow the redirect, and hand the user the resulting URL. It does not work, and the failure is fantastic: eSewa replies "Duplicate transaction UUID."

The reason is that the first POST registers the transaction. When the browser then arrives with the same UUID, eSewa sees a UUID it already knows and rejects it. Your server posting the form is the duplicate. You have to build and sign the fields, return them to the client, and let the browser do the one and only POST.

Two more things worth writing down. eSewa wants amounts as decimal rupee strings, so "100.00", not paisa, which means a conversion at exactly one boundary and nowhere else. And their status API returns NOT_FOUND for a transaction that exists but has not been paid yet. Treating NOT_FOUND as a terminal failure will cancel live payments during the window when the user is still typing their PIN. It is a transient state. Map it to pending.

Khalti, by contrast, is a clean JSON REST API. Its one sharp edge is the auth header, which must be exactly Key <secret>, capital K, lowercase rest, one space. Send anything else and the request fails without telling you why.

Both providers sit behind an interface whose only required method is initiate. Verification stays provider-specific, because the two APIs disagree about almost everything, but settlement converges on one path shared by the polling worker and the webhook controller. Same shape, same code, same tests. When a provider changes something, one adapter changes.

The month that isn't a month

Nepal's official calendar is Bikram Sambat, and it is not a Gregorian calendar with an offset. Months run 29 to 32 days. The lengths do not follow a formula. There is no closed-form conversion, only lookup tables that get extended when the government publishes them. It is currently in the 2080s.

This is a UI curiosity right up until it becomes an AML requirement.

Nepal's Financial Information Unit requires threshold transaction reports for aggregate customer activity of NPR 1,000,000 or more within one month, and it means the Nepali calendar month. Not a 30-day window, not the Gregorian month. The report is due within 15 days of the transactions. Suspicious transaction reports are due within three working days, and Nepal's weekly holiday is Saturday only, not the two-day weekend most date libraries assume.

So the AML aggregation job has to compute a Bikram Sambat month boundary, anchored to Asia/Kathmandu, which is UTC+05:45 and observes no daylight saving. Get any of those three wrong and you produce a report that crosses the threshold on the wrong day.

The month-length data is bit-packed, two bits per month, base 29:

export function daysInBsMonth(year: number, month: number): number {
  const delta = ENCODED_MONTH_LENGTHS[year - BS_YEAR_ZERO];
  if (delta === undefined) throw new Error(`No BS calendar data for year ${year} BS`);
  return 29 + ((delta >>> ((month - 1) << 1)) & 3);
}

The epoch is BS 1970-01-01 = AD 1913-04-13, and everything is whole-day arithmetic against that, with the Kathmandu offset applied so the result reflects Nepali wall-clock, not UTC. I copied the dataset verbatim from the same npm package the frontend uses, on purpose. Two independent implementations of a calendar with no formula will eventually disagree, and the disagreement will show up as a regulatory filing.

That the function throws for an unknown year is deliberate too. A calendar that silently extrapolates past its data is worse than one that stops.

The ledger you cannot UPDATE

The wallet ledger is append-only. Every credit and debit is a new row, and a correction is a reversing entry, never an edit. This is standard practice for anything that touches money, and every team says they do it.

Most teams enforce it in the service layer. Which is not enforcement. It is a convention with good intentions. Any script, any migration, any late-night psql session goes straight around it.

So the database role enforces it:

REVOKE UPDATE, DELETE ON wallet_ledger FROM trile_app;
REVOKE UPDATE, DELETE ON audit_log FROM trile_app;

The application role physically cannot rewrite history. The service layer also exposes no update path, so it is guarded twice, but the REVOKE is the one that survives someone being clever.

Two design details I would keep in any ledger I build again. Balance before and balance after are stored on every row, not derived. Deriving them means replaying the whole wallet across a timestamp range, and an auditor asking "what was the balance at 14:32" should get an answer from one row. And the amount column has a CHECK > 0 while direction carries the sign, so a signed amount can never disagree with its own direction field.

The audit log goes one step further and hash-chains each entry to the previous one, so tampering is detectable rather than merely difficult. Privileged staff actions run through a maker-checker engine where whoever initiates cannot approve, enforced server-side, not in the UI.

About the AI part

I should be straight about this. A large amount of this code was written with an AI agent driving, under a planning workflow that produced a research document and a plan per phase before any code got written.

That is the honest reason a backend, five frontend apps and a compliance pipeline came out of one person in three months. It is not the reason the design decisions are what they are. The agent did not know that eSewa rejects a server-side form POST, or that FIU means the Nepali calendar month. Every one of those came from reading a primary source and then writing the constraint down where it could be enforced.

It is also worth saying what it did not save me from. The two worst bugs in the project were found in a milestone audit, after every phase had passed its own verification. Both were integration bugs. The step-up re-authentication dialog in the frontend verified against the wrong endpoint, so it never wrote the freshness marker the backend guard reads, which meant every privileged write in the admin console returned 403. The other was a compliance action the backend implemented and the frontend never gave anyone a button to trigger. Each side was tested. Neither contract was.

That failure mode is not new and it is not AI-specific. But an agent working phase by phase will happily produce two internally consistent halves that do not meet in the middle, and it will report both as done. If you work this way, budget for an integration pass that exercises the real seam. Phase-level verification will not find it.

What I'd do differently

Verify the regulation before designing around it. I built a graduated KYC tier ladder before confirming that NRB's model is closer to binary, verified or not. The ladder still works, it just maps onto a floor and a ceiling that were not designed for it.

Deploy earlier. The public directory site is feature-complete, verified, and not live, because the API it reads from was never deployed to production. Everything buildable got built. The last mile turned out to be the part I could not do from inside the repo, and I found that out at the end rather than the beginning.

And write down where every number came from. The wallet cap table has a confidence column and a source pointer on every row. That felt like overhead when I added it. Then I found an amendment that moved some of the figures, and the confidence column was the only thing that told me which rows to re-check and which were still solid.

If you're building payments in a market the big processors skip, most of your difficulty will not be in your code. It will be in a scanned PDF, in a calendar with no formula, and in an API that fails with a message describing a problem you did not cause. Budget for that. It is most of the work.

Why free chess analysis is always capped at one game a day

Pukar Khanal — Sat, 22 Aug 2026 09:27:12 +0000

Most free chess game review gives you one game per day. Chess.com works that way, and so does almost every smaller site offering the feature. I assumed for a long time that this was just a paywall placed where it hurts.

It is partly that. But there is a real cost sitting behind the cap, and once I worked out what the cost was, I built my own analysis site differently.

The cost of one game review

Reviewing a 40 move game means evaluating about 80 positions. Give the engine two seconds on each one and you have spent close to three minutes of CPU. None of it is cacheable, because your game is not anyone else's game.

Run that on your own hardware and you pay for every minute. A thousand people reviewing one game a day is roughly 50 CPU hours daily, for a feature you are giving away. The quota is not greed. It is the number that stops the free tier from eating the company.

Which raises a more interesting question than "how do I price this". What happens if you delete the cost instead of rationing it?

Move the engine to the client

Stockfish compiles to WebAssembly. Put it in a Web Worker and the visitor's own processor spends those three minutes. Your server ships static files and never sees a chess position.

The whole free tier problem disappears, because there is no per-user cost left to control. Nothing to meter, so nothing to cap.

Getting started is unremarkable:

const engine = new Worker("stockfish.js");
engine.postMessage("uci");
engine.postMessage("isready");

After that you speak UCI over postMessage. Set a position, ask the engine to think, and read results off the message stream:

engine.postMessage(`position fen ${fen}`);
engine.postMessage(`go depth 15 movetime 2000`);

That is the pitch. Now the parts nobody mentions.

The protocol is strings, and it is asynchronous

UCI was designed for a pipe between two processes. You get that pipe, faithfully, with all of its ergonomics intact. The engine answers with lines like this:

info depth 15 seldepth 22 score cp -34 pv e2e4 e7e5 g1f3
bestmove e2e4 ponder e7e5

So you write regexes against engine output:

const cpMatch = output.match(/score cp (-?\d+)/);
const mateMatch = output.match(/score mate (-?\d+)/);

Two things about this bite you. The first is that info lines stream continuously as the search deepens, and only the last one before bestmove reflects the depth you asked for. Read the wrong line and your evaluation comes from a depth 4 search. You have to hold the most recent value and commit it when bestmove arrives.

The second is that a mate score is not a centipawn score. score mate 3 means mate in three, and if you feed it through the same /100 you use for centipawns you get an evaluation of 0.03 for a forced win. Handle it as a separate branch or your graph will show a winning position as dead level.

One engine, eighty positions

The obvious way to review a game is a loop over the moves. The obvious way is also wrong on the first attempt, because a Worker is a single engine and postMessage does not queue by request. Fire off 80 positions in a Promise.all and you get 80 sets of interleaved output from one engine with no way to tell which line belongs to which position.

So the loop has to be serial. Await each position, resolve on its bestmove, then send the next. In my case that means attaching a listener per position and removing it on resolve:

const listener = (event) => {
  const output = event.data;
  if (output.startsWith("bestmove")) {
    eng.removeEventListener("message", listener);
    resolve({ evaluation: bestEval, bestMove, engineLine });
  }
};

Forget the removeEventListener and every position after the first has listeners from all previous positions still attached, each one resolving a promise that has already resolved. It does not throw. It just quietly produces wrong results, which is worse.

Create the Worker once and terminate it on unmount. In React that is a useEffect with an empty dependency array and a cleanup that calls terminate(). Creating one per analysis leaks a Worker every time.

The thing I got wrong: threads

Stockfish is much stronger with multiple threads. Multi-threaded WASM needs SharedArrayBuffer, and since Spectre, browsers only hand you SharedArrayBuffer on a cross origin isolated page. That means two response headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

My site does not send them. I checked while writing this, which is a slightly embarrassing way to find out. So every analysis on chessdream.app today runs single threaded, and my depth 15 default is doing more work than it needs to for the strength it delivers.

The reason it is not a one line fix is require-corp. Turning it on breaks every cross origin resource that does not opt in with CORP headers, which on my site means the ad script and the analytics tags. That is a real tradeoff and not obviously worth it, given single threaded Stockfish at depth 15 already plays far above any human who is using a free analysis site to review their blitz games.

Worth knowing before you promise yourself threads.

Turning evaluations into words

Users do not want centipawns. They want to be told that move 23 was the blunder. So you take the evaluation delta between consecutive positions and bucket it:

if (moveUci === bestMove || bestMoveSan === moveSan) {
  if (evalDiff > 2) return "brilliant";
  if (evalDiff > 1) return "great";
  return "best";
}
if (evalDiff >= 0) return "excellent";
// ...
if (evalDiff < -1.5) return "blunder";

I want to be honest that these thresholds are judgment, not mathematics. There is no objective centipawn value at which a move becomes a blunder. Every site that labels moves picked numbers that felt right, mine included, and the labels are a user interface decision wearing the costume of an engine output.

One asymmetry to remember: the delta is from the mover's perspective. Black losing half a pawn is evalDiff positive in raw terms and negative in meaning, so you flip the sign for black before bucketing. Skip that and half your board gets praised for its mistakes.

What you actually pay

Nothing here is free. Moving the engine to the client trades your costs for the user's.

The download is real. On my deployment stockfish.wasm is 546KB, plus 146KB of loader. There is also a 2.6MB asm.js fallback for browsers without WASM, which in 2026 is close to nobody, and I should probably drop it.

Results vary by device, which is the part I find genuinely annoying. The same position on the same site gives a different evaluation on a four year old phone than on a desktop, because the phone reaches a lower depth in the same two seconds. Server side analysis is consistent for everyone. Client side analysis is as good as whatever the visitor is holding.

And you get no telemetry on analysis quality, because the analysis never touches your servers. That is the same property that lets you promise nothing is uploaded. You cannot have both.

Was it worth it

For this use case, yes, and not mainly for the cost saving.

The privacy claim turns out to be the part people react to. "Your games never leave your browser" is not a policy or a promise to be trusted. It is a description of where the code runs, and anyone can open devtools and confirm there is no request. I did not expect that to matter as much as it does.

The unlimited analysis follows from the architecture rather than from generosity. I am not choosing to be nice. There is simply no meter to read, so there is nothing to cap, and a business decision I would otherwise have had to make repeatedly is just gone.

If you are building something where the expensive per-user work could run on the user's machine, it is worth pricing out the client side version before you design a quota. The quota is often just the shadow of a server bill.

Site is at chessdream.app if you want to see it running. Happy to answer questions about the Worker plumbing, it is the part I spent the most time getting wrong.