Charith ‘Alex’ Gunasekara, Head of Development & Engineering

He builds real-time AI voice agents from scratch with custom models, end to end. Real-time streaming over WebRTC, speech-to-text in, text-to-speech out, and a language model in the middle doing the actual work.

The part most teams in Australia care about: the voice stream and the language model data can stay inside the Australian region. For health, government and finance work, that is usually the question that decides whether a project can happen at all.

He also builds custom RAG systems: a Python backend, Pinecone or Postgres with pgvector for the vector store, and OpenAI, Anthropic Claude or AWS Bedrock for the model. Most of the quality comes from the document processing before anything reaches the index, not from which model you pick.

The other half is caching and memory. Semantic caching stops the same question being answered from scratch and paid for twice, and careful memory management keeps a long conversation inside the context window without losing the thread.

Most organisations do not need an AI strategy document. They need the boring questions answered: where the data goes, who can see it, and what it actually saves.

He works at that end. Keeping data in the region it has to stay in, deciding what runs on the device or inside the customer’s own environment, and being straight about which tasks a model genuinely speeds up and which ones it only appears to.

Australian privacy requirements make one question unavoidable: which country processes the data? If the answer is a model hosted in the United States or Europe, that needs to be a decision somebody made on purpose, not a default nobody checked.

Most businesses do not know the answer, and it is not only the language model. Speech-to-text, text-to-speech and text embedding models are each a separate service, often in a different region, and every one of them sees the data.

So he designs the pipeline so that processing stays inside Australian region data centres where it has to, and anything that sits outside them is a known, deliberate exception rather than something discovered later.

The same thinking applies to cost. A website assistant does not need a chatbot vendor or a vector store: one Next.js function on Vercel, Vercel AI Gateway holding the model key, prompt caching instead of retrieval, and a hard monthly budget cap that stops requests before the model is called. He wrote up one such build, with the real numbers, inA Cost-Capped AI Assistant on Next.js.

There is a second problem, and it is costing Australian businesses real money. A lot of engineers propose the solution they saw somewhere else: the same architecture, the same models, the same bill. It fits the company they saw it at, not this one.

He starts from the business problem, the budget and where the company is actually trying to go, then designs the smallest thing that solves it. Sometimes that is a custom fine-tuned model. Often it is far less than what was proposed, and the cheaper answer is the correct one.

Over engineering an AI system is easy to sell and expensive to live with. Every extra model, index and service is another thing to run, pay for and keep working.

The other half is visibility. Most businesses already hold the data they need, locked inside systems nothing modern can read. Opening that up is usually worth more than adding another model on top.

He builds and maintains SaaS products in both shapes: multi-tenant, where one deployment serves everyone, and single dedicated tenant, where a customer gets their own instance and their own database.

Those are two different products, not a configuration switch. Multi-tenant is cheaper to run and harder to isolate. Dedicated tenancy is what regulated customers ask for, and it costs more to operate, upgrade and support for the rest of its life.

Most of the work sits in the parts nobody demos: tenant isolation, onboarding a customer without a deployment, keeping one tenant’s data unreachable from another, and upgrading everybody without taking anybody down.

AWS architecture, infrastructure as code with Terraform, and containerised deployment. Repeatable environments, not a console somebody clicked through once and cannot rebuild.

The judgement that matters is choosing the deployment that fits the problem. The right answer depends on the context, the budget and the real traffic, and it is often much cheaper and simpler than the fashionable one. Paying for scale you do not have is a common and avoidable way to burn a budget.

He has been building iOS apps since 2013, starting in Objective-C with XIBs and hand-written programmatic UI, then Storyboards, then Swift, and now SwiftUI.

He shipped through every one of those transitions, which is a different thing from learning iOS after they happened. Plenty of production apps still run on Objective-C, Storyboards and XIBs, and he can work inside that code instead of only offering to rewrite it.

The apps cover the full range: internal tools, enterprise-distributed apps, and public App Store releases. Provisioning profiles, certificates, signing and deployment come with it, because that is usually where a release actually stalls.

Push notifications used to mean writing APNs server scripts by hand. Platforms like Firebase and OneSignal make that easier now, and having done it both ways helps when notifications quietly stop arriving.

Publishing to the App Store is its own skill. Apps get rejected, and the useful experience is knowing why before you submit rather than after.

Native macOS work sits alongside it, and increasingly AI that runs on the device rather than in someone else’s data centre. That includes training and fine-tuning models with Apple MLX and loading the trained model into a shipped app.

He documented the whole path in a five part series: running a model locally, building the dataset, fine-tuning it with LoRA, fusing the adapter, and loading the result into a SwiftUI Mac app. Start with running LLMs locally with Apple MLX.

A lot of Australian businesses still run on IBM i (AS/400). The integration layer in front of it is usually SOAP web services written in RPGLE, working fine and understood by fewer people every year.

He migrates that source code into modern REST services. DB2 does not move. The same tables stay the source of truth, read and written the same way they always were.

Pricing is the part that has to be exact. The new services call the same Infor M3 pricing the same way the RPG code called it, so a quote comes back with the number it has always come back with. A modernisation that quietly changes a price is a defect, not an upgrade.

What changes is who can reach it. Modern software, internal tools, mobile apps and shipping platforms connect through a clean REST API instead of SOAP. That is the door that was closed before.

The middleware is portable, and that decides more than it sounds like it does. He has deployed it onto the customer’s own IBM i, running from the IFS, so the data never leaves their environment.

Authentication is handled through the iSeries key vault rather than credentials sitting in a config file. The same application also runs on AWS or Azure unchanged, so where it is hosted becomes a decision about cost, policy and data residency instead of a rewrite.

Replacing these systems wholesale usually fails. Migrating the integration layer while leaving the data and the business rules alone usually works.

He does not think technical skill alone makes a good engineering leader. The job is to sit between the executives and the engineers, start from the business strategy, and design and architect the solution together with the team rather than handing a design down to them.

From there it becomes a delivery plan: what gets built in what order, and which people are allocated to each part of it. Then he heads towards that delivery with the team, across UI/UX design, development and QA until it ships.

The measure is whether the business outcome actually arrived, not whether the tickets closed.

He is direct about process and discipline. Teams that agree on how they work spend far less time arguing about it later.

The part he cares about most is delegation. Give people real ownership of what they deliver, and the quality goes up on its own. The alternative is a team that hands work back and forth through endless bug cycles and issue triage, which is slower and worse for everyone.

Delegating ownership does not mean standing back. While the team is pushing towards a delivery he still takes development and deployment work himself. Not to take it over, but to carry a share of the weight.

He enjoys that part, and it earns something that cannot be asked for. A team works differently for someone who is in the code beside them instead of sending instructions from outside it.

It also keeps his judgement honest. A leader who stops building slowly loses touch with what he is asking other people to do, and starts making decisions based on how things used to work.

He helps organisations and teams who are struggling to get a product or a solution delivered.

Most of the time the problem is not a missing framework or a new tool. It is an unclear plan, a delivery nobody owns, or an architecture chosen for the wrong reasons.

What he pushes for first is discipline and consistency in how a team delivers. A team that ships the same way every week is worth more than a team that is brilliant now and then.

He believes a leader has to hold those values and have a real technical foundation underneath them, in architecture and in deployment strategy. One without the other does not get a product out the door.

Charith is his original Sri Lankan name, and his legal name. It is the name his family uses, the name on official records, and the name friends and colleagues in Sri Lanka still call him.

Alex is the name he goes by professionally in Melbourne. It started as the simpler name for people to say at work, and it stuck. Most of his Australian colleagues have only ever known him as Alex.

Both names belong to the same person. He writes it as Charith ‘Alex’ Gunasekara so that neither half of his life needs a footnote.

He publishes engineering deep-dives and leadership field notes most weeks. The most recent work is a five part series on training a language model on a Mac and shipping it inside an app. Read it on the writing page, or see the full capability breakdown on the expertise page.

Email hello@charithgunasekara.com, or find him on LinkedIn.