DEV Community: Induwara Ashinsana

Apple's AI Cost Squeeze Is a Warning for Builders Here

Induwara Ashinsana — Thu, 18 Jun 2026 07:51:41 +0000

The story that Apple may raise iPhone prices because of AI is not really a phone story. It is a memory-chip story, and that should get your attention whether you build software in Colombo or just want to buy a laptop that lasts. According to TechCrunch, Apple CEO Tim Cook described the current situation as "unsustainable" in a recent interview.

When the most cash-rich hardware company on earth says the component math no longer works, the rest of us should read the rest of the bill before it lands.

🔍 Why the AI boom shows up on a phone price tag

The unintuitive part is that Apple does not need to ship a single new AI feature to feel this. The AI build-out runs on the same memory that goes into phones, laptops, and consoles. Data centres buying memory by the truckload pull supply away from everyone else, and prices climb for the leftover stock.

So the chain looks like this:

AI companies buy enormous amounts of high-end memory for training and inference.
Memory makers prioritise that demand because the margins are better.
Consumer-device makers like Apple pay more for the same parts they always bought.
Some of that cost reaches the buyer.

Key takeaway: The AI boom is not just a software cost. It is bidding up the physical parts inside ordinary devices, and that pressure flows downstream to anyone who buys hardware.

💰 What "unsustainable" looks like by the time it reaches Sri Lanka

A global component squeeze never arrives here at face value. A price bump that looks small in the US gets multiplied by the cost of getting the device into the country and onto a shelf.

Cost layer	Who adds it	Effect on the final price
Higher memory cost	Component makers	Baseline goes up for everyone
Manufacturer margin	Apple and rivals	Bump preserved, not absorbed
Import duty + taxes	Local landed cost	Multiplies the bump
Forex on the rupee	Exchange rate	Adds another layer
Retailer margin	Local seller	Final shelf price

I am not quoting a figure here because the source does not give one, and inventing a percentage would be worse than useless. The point is structural: a modest factory-gate increase is rarely modest by the time it clears customs and gets priced in rupees. If you were already stretching for a flagship phone or a 16GB laptop, this is the year to expect the goalposts to move.

⚡ The lesson for builders: buy less hardware, rent more compute

Here is where this stops being news and becomes a decision. If memory is the bottleneck, the smart move for a small team or a student is to avoid owning the expensive part wherever you can.

Do not over-spec your dev machine "for AI." A maxed-out RAM config is exactly the part getting more expensive. Buy what your current work needs, not a forecast.
Lean on free tiers and rented compute for the heavy stuff. Training and large-model inference belong in someone else's data centre, where the per-hour cost is shared.
Self-host only when the math beats renting. That calculation just shifted, because the hardware you would buy to self-host is the thing inflating.

Before you commit money to your own GPU box, run the comparison honestly. Our AI self-hosting cost calculator lets you put the upfront hardware spend against a cloud bill over time, and a memory squeeze pushes that break-even point further out than most people assume.

If the part you would buy is the part getting scarce, renting it by the hour is not a compromise. It is the rational call until supply loosens.

🛠️ A simple framework for your next hardware decision

When component prices are moving against you, the worst thing to do is freeze. The second worst is to panic-buy. Here is the order I would think through it.

Question	If yes	If no
Can a free or cheap cloud tier do this job?	Use it, own nothing	Move to next question
Will I run this workload daily for a year+?	Self-hosting may pay off	Rent per hour
Is the device's memory the limiting part?	Expect price pressure, time the buy	Buy on normal cycle
Can I extend my current machine's life?	Do that first	Replace deliberately

Most builders here will land on "use the cloud tier and keep the old machine running another year." That is not a downgrade. It is matching your spend to a market that has temporarily turned against hardware buyers.

🌐 The bigger pattern worth watching

There is a quieter signal in Cook's word choice. "Unsustainable" is not a complaint about one quarter. It is a statement that the current trade-off cannot continue as-is, which means something has to give: prices rise, supply expands, or AI demand cools. All three are slow.

For the rest of us, that means the squeeze is not a one-week headline. Treat elevated memory prices as the baseline for the next while, not a blip to wait out.

Bottom line: When a company with Apple's buying power calls its component costs unsustainable, smaller buyers should assume the pressure on them is worse, and plan spending around it.

What this means for you

If you are buying a phone or laptop this year, expect the AI hardware boom to be quietly baked into the price, and expect the rupee version of that increase to be larger than the headline. Time non-urgent purchases, and do not pay a premium for memory you will not use soon.

If you are building, the move is the same one that has always served small teams well, just with sharper edges now: own as little of the expensive hardware as you can, push the heavy compute to shared infrastructure, and only buy your own box when the numbers clearly beat renting. Run that break-even before you spend, because the AI boom just changed the inputs.

Apple can absorb a bad year. Most of us are better off planning around it.

Vercel Functions Hit 30 Minutes: What It Means for You

Induwara Ashinsana — Tue, 16 Jun 2026 15:11:27 +0000

The headline is simple: Vercel Functions can now run up to 30 minutes, on the Node.js and Python runtimes, for Pro and Enterprise teams. That's more than 2x the previous 800-second ceiling. The detail worth thinking about is why a serverless platform whose whole pitch was "short, stateless, scale-to-zero" suddenly wants your code to run for half an hour.

I read this less as "longer timeouts" and more as Vercel quietly admitting that the AI era broke the old serverless contract. Full announcement is on the Vercel changelog.

⏱️ The number that actually changed

Here's the before-and-after, straight from the source:

	Previous limit	New limit
Max function duration	800 seconds (~13.3 min)	30 minutes (1800s)
Runtimes supported	—	Node.js, Python (more "coming soon")
Plan required	—	Pro and Enterprise
Above 800s	—	Beta, requires Fluid Compute

Key takeaway: This isn't a small bump. Going from ~13 minutes to 30 minutes more than doubles the window, and it targets exactly one kind of workload: jobs that wait on something slow.

The "coming soon" on additional runtimes matters if you're on Go, Rust, or an edge runtime. As of this writing, the 30-minute window is Node and Python only. Don't assume your stack is covered until you check.

🤖 Why serverless and AI stopped getting along

The original serverless deal was: respond fast, hold no state, scale to zero. That fit web requests. It does not fit a single LLM call that streams a long chain of reasoning and tool calls for several minutes.

Vercel lists the workloads driving this, and they read like a list of everything people are building right now:

Long LLM reasoning and multi-step tool calls
AI responses that stream for several minutes
Document and media processing
OCR and extraction
Web scraping and browser automation
Complex workflow steps or queue handlers

The pattern across all six: most of the clock is spent waiting, not computing. Waiting on a model, a database, a third-party API.

If you've ever shipped a feature that pulls text out of scanned documents, you know this wait. We run a free image-to-text OCR tool on this site, and the slow part is never the CPU. It's the model round-trip. That's the exact shape of work this change is built for.

💰 Fluid Compute and the billing trick that makes it affordable

A 30-minute function sounds expensive. The reason it isn't, according to Vercel, is Fluid Compute and how it bills CPU.

Active CPU billing only applies while your code is actually executing. It pauses while your function waits on I/O, such as AI model calls, database queries, and third-party APIs.

This is the part I'd underline for any small team watching its cloud bill. In a naive serverless model, a function that calls an LLM and sits idle for 90 seconds would bill you for all 90 seconds. With active-CPU billing, you're charged for the milliseconds of actual compute, not the idle wait.

Scenario	Naive billing	Active CPU billing
3-min LLM call, mostly idle	Bills ~3 min	Bills only execution slices
OCR job waiting on model API	Bills full wait	Pauses during I/O wait
Web scrape with network stalls	Bills the stalls	Pauses during stalls

One caveat the changelog is explicit about: durations above 800 seconds are in beta and require Fluid Compute. So the long timeout and the cheap billing are tied together. You can't get the 30-minute window on the old compute model.

🛠️ How you actually turn it on

You opt in with maxDuration. You don't get long runs by default, which is sensible, a runaway function shouldn't silently bill you for half an hour.

For Next.js App Router, you set it in the route file:

// app/api/long-job/route.js
export const maxDuration = 1800 // seconds = 30 minutes

For other runtimes and frameworks, you configure it per function path in vercel.json:

{
  "functions": {
    "api/long-job.py": { "maxDuration": 1800 }
  }
}

A few things I'd check before leaning on this:

Confirm your plan. It's Pro and Enterprise only. Hobby projects don't get the long window.
Confirm your runtime. Node and Python today; others "coming soon."
Confirm Fluid Compute is on. Above 800s requires it, and it's still beta.
Set a realistic ceiling. 1800 is the max, not a target. If your job needs 4 minutes, set ~300, not 1800.

💡 What this means for you

If you're a student or solo builder in Sri Lanka shipping side projects on a free or low tier, the headline number doesn't change your day directly, the 30-minute window is gated behind paid plans. But the direction matters, and it's worth understanding even before you pay for it.

For small teams already on Pro, this removes a specific class of ugly workaround. The pattern of "spin up a separate worker queue just because my AI call might take 11 minutes" gets simpler. You can keep more of your pipeline inside one function instead of stitching together a queue, a worker, and a polling endpoint.

Bottom line: The long timeout is for I/O-bound, mostly-waiting work, AI calls, OCR, scraping, media processing. If your job is CPU-bound and genuinely computes for 25 minutes, serverless is still the wrong tool, and you'll feel that on the bill. Match the feature to the workload, not the hype.

My honest read: this is a useful, narrow change. It won't replace your background job system for heavy compute, and it isn't meant to. It just makes the increasingly common "my function spends most of its life waiting on a model" pattern stop fighting the platform. For the kind of AI-glue features most of us are building this year, that's a quietly practical fix.

Anthropic's India block is a warning for Sri Lankan builders

Induwara Ashinsana — Mon, 15 Jun 2026 18:53:59 +0000

The news that Anthropic suspended access to its newest models for foreign nationals should make every Sri Lankan who builds on a US AI API stop and think. If a market the size of India can be cut off, a team in Colombo has even less leverage. The whole episode is a reminder that an API key is not a guarantee.

The story comes from TechCrunch's report, As Anthropic suspends access to new models, India debates its AI future. I'm not republishing it. I want to talk about what it means if you're shipping software from a country that has no seat at the table where these decisions get made.

🔍 What actually happened

According to TechCrunch, Anthropic restricted access to its newly launched Fable 5 and Mythos 5 models for all foreign nationals, including its own foreign employees, after a US government directive on Friday, June 13, 2026. The report notes the move landed right after Anthropic announced an India partnership with Tata Consultancy Services, and that the White House pointed to Anthropic's handling of alleged jailbreak vulnerabilities. Anthropic disputed that characterization.

Key takeaway: The restriction wasn't about price, capacity, or a billing dispute. It was a government order about who gets to use a model. That is a category of risk most of us never put in our architecture diagrams.

The detail that matters for the rest of us is who India is to these companies. TechCrunch reports India is the second-largest market for both Anthropic and OpenAI after the US. If the second-largest market can be affected by a directive overnight, "we're a paying customer" is not the protection people assume it is.

📊 Why a Sri Lankan team should care more, not less

India has options Sri Lanka doesn't. The report quotes former Infosys executive Mohandas Pai proposing a ₹500 billion annual AI fund and a ₹2 trillion credit guarantee, against India's current IndiaAI Mission budget of ₹103.72 billion over five years. Those are numbers a national program argues about. We are not building national compute funds. We are individuals and small teams renting intelligence by the token.

Here's how I'd frame the exposure for a small builder here:

Dependency	What breaks if access is cut	Realistic fallback
One frontier API for everything	Whole product stops	Painful rewrite under pressure
Provider abstraction layer	One provider degrades, others hold	Swap model, keep shipping
Self-hosted open model	Nothing external can revoke it	Lower ceiling, full control

The teams that will be fine are the ones who treated their model provider as one interchangeable part, not the foundation.

💡 The open-source argument just got louder

The most useful voice in the TechCrunch piece, for a builder on a budget, is Zoho founder Sridhar Vembu, who urged embracing smaller and open-source models. That's not nationalism for us in Sri Lanka. It's plain risk management plus cost control, which is the same reason most of us reach for open weights anyway.

What "smaller and open-source" looks like in practice when you can't assume frontier access:

Run a quantized open model locally for the parts of your product that don't need a frontier brain. A lot of summarizing, classifying, and extraction work runs fine on a model you fully control.
Reserve the expensive hosted model for the genuinely hard 10% of requests, behind a switch you can flip.
Keep at least two providers wired up so a single directive, outage, or price hike doesn't end your week.
Cache aggressively. Every cached response is one you don't pay for and one a policy change can't take away.

If your roadmap assumes one specific model from one specific company will always be available to you, you don't have a roadmap. You have a hope.

This is the philosophy behind the free AI tools on induwara.lk. They lean on open, swappable models precisely so they keep working regardless of which frontier provider is having a bad month. That's not a coincidence. It's the lesson of stories like this one applied early.

⚡ The geopolitics part you can't engineer around

Policy expert Prasanto Roy is quoted warning that "American AI models are bound to American geopolitics." That line is the whole article in seven words. Atomicwork CEO Vijay Rayapati put the commercial edge on it: "If your AI team is not made up entirely of U.S. citizens, you are at a competitive disadvantage."

For a Sri Lankan founder selling to global customers, sit with that. It means:

The model under your product can change terms for reasons that have nothing to do with you.
Your nationality, or your team's, could one day be a factor you can't fix with money.
"Sovereign AI," a phrase Activate founder Aakrit Vaish said this episode materially shifts thinking on, is really just a country wanting the same insurance you should want for your product.

You can't out-engineer geopolitics. But you can refuse to bet your only copy of the product on it.

🛠️ What this means for you

If you build software in Sri Lanka and AI is anywhere in it, treat this week as a free stress test. A few concrete moves:

Audit your single points of failure. Grep your codebase for hardcoded model names and provider clients. Every one is a place a directive could reach.
Put a provider abstraction in now, while nothing is on fire. A thin interface that lets you swap models is an afternoon of work and a lot of future calm.
Prototype the open-source fallback for your most common request type. You want to know it works before you need it, not during an outage.
Don't panic-migrate. Frontier models are still the best tools for hard problems. The point isn't to abandon them. It's to never be unable to walk away.

Bottom line: The cheapest insurance in AI right now is optionality. Build so that losing any one model is an inconvenience, not an extinction event. India is debating its AI future with billions. We get to debate ours one architecture decision at a time, and those decisions are entirely ours to make.

Mistral's €20B Valuation: Why It Matters to SL Builders

Induwara Ashinsana — Sun, 14 Jun 2026 22:30:53 +0000

Mistral's €20B valuation is the kind of headline I usually scroll past, but this one is worth a pause. According to a TechCrunch report from 12 June 2026, the French AI lab is rumoured to be raising €3 billion at a valuation of around €20 billion (about $23.15 billion), nearly double its Series C valuation of €11.7 billion.

I don't have a billion euros, and neither do you. So why should a student in Colombo or a two-person startup in Galle care about a European funding rumour? Because of what Mistral funds, not what it's worth.

📊 The numbers, in plain terms

Here's the rumoured round next to the last known valuation, straight from the source:

Metric	Figure
Reported raise	€3 billion
New valuation	~€20 billion (~$23.15 billion)
Previous (Series C) valuation	€11.7 billion
Roughly	Nearly 2× the Series C
Source	TechCrunch, 12 Jun 2026

Key takeaway: A valuation jumping from €11.7B to ~€20B is the market betting that an open-weight-friendly lab can keep up with the closed frontier labs. That bet, if it pays off, keeps a cheap lane open for the rest of us.

I want to be careful here: this is reported as a rumour, not a closed deal. No signed terms, no confirmed investors that I'd stake a claim on. Treat the figures as "what's being reported," not gospel.

🌐 Why a European lab matters for the cheap lane

Most of the AI tools you and I reach for are priced in US dollars and tuned for American or Chinese infrastructure. Mistral has built its name on releasing models you can actually download and run yourself, instead of only renting them through an API you can never inspect.

That distinction matters more in Sri Lanka than in San Francisco:

Currency risk. Every API call billed in USD is exposed to the LKR exchange rate. A model you can host once and reuse caps that risk.
Data control. If a model runs on your own machine or a cloud box you rent, your users' data never leaves your control. For anyone handling local customer records, that's not a nice-to-have.
No vendor lock-in. Open weights mean the model still works even if the company changes its pricing, its terms, or its mind.

A bigger war chest for Mistral is, indirectly, fuel for that whole approach. The more credible the open-weight lane stays, the less leverage any single closed provider has over your roadmap.

💰 What "well-funded" does and doesn't change for you

Funding rounds are exciting for founders and boring for users until they translate into something you can touch. Here's my honest read on what a €3B raise might and might not change for a small builder:

What it could help	What it won't fix on its own
More frequent model releases	Your GPU bill if you self-host
Better non-English coverage over time	The learning curve of running models locally
Longer company runway (less risk of shutdown)	Your need to actually measure costs before shipping
More competition pushing prices down	Hallucinations and the need to verify outputs

The trap is reading "huge valuation" as "I should adopt this now." A valuation is a bet on the future. Your decision should rest on whether a specific model, at a specific price, solves a specific problem you have this month.

Don't buy the hype. Buy the benchmark that matches your use case, at a price your project can survive.

🛠️ How to actually act on this from Sri Lanka

If the news nudges you to take open-weight models seriously, do it with numbers, not vibes. Here's the sequence I'd follow:

Pin down your workload. Is it short prompts at high volume, or long documents at low volume? The answer flips which model and which hosting choice is cheapest.
Estimate token usage before you commit. Rough out how many tokens a typical request will burn so cost projections aren't guesswork. Our AI token counter gives you that baseline fast.
Compare hosting routes. Renting an API is convenient; renting a GPU and self-hosting an open-weight model can be cheaper at scale, or far more expensive at low volume. Run the maths with the AI self-hosting cost calculator before you decide.
Put models side by side. Don't pick on brand. The AI model comparison tool lets you weigh options on context window, price, and capability together.
Start small and measure. Ship one feature, log real token usage for a week, then project. Real data beats a launch-day estimate every time.

The headline cost difference between "rent an API" and "host your own" is rarely obvious until you plug in your own volume. For a low-traffic side project, a hosted API is almost always cheaper than paying for a GPU that sits idle. For a tool getting steady daily use, the equation can flip hard.

💡 What this means for you

A €20B valuation for Mistral isn't a reason to switch your stack tomorrow. It's a signal that the open-weight, run-it-yourself approach to AI has serious money behind it, which is good news if you're building on a learning budget and want options that aren't controlled by a single US provider.

For a Sri Lankan engineer, the practical move is unchanged: pick the model that fits the job, price it honestly in LKR terms, and verify before you ship. The funding round just makes me more confident the cheap lane will still be there next year.

If you're weighing your own AI costs this week, start with the token counter and the self-hosting cost calculator, then decide with numbers in front of you. That's the only part of this story you can actually control.

AI Scam Texts Are Now $88/Week. Here's What That Means

Induwara Ashinsana — Sun, 14 Jun 2026 02:07:56 +0000

An AI-powered phishing kit that pumps out scam text messages now rents for less than a month of most streaming subscriptions. That's the number I can't stop thinking about after reading TechCrunch's report that Google sued an alleged Chinese cybercrime operation called Outsider Enterprise.

The group sent 2.5 million text messages in two weeks and scammed hundreds of thousands of victims. But the figure that should worry every builder and small-team founder reading this isn't the volume. It's that the tooling reportedly rents for $88 a week.

🔍 The economics just flipped against defenders

For years, running phishing at scale took real effort: building convincing fake sites, writing copy that didn't read like a bad translation, and rotating domains faster than they got blocked. According to Google's complaint, Outsider Enterprise sold all of that as a subscription product.

What they allegedly sold	Detail from the complaint
Phishing-as-a-service kit	$88/week or $200/month
Pre-built fake-site templates	290+ mimicking legitimate brands
Fake websites deployed	9,000 live sites
Fraudulent domains	Around 1 million
AI used to generate the fake sites	Google's Gemini, per Google's filing

The part I find most telling is the last row. Google is accusing a scam operation of using Google's own Gemini to build the fake pages, then hosting some of them on Google Drive and Google Cloud. The same generative tools we use to ship products faster also lower the cost of faking those products.

Key takeaway: AI didn't invent phishing. It removed the two things that used to limit it — the cost of writing convincing content and the skill of building fake sites at scale.

📊 Why the message volume is the real story

Volume is what turns a clever scam into an industrial one. Google said Android users flagged 55,000 spam texts in two weeks this past May, which it described as more than two spam complaints a minute.

Put the numbers next to each other and the asymmetry is obvious:

2.5 million texts sent in two weeks
36,000 payment cards reportedly stolen from institutions in 95 countries
The FBI estimates roughly $1.9 billion in losses tied to this kind of stolen-card activity

A campaign like this doesn't need a high hit rate. If one in a thousand recipients taps the link and enters a card number, the operator still wins, because sending the next million messages costs almost nothing. That math is why smishing (SMS phishing) keeps growing, and it's the same math that lands fake "your parcel is held at customs, pay the fee" texts in Sri Lankan inboxes every week.

🛠️ How to actually tell a real link from a fake one

You don't need a security team to defend against this. You need a couple of habits that survive a convincing message. Here's the checklist I give friends and family:

Never tap a link in an SMS to log in or pay. Open the app or type the official domain yourself. Real banks and couriers do not need you to use their link.
Read the domain right to left. The real owner is the bit just before the first single slash. dialog.lk.secure-login.co is owned by secure-login.co, not Dialog.
Distrust urgency. "Account suspended," "parcel held," "claim before midnight." Pressure is the product. A real institution gives you time.
Check the sender, not the logo. Logos and copy are now AI-generated and look perfect. The page can be flawless and still be a trap.

Bottom line: The fake site will look real. That's the whole point of the AI. So stop judging legitimacy by how polished a message looks, and judge it by how you arrived at the link.

If you're a developer, you can pull a suspicious link apart safely before clicking anything. Our free URL encoder/decoder will expand the percent-encoding that scam links use to hide the real destination, so you can read where a button actually points.

💡 What this means if you ship products

This case is a warning for builders, not just consumers. If you run any service with a login, you are now a template. Outsider Enterprise allegedly shipped 290+ ready-made clones of legitimate brands, and adding one more is trivial. A few things I'd treat as non-negotiable:

Defense	Why it matters now
Real multi-factor auth	A stolen password alone stops being enough
Out-of-band confirmation	Confirm payments by a second channel, not the same SMS thread
Domain monitoring	Lookalike domains of your brand are cheap to spin up
Clear "we never SMS links" policy	Train users so a fake stands out

The other lesson is for anyone building on top of generative AI. The same Gemini, GPT, or open-source model that drafts your marketing page can draft a perfect clone of someone else's. "It looks professional" is no longer evidence of anything. Provenance is, and we're going to need better signals for it than a clean UI.

🌐 What this means for you

Whether you're a student in Colombo, a freelancer billing clients abroad, or a two-person team shipping a side project, the takeaway is the same: the cost of attacking you just dropped, and the quality of the bait just went up.

You can't out-spot an AI-written scam by looking for typos anymore, because there won't be any. What you can do is change the rule you live by. Stop trusting links because they look right, and start trusting only the paths you control: the app you opened, the domain you typed, the second channel you confirmed on.

Google's lawsuit may shut down one operation. The $88-a-week business model it exposed isn't going anywhere. Build and browse like that's true, because it is.

DoorDash's AI chatbot is a lesson in conversational search

Induwara Ashinsana — Fri, 12 Jun 2026 13:16:06 +0000

DoorDash's new AI chatbot, called Ask DoorDash, lets you type what you want in plain words and get a cart instead of scrolling through restaurant menus yourself. According to TechCrunch's report, it also takes photos as input, so you can show it a dish instead of describing it.

The headline is the feature. The interesting part is what it signals: typing what you want, in your own language, is quietly becoming the default way people expect to use any app with a catalog. That shift matters more to a small builder in Colombo than it does to DoorDash.

🔍 What "Ask DoorDash" actually changes

The old flow was a funnel you walked manually: open the app, pick a category, open a restaurant, read the menu, add items, repeat. Ask DoorDash collapses that into one input box. You describe intent ("cheap rice and curry near me, no beef") and the system does the browsing.

That is conversational commerce: the interface is a sentence, not a navigation tree. Two things make it work, and neither is exotic anymore.

Capability	What it replaces	What it needs
Plain-language search	Category filters + manual browsing	Embeddings over your catalog
Photo input	Typing a description you don't have words for	A multimodal model
Cart assembly	Tapping each item by hand	Structured tool-calls back into your app

Key takeaway: The feature isn't "a chatbot." It's intent in, structured result out. The chat box is just the skin over a catalog you already have.

💡 Why this is a bigger deal for small teams than for DoorDash

DoorDash has millions of users and a search team. For them this is an incremental upgrade. For a two-person shop running a grocery app, a tuition-class booking site, or a parts catalog, the same pattern is the difference between a customer finding the thing and bouncing.

Here's the asymmetry I keep coming back to:

Big platforms had good search already. Conversational search saves their users a few taps.
Small catalogs usually have bad search: an exact-match text box that returns nothing if you misspell "thosai" or search in Sinhala. For them, semantic search is not a luxury, it fixes a broken experience.

So the lesson isn't "we should all build a chatbot because DoorDash did." It's that the cheapest version of this, semantic search over your own listings, now clears the most common reason people fail to buy.

A customer who types "school shoes black size 8" and gets zero results because your DB only matches the word "footwear" is a customer you lost to bad search, not to price.

🛠️ How you'd build the cheap version yourself

You do not need DoorDash's budget. The minimum viable version of this is three steps, and the first two are a weekend's work for one engineer.

Embed your catalog. Run every product title and description through an embedding model once, store the vectors. A few thousand items costs cents.
Embed the query at runtime, find the nearest catalog vectors, return those. That alone gives you "search in your own words," no chat UI required.
(Optional) Add a chat layer that turns the matches into a sentence and assembles a cart via tool-calls. This is where cost and complexity climb.

Steps 1 and 2 are retrieval. Step 3 is an agent. The jump in price between them is real, and it's worth knowing the number before you commit. You can sketch it on our AI chatbot cost calculator, and if you go further and let the model take actions like building a cart, the AI agent cost calculator will show how tool-calling rounds inflate the bill.

Version	What it does	Rough complexity
Retrieval only	"Search in plain words" returns matching items	Low — one embedding model, one vector lookup
Retrieval + summary	Returns items and a one-line explanation	Medium — adds a generation call per query
Full agent	Understands intent, assembles a cart, takes actions	High — multi-step, multimodal, error handling

My honest advice for most local apps: ship step 2, measure whether people use it, and only build step 3 if usage justifies the running cost.

🌐 The Sri Lanka and multilingual angle

The part of this that English-language coverage tends to skip: semantic search is one of the few AI features that helps more in a multilingual market, not less.

A keyword search box punishes the user for not knowing your exact catalog wording. In Sri Lanka, that means it punishes anyone who types in Singlish, switches between Sinhala and English mid-sentence, or spells a food name the way they say it rather than the way you stored it. Embedding-based search closes a lot of that gap automatically, because it matches on meaning, not characters.

"kottu near pita kotuwa" should find Kotahena kottu listings even if none contain the exact string.
A photo of a string-hopper dish should find string hoppers even if the user has no idea it's called idiyappam on your menu.

This is the same capability DoorDash is shipping, applied to a problem global tools rarely bother to solve well: messy, mixed-language, locally-spelled queries.

Bottom line: The smaller and more multilingual your audience, the bigger the relative win from conversational search. DoorDash gets a nice-to-have. You might get the feature that finally makes your search usable.

🚀 What this means for you

DoorDash didn't invent anything you can't copy in spirit. They put a sentence-shaped interface on a catalog and let a model do the browsing. The reusable idea, not the brand feature, is the takeaway.

If your app has a list of anything people search, your real competitor is exact-match search returning nothing.
The cheap win is retrieval, not a chatbot. Embed your catalog, match on meaning, ship that first.
Add the conversational and photo layers only when you've seen demand and run the cost numbers so the bill doesn't surprise you.
In a Sinhala-English market, semantic search isn't a flourish. It's the fix for a search box that has been quietly failing your users all along.

The news is that a giant shipped it. The opportunity is that the same pattern is now within reach of a solo builder on a learning budget.

Apple's WWDC catch-up is a lesson in shipping basics first

Induwara Ashinsana — Wed, 10 Jun 2026 22:17:36 +0000

The most interesting thing about Apple's WWDC 2026 keynote isn't the AI-powered Siri. It's the running order. Apple spent the first stretch on fixes, speed, and long-requested features, and only then revealed its big AI play. As TechCrunch put it in Apple plays catch-up at WWDC, the company wants you to see AI as one part of a broader effort to make its software better, not the whole show.

That sequencing is a strategy, and it's one worth copying if you build software in a small team.

🔍 What Apple actually led with

Before any AI demo, Apple talked about things users had been complaining about. The headline numbers were about performance, not intelligence:

Improvement	Claimed gain
iPhone / iPad app launch	30% faster
Photo loading	70% faster
AirDrop transfers	80% faster
Mail search	Rebuilt, "more stable, more efficient"

There was also a slider to dial back the divisive Liquid Glass look (including a fully tinted option), smoother Wi-Fi-to-cellular handoff, perimenopause and menopause tracking in Health, and shared iCloud photo albums that now accept contributions from Android and Windows users.

Craig Federighi summed up the framing directly:

"Instead of just introducing a host of new features, we're also taking the features you already rely on and making them even better."

None of that is glamorous. All of it is what people use every day.

⚡ The AI came second, and on purpose

The upgraded Siri does land, in beta later in 2026, alongside a stack of AI features: Safari tab organization and webpage analysis, password suggestions, message reply suggestions with photo recognition, natural-language calendar event creation, and an Image Playground API for developers. Apple also showed advanced photo editing like object removal, edge expansion, and spatial reframing.

But notice two things.

First, the AI Siri is launching excluding the EU and China at the start, for regulatory reasons. Regional rollouts are never simultaneous, so if you're in Sri Lanka, don't assume day-one access. I'm not going to guess a local date the source doesn't give.

Key takeaway: Apple is no longer selling AI as the product. It's selling reliable software, with AI as one feature among many. After a year of overpromised assistants across the industry, that repositioning is the actual news.

Second, by burying the AI reveal behind a wall of fixes, Apple lowered the stakes. If the new Siri underwhelms at launch, the keynote still held up. That's a hedge, and a smart one.

🛠️ Why this is the right order for small teams

If you ship a product in Colombo, Galle, or anywhere with a four-person team and no marketing budget, the temptation is to lead with the flashiest feature. A chatbot. An "AI-powered" anything. It demos well and it's easy to talk about.

Apple just demonstrated the opposite playbook at the largest possible scale:

Fix the boring things first. Speed, crashes, search that actually finds things. These are what make users stay.
Treat AI as a feature, not a foundation. Bolt it onto a product that already works, instead of betting the product on it.
Set expectations you can clear. A modest, working feature beats a dramatic one that ships half-broken.

For a bootstrapped builder this isn't just philosophy, it's economics. The two kinds of work have very different cost shapes:

	AI feature	Performance fix
Upfront cost	Moderate	Moderate to high
Ongoing cost	Per-request (API, GPU, rate limits)	Near zero
Fails when	Provider changes, quota runs out	Rarely, once shipped
User reaction	"Nice, sometimes"	"It finally works"

When your budget is a student stipend or freelance income, that ongoing column is what bites you. A performance fix is mostly a one-time engineering cost that keeps paying off; an AI feature is a bill that arrives every month whether users love it or not.

💡 The free-tier angle: you don't need Apple's stack to copy this

The features Apple charges into a flagship phone often exist as free, in-browser tools you can use today. Apple's photo object-removal is impressive, but you don't need to wait for an iOS update or a region rollout to clean up an image. Our background remover runs entirely in your browser, with no upload and no signup, which is exactly the "do the boring thing well" principle applied to a single task.

The broader point for builders:

Scope tightly. Apple shipped one good Siri, not ten mediocre assistants. Pick the one AI feature your users actually asked for.
Run client-side where you can. In-browser tools cost you nothing per use and keep user data on the device. That's a real edge when server GPU time is the expensive part.
Ship the fix, ship the speed-up, then earn the right to ship the AI. Trust compounds; hype doesn't.

🌐 What this means for you

Apple is the most resourced software company on earth, and at WWDC 2026 it chose to lead with a faster AirDrop and a stabler Mail search before its AI assistant. If the company that could out-spend everyone decided that fixing the basics was the story worth telling, that's a strong signal for the rest of us.

Bottom line: Don't build your product around AI. Build a product that works, then add the AI feature your users actually want. The order Apple used on stage is the order to use in your own roadmap.

If you're a Sri Lankan student or small-team founder weighing where to spend limited hours this month, spend them on the thing that breaks most often for your users. The AI feature will still be there next sprint. A reputation for software that just works is much harder to win back once you've lost it.

Apple's new iPhone AI features: what they mean for builders

Induwara Ashinsana — Tue, 09 Jun 2026 20:56:54 +0000

Apple's new iPhone AI features, announced this week, are less about any single trick and more about one quiet decision: plain English is now the default way you tell your phone what to do. According to TechCrunch, Apple is wiring AI into Safari, the Shortcuts app, and the Passwords app, plus Messages, Calendar, Phone, and Photos.

I don't own the latest iPhone, and most of the people I build for in Sri Lanka don't either. So the interesting question isn't "should I upgrade." It's: what does this change about how we work, and how much of it can I get today without buying into Apple's hardware?

🗣️ The interface is becoming a sentence

The thread running through every feature is the same. You describe the outcome in words, and the software assembles the steps.

Shortcuts: describe a workflow in natural language and the app builds the automation, instead of you dragging blocks together.
Safari: create a custom browser extension by typing what you want it to do, no developer skills required.
Passwords: one tap to update a compromised password, with Apple driving Safari through the login flow for you.
Messages: AI reply suggestions and photo search by description ("the receipt from last month").

Key takeaway: The skill that matters is shifting from knowing how to operate the tool to knowing what to ask for. That's good news if you can write a clear spec, and a problem if your whole value was clicking the right menu.

For a junior developer or a student here, that's worth sitting with. The button-clicking layer is getting automated away across consumer software. The judgment layer (what's worth automating, what a good prompt looks like, what's safe to let run) is not.

🔒 The Passwords feature is the one to watch carefully

Most of the new abilities are conveniences. The one-tap password update is different, because it hands an agent the keys to your accounts.

The idea: Apple Intelligence detects a compromised password and walks through the site's change-password flow on your behalf. Useful. Also a meaningful amount of trust to delegate.

Question	Why it matters
What runs on-device vs in the cloud?	The source doesn't say. For passwords, that distinction is everything.
What happens when the flow breaks mid-update?	A half-changed password can lock you out of your own account.
Who is liable if it changes the wrong thing?	Convenience features rarely come with clear answers here.

The TechCrunch piece doesn't specify which features run on-device versus in the cloud, and I won't pretend to know. I'd just say: read the fine print before you let any agent log into your bank for you.

Bottom line: Automating password hygiene is great. Automating password changes deserves a slower, more skeptical look. If you want strong passwords without handing over account access, generate them yourself with a tool like our free password generator, which runs entirely in your browser.

🌐 You don't need an iPhone for most of this

Here's the part Apple won't tell you. Strip away the marketing and most of these features are AI jobs that already run in any browser, for free, on the cheap Android phone or second-hand laptop most people in Sri Lanka actually use.

Apple feature	Cross-platform equivalent you can use today
Photos: object removal, infill, expand	Background Remover (in-browser, no upload)
Messages: summarize / rewrite text	AI Text Summarizer, AI Paraphrasing Tool
Translate across the conversation	AI Translator (Sinhala, Tamil, English + 200 languages)
Photo search by description	OCR + keyword tools like Image to Text

None of these require a subscription, an Apple ID, or a recent device. That's the gap worth naming: Apple is bundling AI into a premium ecosystem, while the same underlying models are available to anyone with a network connection.

🛠️ The "build an extension from a prompt" idea is the sleeper

The feature I keep thinking about is Safari letting you generate a custom extension from a text prompt. That's the same pattern as natural-language app builders, pointed at the browser.

It tells you where things are heading:

Specs beat syntax. Describing behavior clearly becomes more valuable than memorizing an API.
Small tools get disposable. If you can generate a one-off page-tweak in seconds, you make it and throw it away.
Review becomes the bottleneck. Generating code is cheap; knowing whether the generated code is safe is not.

Key takeaway: When generation is free, your edge is judgment — reading what the AI produced, spotting what it got wrong, and deciding what's worth shipping. That skill is platform-independent and doesn't expire.

If you're a student, this is the cheapest possible way to practice: describe a tiny automation, look at what the model builds, and figure out why it made each choice.

💡 What this means for you

The headline is "Apple taught your iPhone new tricks." The real story is that natural language is quietly becoming the control surface for everyday software, and the leverage moves to whoever can describe what they want and judge what comes back.

Practical takeaways if you're building or learning from Sri Lanka:

Don't wait for the hardware. The same AI jobs run free in your browser today. Test them, learn the limits, build the instinct.
Be slow with agentic features that touch credentials or money. Convenience is not the same as safety, and the on-device-vs-cloud question is still unanswered here.
Invest in the durable skill. Writing clear specs and reviewing AI output travels across every platform. Button-memorization does not.

Apple is betting most people will pay for the polish. For builders and students, the more useful bet is to get fluent with the free, cross-platform version of the same idea, because that's the part that compounds.

Ramp's $44B Round and the AI Premium, Read From Sri Lanka

Induwara Ashinsana — Tue, 09 Jun 2026 00:56:10 +0000

The headline that Ramp raised $750M at a $44B valuation is, on its face, a story about a US fintech most Sri Lankans will never use. But the reason behind the number is the part worth reading: investors are paying up specifically for fintechs with an AI story. That signal travels. It tells you what the money believes right now, and that shapes what gets funded, hired, and copied for the next two years.

I read the original report on TechCrunch and want to add the angle it skips: what a single high-multiple round means for someone building on a learning budget here, not in San Francisco.

📊 What the number actually says

According to TechCrunch, Ramp has nearly tripled its valuation over the past year, with investors scrambling for a piece of a fast-growing company. Strip the excitement and you get two plain facts.

Signal	What it tells you
$44B valuation	The market will pay a large multiple for fintech with credible AI in the product
~3x in one year	The re-rating happened fast, driven by narrative as much as numbers
"hunger" for an AI story	Capital is rewarding the story, which means the story is now table stakes

Key takeaway: When investors pay a premium for an "AI story," the premium is temporary. Stories get commoditised. The durable value sits in the workflow and the data underneath, not the label.

The interesting question is not whether Ramp is worth $44B. It is what happens to every smaller company that now has to compete for attention and capital against that narrative.

💡 The "AI story" is now the price of entry, not the edge

A year ago, saying your product used AI was a differentiator. After a round like this, it is the baseline expectation. That is good and bad for a small builder.

The bad: if you pitch a fintech, a SaaS tool, or even a freelance service, "we use AI" buys you nothing on its own. Everyone says it.

The good: the actual capability is cheaper and more accessible than the valuations suggest. You do not need $750M to put a competent model behind a workflow. You need:

A real, narrow problem someone will pay to remove.
Clean data or a clean workflow the model can act on.
Costs you actually understand before you ship.

That third point is where most small teams get hurt. They wire up a model, demo it, and only later discover the per-request cost makes the unit economics impossible. If you are sketching anything agent-shaped, run the numbers first with our AI agent cost calculator so the cost is a decision, not a surprise.

🛠️ What a Sri Lankan builder should copy, and what to ignore

Ramp's category is corporate spend and finance automation. You probably are not cloning that. But the shape of the bet is copyable on a tiny budget.

Copy this:

Automate a boring, repeated finance or admin task. Reconciliation, expense sorting, invoice extraction. Boring is where the money is.
Make the AI invisible. Users want the outcome, not a chatbot. Ramp wins because the AI does work, it does not just talk.
Own the workflow end to end. The moat is the surrounding product, not the model call.

Ignore this:

The valuation game. A US growth round does not map to a market the size of Sri Lanka's. Optimise for revenue per customer, not for a multiple no local investor will pay.
The "raise to grow" reflex. Ramp can burn capital to capture a market. You almost certainly cannot, and you do not need to.

Bottom line: study the mechanism of Ramp's bet, not the scale. The mechanism is "AI quietly removes finance grunt work." The scale is a US capital-market artefact.

💰 Why the cost discipline matters more for you than for them

A company at a $44B valuation can afford to run expensive models on every transaction and figure out margins later. You cannot. This is the single biggest practical difference between their playbook and yours, and it is where I see local projects fail.

Factor	Funded US fintech	Small SL team
Tolerance for negative margins	High, backed by capital	Near zero
Cost per AI call	Absorbed into growth spend	Comes straight out of profit
Right model choice	Can default to the biggest	Match model size to the task
Failure mode	Slower growth	Project dies

The lesson is not "avoid AI." It is "size it correctly." A smaller, cheaper model on a well-defined task often beats an expensive one on a vague task, both on cost and on reliability. Decide the budget, pick the model that fits inside it, and only scale up where the task genuinely needs it.

🚀 What this means for you

The Ramp round is a thermometer, not a map. It tells you the temperature of investor appetite, which is hot for AI-in-fintech right now. It does not tell you to go raise money or chase the same category.

If you are a student, freelancer, or a small team here, take three things from it:

An "AI story" is expected now, so compete on the workflow underneath it. The label is free; the execution is not.
Pick a narrow, boring, painful task. That is where AI pays for itself fastest.
Know your cost per request before you ship. Model the economics first; the funded players can ignore margins, you cannot.

The companies raising at eye-watering valuations and the solo builder in Colombo are answering the same question: does the AI actually do useful work, cheaply enough to matter? Ramp answered it at one scale. You can answer it at yours, and you do not need $750M to start.

The Tokenpocalypse: What AI Token Pricing Means for SL Builders

Induwara Ashinsana — Mon, 08 Jun 2026 04:23:24 +0000

AI token pricing is quietly rewriting the budget of every small team that touches a language model, and the cheap years are ending. TechCrunch published a piece on 7 June 2026 called Is this the dawn of the Tokenpocalypse?, reporting on how AI products are switching from flat monthly fees to charging you per token.

I read it as a warning shot for anyone building on someone else's model. If you are a student, a freelancer, or a three-person studio in Colombo, the subsidy that made these tools feel free is being withdrawn. Here is what I think actually changes.

💰 What the "Tokenpocalypse" actually is

The word, per the TechCrunch report, came from Reddit users reacting to Microsoft moving GitHub Copilot from a flat rate to token-based billing. The joke names a real shift: the hidden cost of running a model is now printed on your invoice.

A flat fee hides the meter. Token billing exposes it. The difference matters most when your usage is spiky.

Billing model	What you pay	Who it favours
Flat subscription	Fixed amount, e.g. a set monthly fee	Heavy users; the vendor eats overage
Token-based	Per unit of input + output consumed	Light users; the vendor stops subsidising

Key takeaway: Flat pricing was the investor-subsidised on-ramp. Token pricing is the real cost of the compute, handed back to you.

📊 Why the bills are about to climb

The article's core claim is about timing. As the large AI labs prepare to go public, they need margins that survive an auditor, not just a pitch deck. TechCrunch notes that token-related risk now has to be written into IPO filings, naming Anthropic specifically, and that one of the open questions is how you even describe a risk that is changing while you write it.

There is a vivid data point in the piece: Uber reportedly burned through its annual AI budget in four months and then capped what employees could spend. If a company that size loses track of the meter, a small team running a chatbot on a credit card will feel it faster.

The report also recalls that ChatGPT Plus launched at $20/month without much pricing science behind it, and that a "tokenmaxxxing" spending spree peaked and faded inside six months. The honeymoon numbers were never the real numbers.

The reckoning is not that AI got more expensive. It is that we are finally being shown what it always cost.

🛠️ What this changes for a small Sri Lankan team

Earning in rupees and paying for tokens in dollars is the squeeze most local builders will feel. A price rise that an American startup shrugs off lands harder when the LKR exchange rate is already working against you.

Three practical consequences:

Per-seat maths breaks. If you resell an AI feature at a fixed monthly price but pay per token underneath, one power user can wipe out the margin on ten others.
Usage caps become normal. Expect more vendors to throttle or meter, the way Uber capped its staff. Build your product assuming the tap can be tightened.
Free tiers get thinner. The generous quotas that let students learn for nothing were marketing. Treat any current free allowance as temporary.

Bottom line: Price your product on what a token actually costs you today, not on the promotional rate you signed up under.

⚡ How to keep your AI bill from exploding

You do not control the vendors' pricing, but you control your consumption. The single biggest lever is knowing your token count before you send a request, then picking the cheapest model that still does the job.

A rough control checklist I would run on any AI feature:

Control	Why it helps
Measure tokens per request	You cannot budget what you cannot count
Trim system prompts	Every repeated instruction is billed on every call
Cap output length	Output tokens usually cost more than input
Cache common answers	Stop paying twice for the same question
Route by difficulty	Send easy calls to a cheap model, hard ones to a strong one

Two of our free, in-browser tools map straight onto the first and last rows. Use the AI Token Counter to see exactly how much of a model's context window a prompt eats before you pay for it, and the AI Model Comparison to line up input and output prices across GPT, Claude, Gemini, and Llama so you can project a monthly figure for your real workload. Both run on your machine, so your prompts never leave the browser.

A worked example, using round numbers to show the method, not a vendor quote:

Chat feature: 5,000 calls/month
Avg input  ≈ 800 tokens, output ≈ 400 tokens
= 6.0M tokens/month

Trim the prompt to 500 input tokens and cap output at 250
= 3.75M tokens/month  → ~37% cut, same feature

You did not change the model or the vendor. You just stopped paying for tokens you were never using.

💡 What this means for you

The Tokenpocalypse is a clumsy name for an overdue correction. The era of building on flat-rate AI and ignoring the meter is closing, and the IPO calendar will only speed that up. None of that is a reason to stop building.

It is a reason to build like the bill is real, because now it is. Count your tokens, compare your models, cache what repeats, and price your product on today's cost rather than yesterday's discount. The teams that treat AI spend as a first-class engineering problem will be fine. The ones still assuming it is free will get a surprise on their next invoice.

Key takeaway: Cheap AI was a launch promotion. Measure your usage now and you turn a looming price shock into a line item you actually manage.

Sriram Krishnan's exit: what shifting US AI policy means for SL devs

Induwara Ashinsana — Sun, 07 Jun 2026 08:02:34 +0000

The news that Sriram Krishnan is leaving his role as White House AI advisor sounds like inside-baseball Washington gossip, and from a desk in Colombo it's easy to scroll past. I don't think you should. When the person shaping a government's posture on AI changes seats, the rules that decide which models you can download, which APIs accept your card, and which export controls touch your GPU access tend to move with them.

According to TechCrunch, Krishnan is reportedly starting a new institution to keep shaping the Trump administration's AI policy from outside government. That detail is the interesting part, and the rest of this post is about why.

🔍 Why a Washington reshuffle reaches your laptop

US AI policy is not a domestic-only document. The frontier model labs, the cloud providers, and the chip designers you actually depend on are mostly American, so the rules written there become the defaults the rest of us inherit.

Here's the chain, concretely:

Policy lever in the US	What it changes for you in Sri Lanka
Export controls on GPUs	Which cloud regions and instance types you can rent
Open-weight model stance	Whether you can legally download and self-host a model
API access / KYC rules	Whether your card and country are accepted at signup
Safety / licensing rules	How fast new model versions ship to everyone

Key takeaway: You don't get a vote in US AI policy, but you absolutely live with its output. Watching who writes it is cheaper than being surprised by it.

When an advisor leaves to build a separate institution, the direction usually doesn't stop. It often gets more concentrated, because a dedicated outside body can push a single agenda harder than one person inside a busy administration.

🛠️ The free-tier reader's real exposure

I build on free and cheap tiers, and I suspect you do too. That's exactly the layer most sensitive to policy mood swings. Paid enterprise contracts have lawyers and SLAs. The free tier has terms-of-service that change on a Tuesday.

Three things I actually watch:

Geographic availability. Plenty of model APIs still gate signups by country. A policy that tightens access rarely opens it for Sri Lanka first.
Open weights vs closed. If an administration leans toward restricting open-weight releases, your ability to run a model locally, offline, on a borrowed GPU, shrinks.
Compute cost. Export rules ripple into which data-center regions get the newest chips, and that ripples into the per-token price you eventually pay.

If a policy shift threatens your access to a hosted API, the hedge is not panic. It's having a local fallback you've already tested.

💡 The hedge: own your stack where you can

This is where a policy story turns into a to-do list. The cleanest insurance against someone else's regulation is reducing how many of your tools depend on a single foreign API that can revoke you.

I lean on this split:

Layer	Cloud-API dependent	Runs on your device
Drafting text	Hosted LLM	Local model + your own editing
Transcription	Hosted speech API	Browser speech recognition
Image cleanup	Hosted SaaS	In-browser WASM tools
File conversion	Upload-based site	Client-side conversion

A surprising amount of day-to-day work doesn't need a frontier model at all. The in-browser tools I keep at induwara.lk/tools run entirely on your machine, no signup, no foreign card, no policy that can switch them off. That's not a pitch, it's the point: the work that runs locally is the work no advisor in Washington can take away from you.

🌐 What a "new institution" usually signals

I won't pretend to know Krishnan's exact plans beyond what was reported, and I won't invent any. But the shape of the move is familiar. People who leave government to start a policy institution are usually betting that influence is more durable from the outside, where they can publish, convene, and lobby without the constraints of an official seat.

For builders, the practical reading is simple:

The policy direction he favoured is unlikely to reverse just because the chair is empty.
Expect continuity, possibly sharper continuity, not a clean reset.
Watch what the new institution publishes once it exists. Those documents often preview the next round of rules before they're rules.

Bottom line: Treat think-tank output as an early-warning radar, not background noise. The white papers come before the regulations.

What this means for you

If you're a student, a freelancer, or a two-person team in Sri Lanka, you don't need to track every personnel change in Washington. You do need a posture, and the Sriram Krishnan departure is a good prompt to set one.

Do three small things this week:

List your single points of failure. Which of your daily tools die if one US API closes its doors to your country? Write them down.
Test one local replacement. Pick the riskiest dependency and run a self-hosted or in-browser alternative for a day. Knowing it works is the whole value.
Bookmark the source, not the headline. Follow the institutions writing policy, not the outrage cycle reacting to it.

None of this requires a budget. It requires the habit of assuming that access granted by a foreign government's mood is access that can be withdrawn. Build a little resilience now, while the news is just a reshuffle and not a wall.

AirTrunk's $30B India AI buildout: what it means for us

Induwara Ashinsana — Sat, 06 Jun 2026 12:02:17 +0000

AI data centers in India just got a very large vote of confidence. According to TechCrunch, the Australian operator AirTrunk is committing $30 billion to build out 5GW of AI data center capacity in India. That is one of the biggest single regional infrastructure bets I've seen aimed squarely at AI workloads.

I'm not in India and neither are most of my readers. So the interesting question isn't "good for India?" It's "what does a wall of GPUs going up next door actually change for a small-team builder, a student, or an engineer in Colombo?" Here's how I read it.

🌐 Why a buildout next door matters more than one in Virginia

Most large AI capacity today sits in North America and Europe. For someone serving users in South Asia, that distance shows up as latency and as egress cost. Every token your app streams from a US region crosses oceans before it reaches a phone in Galle.

A regional hyperscale presence changes the physics of that.

Factor	Compute far away (US/EU)	Compute in the region
Round-trip latency	200–300ms typical	Much lower, same landmass
Data residency	Often a compliance headache	Easier to keep nearby
Egress / transit cost	You pay for the distance	Shorter hops
Failover options	Few nearby zones	More regional redundancy

Key takeaway: 5GW of AI capacity in India is the closest thing to "local" hyperscale AI that the South Asian region has had. Lower latency to your users is the part that reaches your app, even if you never rent a rack.

I want to be careful here: AirTrunk's announcement is about capacity, not about a public price cut tomorrow. Capacity takes years to build. But supply moving closer is the precondition for everything else.

📊 5GW is an absurd amount of power, and that's the real story

The number that should stop you isn't the $30B. It's the 5GW. Dollars are abstract; gigawatts are physics.

A single large AI training cluster can pull tens of megawatts.
5GW is 5,000 megawatts of designed capacity.
That scale of power is the actual bottleneck for AI right now, not chips alone.

The reason every big operator is racing to lock in power and land is simple: you can buy GPUs faster than you can energize a building to run them. AirTrunk putting capital behind power-and-shell at this scale tells you where the industry thinks the constraint is.

For a builder, the lesson is the same one scaled down: your AI cost is mostly energy and utilization, wearing a software costume. When you rent a GPU by the hour, you're really renting a slice of a power bill plus depreciation.

The companies winning the AI race aren't the ones with the cleverest model. They're the ones who secured power and cooling two years ago.

💰 What it does (and doesn't) do to your bill

Here's where I'll push back on the hype. A $30B announcement does not put cheaper inference in your curl request this quarter. So before you plan around future price drops, plan around what you actually pay today.

If you're shipping anything with an LLM in it, the discipline that matters is knowing your unit economics cold:

Estimate tokens per request before you wire up billing, not after.
Separate fixed cost (idle GPU time, storage) from variable cost (per-token, per-image).
Model a realistic load, not your demo. Ten test calls hide nothing; 10,000 real ones do.

This is exactly why I built the free calculators on the site. If you want to sanity-check what a self-hosted model on rented hardware would cost versus an API, the AI GPU cloud cost calculator is the fastest way to get a real number. And because the entire AirTrunk story is ultimately a power story, the AI energy & carbon calculator lets you see the energy footprint behind your own workload.

Question you should answer	Tool that answers it
What does running my own GPU cost per hour?	AI GPU cloud cost calculator
How much energy/CO₂ does my AI usage burn?	AI energy & carbon calculator

🛠️ How I'd actually act on this as a small builder

I'm not going to rent capacity in a 5GW campus. Neither are you. But the strategic posture this news rewards is one any small team can adopt:

Stay region-aware. When picking a cloud region for an AI feature, check whether a South Asian or Indian region is now an option. If it is, test latency from a Sri Lankan connection before defaulting to a US region.
Keep your stack portable. The cheaper compute gets, the more it pays to be able to move providers. Don't hard-wire one vendor's proprietary API if an open-source model would do.
Lean on free tiers while supply is tight. Compute is still rationed. Use free inference tiers and open-weight models for learning and prototyping, and reserve paid GPUs for the workload that actually earns.
Measure first. Every decision above is easier when you have a number. Guessing is how AI projects quietly go over budget.

Bottom line: A buildout like this is a slow tide, not a wave. It won't change your invoice this month, but it shifts the default of where AI compute lives toward our part of the world.

💡 What this means for you

If you're a student or a solo builder reading this from Sri Lanka, the takeaway isn't "wait for cheap GPUs." It's the opposite: build the cost discipline now, so you're ready when supply does loosen.

The infrastructure giants are betting tens of billions that AI demand keeps climbing. You don't need to match that bet. You need to know your own numbers well enough that, whichever way prices move, you can ship something that pays for itself. Start with a cost estimate, keep your code provider-agnostic, and treat every gigawatt of regional capacity as one more reason South Asia stops being an afterthought on the AI map.