Building for Bangladesh: AI Easy Access

A practical guide for developers who want to use AI to build something meaningful — and a proof of concept showing how the payment barrier can be removed so anyone can start.

---

AI Is Already Here — The Question Is What We Build with It

Artificial intelligence has moved from research labs into everyday life. A doctor can use it to process notes faster. A teacher can generate lesson materials in Bangla. A developer can build tools that would have taken a full team just a few years ago. A farmer can ask it questions and get advice tailored to local conditions.

The technology is real, accessible, and powerful enough to solve genuinely difficult problems. The free tiers of ChatGPT, Claude, and Gemini already give anyone with a phone and internet access a taste of what is possible.

But there is a difference between using AI as a tool and building with AI as a platform.

When a developer in Bangladesh wants to create something an app that helps students study in Bangla, a tool that assists healthcare workers with records, a service that helps small businesses communicate with customers — they need to connect AI to what they are building. That means API access. And API access to the most capable AI systems in the world OpenAI’s GPT models, Anthropic’s Claude, Google’s Gemini almost always requires an international payment card. A Visa or Mastercard billed in US dollars.

That single requirement shuts out a huge number of talented, motivated developers in Bangladesh. Not because they cannot afford the cost of using AI. Because the payment method simply is not available to most people here.

This is the access problem. And this proof of concept is an attempt to solve it.

---

The Access Problem Being Solved

Bangladesh has MFS (Mobile Financial Services). These are mobile payment wallets: bKash, Nagad, Rocket and others that between them move billions of taka every month. People pay bills, send money across the country, run small businesses entirely through their phones. The financial infrastructure works, it just does not connect to the international payment rails that OpenAI, Anthropic, and Google require.

The result is a structural gap. A developer who could build something genuinely useful, a mental health support tool, a legal aid assistant, an agricultural advisory app is blocked not by skill or ambition or the cost of AI, but by a payment method mismatch.

There is also a second layer to the problem. Even developers who manage to get API access — through a friend abroad, a workaround, a borrowed card are building on an unstable foundation. They cannot build a real service for other Bangladeshi users on that basis. The platform itself needs a sustainable local payment model.

The Bangladesh LLM Access Platform proof of concept addresses both layers:

• It gives individual developers frictionless local payment access to paid AI APIs
• It provides a blueprint that anyone can use to run this kind of platform for their own community

---

The High-Level Architecture of the Proof of Concept

The proof of concept is built around four open-source components. Each handles a distinct responsibility. Together they form a complete request pipeline — from a user typing a question to a response arriving on their screen, with every token counted and every taka deducted along the way.

Bifrost is the AI gateway. Every request from the application hits Bifrost first. Bifrost reads its provider configuration, translates the request into the format the target provider expects, OpenAI, Claude, Gemini, or a self-hosted model and forwards it. When the response comes back, Bifrost passes it upstream along with the token count. The application never calls any AI provider directly. Bifrost is the single entry point, the same way an API gateway sits in front of backend microservices.

Lago is the billing meter. After each request completes, the application fires a usage event to Lago: user ID, model used, token count. Lago looks up the configured price per token for that model, calculates the taka cost, and deducts it from the user’s prepaid wallet in real time. No batch processing, no end-of-month invoice, the balance drops the moment the response is served.

Kill Bill is the subscription engine. It does not sit in the live request path. Instead it manages the plan layer: what credit package a user is subscribed to, when the billing cycle renews, and how much taka gets credited to their Lago wallet at each renewal. An operator can offer a 500 taka/month plan, Kill Bill handles the recurring logic, Lago handles what gets spent against it.

The MFS integration is the local payment layer. Users top up using MFS, bKash, Nagad, Rocket and others. When payment is confirmed, the provider sends a webhook to the platform, which credits the user’s Lago wallet in taka. This is the only point where local money enters the system.

The operator holds the international side: they pay AI provider bills in USD from their own card. Users only ever see taka. The platform sits between the two, bridging local mobile money and global AI APIs.

The diagram above shows the full request flow end to end. A client, mobile app, web app, or developer SDK — sends an HTTP request to the app server, which handles authentication and rate limiting before passing the request down to Bifrost. Bifrost reads its provider configuration and forwards the request to the selected LLM provider: OpenAI, Claude, Gemini, or a self-hosted model via Ollama. The provider processes the prompt and returns a response with a token count. That response travels back up through Bifrost to the app server and on to the client.

In parallel, the token count from the completed request triggers a usage event that flows into Lago. Lago’s cost engine looks up the price per token for the model used, calculates the taka amount, and deducts it from the user’s prepaid BDT wallet in real time. The wallet was funded earlier through the MFS top-up path bKash, Nagad, Rocket or others, which credits the balance via a webhook when payment is confirmed. Kill Bill sits alongside this, managing the subscription layer: when a user’s monthly plan cycle fires, Kill Bill triggers a wallet credit so the balance is ready before the next batch of requests.

---

The Implementation Approach

Building this proof of concept involves three layers of work, each with a different character.

The infrastructure layer is Bifrost, Lago, and Kill Bill, deployed on servers the operator controls — ideally hosted within Bangladesh. All three are open source. Bifrost is configured with the API credentials for whichever AI providers the operator wants to offer. Lago is configured as the metering engine: price per token per model, wallet structure, low-balance thresholds. Kill Bill sits alongside Lago managing the subscription layer: plan definitions, billing cycles, and operator-level account management.

The application layer is the software users interact with — a web app, a mobile app, or a developer API. It handles user accounts, authentication, and the wallet top-up experience. After each AI request, it fires a usage event to Lago. Plan management and upgrades flow through Kill Bill. This layer is standard software development the only PoC-specific pieces are the Bifrost integration for sending requests and the Lago and Kill Bill integrations for recording usage and managing plans.

The local payment layer is the integration with MFS providers: bKash, Nagad, Rocket and others whichever mobile payment wallet the operator supports. The user initiates a top-up, the payment provider sends a webhook confirmation, and the platform credits the user’s wallet. This layer is the most variable local payment APIs differ in their webhook formats, settlement timing, and error handling and it is where the most real-world testing is needed before a production deployment.

In the proof of concept, the local payment layer was simulated with a test webhook. The Bifrost, Lago, and Kill Bill layers ran against real configuration. The core loop request in, tokens counted, wallet debited was demonstrated end to end.

---

Why Bifrost, and also Lago or KillBill?

Why Bifrost?

Without a gateway, the platform would need to write and maintain separate integration code for every AI provider. OpenAI’s API format differs from Anthropic’s, which differs from Google’s. Every provider change means code changes.

Bifrost solves this with a single consistent interface. The platform sends every request to Bifrost. Bifrost handles the provider-specific formatting and routing. Switching providers or adding a new one requires changing one configuration setting, not rewriting application code.

Bifrost is open source, free to use, built by Maxim, and supports over fifteen providers including OpenAI, Claude, Gemini, AWS Bedrock, Mistral, and locally hosted models via Ollama. It is written in Go, adds under fifteen microseconds of overhead per request, and can be self-hosted entirely within Bangladesh.

The provider flexibility matters beyond convenience. If a provider restricts access to Bangladesh, changes pricing significantly, or a more accessible regional alternative emerges — the platform adapts by changing configuration, not rebuilding.

Why Lago?

Every AI request consumes tokens. Tokens cost money. That cost needs to be calculated per model, deducted from the user’s prepaid wallet in real time, and logged for audit purposes all without manual intervention.

This is a metering problem, not a subscription problem. Lago is built specifically as a usage metering engine. After each request, the platform fires a usage event to Lago, 500 tokens used, model GPT-4o, user ID and Lago handles the rest: cost calculation, wallet deduction, balance tracking, and low-balance alerts.

Lago is open source and self-hostable within Bangladesh, meaning user financial data stays local. Building this metering layer from scratch would take months and introduce significant risk. Lago makes it a configuration task.

The honest tradeoff: Lago has a real learning curve. Initial setup is not trivial, and some billing concepts require careful documentation reading. Budget time for this.

Why Kill Bill?

Lago handles the per-request metering. Kill Bill handles everything around it, the plan structure that determines what a user or operator is entitled to.

A platform with no subscription layer is just a pay-as-you-go meter. That works, but as the platform grows it becomes limiting. Operators may want to offer monthly credit packages, buy 500 taka of AI credit per month on a recurring basis. Enterprise users may need account-level billing. The platform operator itself may charge for access via tiers. Kill Bill is built to manage exactly this: subscription plans, billing cycles, plan upgrades and downgrades, and renewal logic.

Kill Bill is an open-source subscription billing and payments platform with over ten years of production use. It is self-hostable and sits cleanly alongside Lago Lago meters what was used, Kill Bill manages the plan around it. Together they cover the full billing stack: usage metering and subscription management.

Also why a Hosted AI Provider could be an option?

The primary value of the platform is making the paid APIs: OpenAI, Claude, Gemini — accessible through local payment. These are the most capable and most widely used AI systems in the world. Connecting Bangladeshi developers to these providers is the core goal.

Each provider has different strengths. OpenAI’s GPT models are the most widely documented and supported. Claude is strong for nuanced writing and coding with careful reasoning. Gemini offers a generous free tier API that reduces cost for operators and users, and supports multimodal inputs including images.

And another option, self-hosted models via Ollama, allows the platform to route to a model running entirely on the operator’s own server, using open models like Qwen or LLaMA. No external API cost, no foreign payment, no data leaving the country. This is a more technically involved setup but a meaningful option for operators who want full independence or lower ongoing costs. Bifrost routes to a self-hosted model exactly the same way as to any hosted provider the rest of the system does not change.

Self hosting LLM model does cost but its way cheaper option if you can invest once.

How Local Payment Top-Up Fits Into the System

The local payment layer is what makes the platform specifically work for Bangladesh.

Users top up their platform wallet using MFS: bKash, Nagad, Rocket and others — the same mobile payment wallets they already use every day. They do not need to understand exchange rates, foreign accounts, or API billing. They add taka, they use AI, their balance goes down. When it runs low, they top up again.

The technical mechanism is a webhook integration. When a user completes an MFS payment through bKash, Nagad, Rocket or others; the payment provider sends an automatic notification, a webhook, to the platform. The platform verifies the notification and credits the user’s wallet with the paid amount in taka. This happens automatically, without manual intervention.

The operator handles what the user never sees: receiving taka from local payments and paying USD to AI providers. The platform sits between the two, holding the international payment relationship on one side and the local payment relationship on the other.

One important production consideration: most local MFS providers do not settle in real time. There can be a gap between when a user initiates a payment and when the webhook arrives confirming funds. During this window the platform must decide whether to extend provisional credit or hold access until settlement is confirmed. The proof of concept assumes instant confirmation. A real deployment needs a clear policy for this gap.

---

Key Lessons from the Prototype

The core loop works and is not complicated to build. Getting the full flow running request in, tokens counted, wallet debited took days, not months. The architecture is sound.

The payment layer is where the real work is. Bifrost and Lago are straightforward to configure. Understanding MFS provider APIs, their webhook behaviour, and settlement timing is where most of the real-world effort goes.

Lago and Kill Bill serve different layers. Lago handles every individual request in real time tokens, cost, deduction. Kill Bill handles the slower subscription layer, plans, cycles, renewals. They are designed for different problems and work well together.

Regulatory and currency questions cannot be solved with code. Holding prepaid taka balances may require Bangladesh Bank authorisation. MFS merchant status requires business registration and KYC. Exchange rate exposure between taka and USD needs a deliberate pricing strategy. These are real barriers to production that engineering alone cannot clear.

This is infrastructure, not a single app. The most important finding is that this stack is a reusable pattern. Any developer or team in Bangladesh can take it, deploy it, and build many different products on top. The goal is a foundation, not one product.

---

What Becomes Possible

Remove the payment barrier and a developer in Dhaka has access to the same building blocks as a developer anywhere in the world. The free tiers of ChatGPT and Gemini can answer questions. What API access enables is something different, persistent pipelines, programmatic integration, and systems that run without a human in the loop.

An agricultural research team can build a system that ingests satellite imagery, soil sensor data, and local weather feeds, then uses a vision-capable model to detect early-stage blast disease in paddy fields before it is visible to the eye, alerting farmers by SMS days before yields are affected. A climate research group can combine historical rainfall data with real-time river gauge readings and run multimodal AI inference to predict flash flood risk by union, giving local government hours of advance warning rather than minutes.

A hospital network can build a triage pipeline that processes incoming patient notes, flags high-risk indicators for sepsis or maternal complications, and surfaces them to the duty doctor — not a chatbot, but a clinical decision support system running on structured medical data. A legal aid organisation can build a system that reads court documents, cross-references case law, and generates jurisdiction-specific summaries in Bangla for clients who cannot afford representation — the kind of document processing that requires sustained API calls across large contexts, not a single free-tier query.

These are not simple tools. They are pipelines — systems that call AI APIs repeatedly, programmatically, at scale, integrated into real workflows. That class of application requires reliable, affordable API access. The proof of concept here demonstrates that the infrastructure to support it can be built in Bangladesh, paid for in taka, and owned entirely by the people running it.

---

This article is part of an ongoing series on open-source infrastructure and AI accessibility in Bangladesh and beyond.