I build systems where architecture drives capability. My focus is on AI-assisted, workflow-heavy, multi-tenant environments where data isolation, state management and role boundaries dictate how the software must be built.
- Core Business Systems & Enterprise Platforms
- Agentic AI Systems & RAG Integrations
- Multi-tenant Architecture & RBAC
- CRM Architecture & Workflow Automation
Location
Colombo, Sri Lanka
Focus
Software Engineering · AI
Stack
TypeScript · React · Node.js · Go · Python · Postgres · AWS
Availability
Open to opportunities
"Anyone can ship code now. What's scarce is knowing what's worth building and holding up when it gets hard."
About
Engineering aligned with business reality.
I'm a software engineer based in Colombo. I build systems that run real operational environments: workflow-heavy platforms with strict permissions, complex integrations and the kind of edge cases that only show up in production.
My work spans tenant-isolated architectures, agentic AI systems, deep API integrations and the internal tooling that keeps operations running. I handle the full lifecycle from schema design and backend logic to frontend delivery.
I care about how software functions under constraints: who uses it, what business rules apply, how AI integrates into real workflows and what maintainability actually means for the team inheriting the codebase.
Outside of engineering: football, camping and time with people who don't care about system design. :)
Orientation
- Systems over isolated features.
- Architecture awareness at every layer.
- Designed for operational constraints.
- Secure, multi-tenant and permission-aware.
- AI as a reliable layer, not a demo feature.
- Maintainability over fragile shortcuts.
Location
Colombo, Sri Lanka
Focus
Software Engineering · AI
Platforms
Web · Mobile · AI
Availability
Open to opportunities
Background
Roles and operational background.
2.5+ years industry experience
Augustory, Corp. (Formerly Nerve8)
- Led technical architecture for enterprise SaaS platforms, designing multi-tenant backends and resilient data isolation layers.
- Engineered production AI systems, automated evaluation pipelines and structured document extraction workflows.
- Built enterprise CRM and ERP integrations to automate business operations and support workflows.
- Delivered full-stack web applications and commercial platforms from architecture to production deployment.
Spectrum Code
Worked across front-end and back-end web development in a remote team, contributing to production features from internship through to a part-time engineering role.
Third Space Global
Delivered online mathematics tutoring, adapting complex analytical concepts for diverse learning levels.
Academic Tutoring
Tutored university students in Software Engineering and Open Source Applications.
Scope
What I build and how I engage.
Full-Stack & Mobile
Building production-grade web and mobile applications from concept to launch. Focused on modular architecture, strict API contracts and responsive cross-platform interfaces.
Software Architecture
Designing multi-tenant SaaS platforms, strict data isolation boundaries, asynchronous task queues and resilient distributed systems engineered for concurrency and auditability.
AI & Agentic Systems
Engineering production RAG pipelines, structured knowledge graphs, multi-agent workflows with human-in-the-loop controls and automated evaluation harnesses.
Cloud & Enterprise Systems
Provisioning scalable cloud infrastructure, container orchestration, automated CI/CD pipelines, distributed observability and mission-critical ERP or CRM integrations.
Skills
Technologies I work with in production.
Languages
Frontend & Mobile
Backend & APIs
AI & Agentic Systems
Databases & Storage
Cloud & DevOps
Architecture Patterns
Integrations & Platforms
Testing & Observability
Approach
How I think about engineering.
Design for reality
Systems must survive contact with operational reality. I prioritize edge-case handling, data integrity and reliability over surface-level shine.
Map to the workflow
Features that ignore how people actually work accumulate friction. Good architecture maps directly to real business constraints and user habits.
Protect maintainability
Fast delivery built on shortcuts creates compounding debt. I write code that future engineers can quickly understand, debug and safely extend.
Security by design
Multi-tenancy and data isolation are not afterthoughts. Role-based permissions and security boundaries are enforced directly at the database layer.
AI accelerates, fundamentals sustain
Generating code is easy. The real scarcity is the judgment to know what to build, how to structure it and when to hold the line on quality. I use AI to iterate faster but rely on engineering fundamentals to make the architectural trade-offs that tools cannot make.
Field Notes
Real reflections from production.
Why RLS over app-level tenancy
I've learned the hard way that app-layer tenancy is just too easy to forget. Pushing isolation deep into PostgreSQL with RLS makes the database the absolute final guardrail, regardless of what the API does.
What breaks first in multi-tenant systems
It's rarely the database. Multi-tenant systems usually fail right at the seams. A middleware loses context, some shared query becomes noisy or auth state drifts between layers.
Architecture ages faster than code
You can rewrite bad code in an afternoon, but bad architecture takes months to unwind. Knowing exactly when to keep a system dead simple is honestly one of the most underrated engineering skills.
Trust the database for invariants
If a business rule must absolutely never be violated, it belongs somewhere much stronger than application logic.
Account balances should never be stored as editable numbers
Storing account balances as mutable numbers is asking for balance drift. The only number you should trust in financial accounting is the sum of an immutable ledger computed inside the database.
Idempotency is not optional in unreliable networks
When users inevitably mash the retry button under a poor connection, duplicate submissions are a system design failure, not a frontend problem.
A booking system should fail closed
In production flows where capacity is strictly limited, the safest default is always to reject duplicates before they ever hit the database twice.
Real-time systems need deduplication more than speed
Blazing fast updates are completely useless if the same event gets processed twice and corrupts your entire current state.
Long-running tasks do not belong in an HTTP request
Holding an open connection while an AI model parses documents or scores data is fragile. Drop the payload into a persistent queue, return a job ID immediately and stream progress over lightweight events.
Telemetry should be appendable, but state should be current
Raw events belong in history. Operational views, on the other hand, should be the result of carefully controlled merges, not blind overwrites.
Human approval is part of the design
Whenever an external system is allowed to change ownership records, I always build in a pause for human review before anything irreversible commits.
Not every sync should be automatic
Some changes are totally safe to detect on the fly, but wildly unsafe to apply without a real person eyeballing the diff first.
Bi-directional sync requires an undisputed owner
If two systems can both write to the same field, you will eventually hit reconciliation deadlocks. Every synced data attribute must have one clear system of record that always wins conflicts.
Good automation knows when to stop
A truly reliable automation tool isn't fully autonomous. It deliberately exposes a pause point right before it does something you can't undo.
LLM output is only useful if it is structured
If your AI cannot return strict, evidence-backed, schema-valid output, keep it far away from production data workflows.
Traceability matters more than clever prompting
A genuinely useful AI system doesn't just spit out an answer. It shows its work and points to exactly where that answer came from.
Vector similarity is not reasoning
Cosine similarity tells you that two paragraphs sound related, not how entities actually connect. When evaluating cross-document dependencies, a structured knowledge graph beats a larger embedding dimension every time.
Why RLS over app-level tenancy
I've learned the hard way that app-layer tenancy is just too easy to forget. Pushing isolation deep into PostgreSQL with RLS makes the database the absolute final guardrail, regardless of what the API does.
What breaks first in multi-tenant systems
It's rarely the database. Multi-tenant systems usually fail right at the seams. A middleware loses context, some shared query becomes noisy or auth state drifts between layers.
Architecture ages faster than code
You can rewrite bad code in an afternoon, but bad architecture takes months to unwind. Knowing exactly when to keep a system dead simple is honestly one of the most underrated engineering skills.
Trust the database for invariants
If a business rule must absolutely never be violated, it belongs somewhere much stronger than application logic.
Account balances should never be stored as editable numbers
Storing account balances as mutable numbers is asking for balance drift. The only number you should trust in financial accounting is the sum of an immutable ledger computed inside the database.
Idempotency is not optional in unreliable networks
When users inevitably mash the retry button under a poor connection, duplicate submissions are a system design failure, not a frontend problem.
A booking system should fail closed
In production flows where capacity is strictly limited, the safest default is always to reject duplicates before they ever hit the database twice.
Real-time systems need deduplication more than speed
Blazing fast updates are completely useless if the same event gets processed twice and corrupts your entire current state.
Long-running tasks do not belong in an HTTP request
Holding an open connection while an AI model parses documents or scores data is fragile. Drop the payload into a persistent queue, return a job ID immediately and stream progress over lightweight events.
Telemetry should be appendable, but state should be current
Raw events belong in history. Operational views, on the other hand, should be the result of carefully controlled merges, not blind overwrites.
Human approval is part of the design
Whenever an external system is allowed to change ownership records, I always build in a pause for human review before anything irreversible commits.
Not every sync should be automatic
Some changes are totally safe to detect on the fly, but wildly unsafe to apply without a real person eyeballing the diff first.
Bi-directional sync requires an undisputed owner
If two systems can both write to the same field, you will eventually hit reconciliation deadlocks. Every synced data attribute must have one clear system of record that always wins conflicts.
Good automation knows when to stop
A truly reliable automation tool isn't fully autonomous. It deliberately exposes a pause point right before it does something you can't undo.
LLM output is only useful if it is structured
If your AI cannot return strict, evidence-backed, schema-valid output, keep it far away from production data workflows.
Traceability matters more than clever prompting
A genuinely useful AI system doesn't just spit out an answer. It shows its work and points to exactly where that answer came from.
Vector similarity is not reasoning
Cosine similarity tells you that two paragraphs sound related, not how entities actually connect. When evaluating cross-document dependencies, a structured knowledge graph beats a larger embedding dimension every time.
Autonomous agents need narrow state machines
Giving an LLM open-ended tool access without explicit state transitions is a recipe for runaway token bills. The most reliable multi-agent systems are strict state machines where agents only make decisions at defined gates.
Deterministic validation makes AI usable
The moment you force AI output into a strict schema, it transforms from a parlor trick into something a database can actually trust.
The browser is not always a simple input surface
Modern UIs love to hide their real state behind React components. If you're building automation, you have to work with the raw DOM, not just blindly click things.
When WebDriver is not enough, the DOM still is
When standard automation inevitably flakes out, dropping down to direct event dispatch and controlled script execution is the only way to build resilient RPA.
Legacy systems should be modernized without breaking the contract
Shipping a shiny new frontend is completely pointless if it breaks the behavior that all your downstream integrations depend on.
Refactoring should reduce risk, not create new ones
The goal isn't to rewrite everything from scratch. It's to surgically improve the system without disturbing the ugly parts that are actually working fine in production.
Production incidents are architecture feedback
Server crashes, log explosions and sudden resource exhaustion are almost always symptoms of deeper design problems, not just isolated bugs.
Stability is an engineering feature
I'll take a system that survives memory pressure, disk exhaustion and bad dependencies over one that only hums along in ideal conditions any day.
Operational cleanup is part of software work
Sometimes the most critical engineering task you can do isn't shipping a new feature. It's restoring a degraded system so it can keep serving real users.
A good feature respects the real world around it
Whether it's offline users, flaky third-party APIs or live operational dashboards, your design simply has to assume imperfect conditions.
Systems should be built for retries, stale state and partial failure
Production is never a clean sequence of requests. It's a messy, chaotic stream of duplicates, delays and sudden interruptions.
External webhooks will arrive broken and out of order
Third-party APIs do not guarantee chronological delivery or clean schemas. Persist the raw webhook payload first, check idempotency keys second and only then hand off processing to a worker.
The hard part is often coordination, not code
Most of the real challenges I face are just about keeping data, the UI, background jobs and external systems perfectly aligned.
Security is strongest when it is layered
One single control is too easy to miss. Stacking multiple, aligned controls makes a catastrophic failure infinitely harder to pull off.
Audit trails need cryptographic proof, not just logs
Application logs can be modified or purged during incident cleanup. High-stakes legal and financial actions require detached cryptographic signatures with public-key verification that stand up independently in court.
If one layer fails, the next layer should still hold
Good systems are inherently paranoid. They assume mistakes will happen and are built to keep the data safe anyway.
Architecture is really about preserving correctness under stress
Clean architecture diagrams don't matter at all if the system can't behave correctly when requests overlap, jobs retry and integrations lag.
Autonomous agents need narrow state machines
Giving an LLM open-ended tool access without explicit state transitions is a recipe for runaway token bills. The most reliable multi-agent systems are strict state machines where agents only make decisions at defined gates.
Deterministic validation makes AI usable
The moment you force AI output into a strict schema, it transforms from a parlor trick into something a database can actually trust.
The browser is not always a simple input surface
Modern UIs love to hide their real state behind React components. If you're building automation, you have to work with the raw DOM, not just blindly click things.
When WebDriver is not enough, the DOM still is
When standard automation inevitably flakes out, dropping down to direct event dispatch and controlled script execution is the only way to build resilient RPA.
Legacy systems should be modernized without breaking the contract
Shipping a shiny new frontend is completely pointless if it breaks the behavior that all your downstream integrations depend on.
Refactoring should reduce risk, not create new ones
The goal isn't to rewrite everything from scratch. It's to surgically improve the system without disturbing the ugly parts that are actually working fine in production.
Production incidents are architecture feedback
Server crashes, log explosions and sudden resource exhaustion are almost always symptoms of deeper design problems, not just isolated bugs.
Stability is an engineering feature
I'll take a system that survives memory pressure, disk exhaustion and bad dependencies over one that only hums along in ideal conditions any day.
Operational cleanup is part of software work
Sometimes the most critical engineering task you can do isn't shipping a new feature. It's restoring a degraded system so it can keep serving real users.
A good feature respects the real world around it
Whether it's offline users, flaky third-party APIs or live operational dashboards, your design simply has to assume imperfect conditions.
Systems should be built for retries, stale state and partial failure
Production is never a clean sequence of requests. It's a messy, chaotic stream of duplicates, delays and sudden interruptions.
External webhooks will arrive broken and out of order
Third-party APIs do not guarantee chronological delivery or clean schemas. Persist the raw webhook payload first, check idempotency keys second and only then hand off processing to a worker.
The hard part is often coordination, not code
Most of the real challenges I face are just about keeping data, the UI, background jobs and external systems perfectly aligned.
Security is strongest when it is layered
One single control is too easy to miss. Stacking multiple, aligned controls makes a catastrophic failure infinitely harder to pull off.
Audit trails need cryptographic proof, not just logs
Application logs can be modified or purged during incident cleanup. High-stakes legal and financial actions require detached cryptographic signatures with public-key verification that stand up independently in court.
If one layer fails, the next layer should still hold
Good systems are inherently paranoid. They assume mistakes will happen and are built to keep the data safe anyway.
Architecture is really about preserving correctness under stress
Clean architecture diagrams don't matter at all if the system can't behave correctly when requests overlap, jobs retry and integrations lag.
Writing
Things worth writing down.
Your Auth Middleware Is Too Late. Here's What Should Run Before It.
Most Node.js apps have an auth middleware. You write a protect function, drop it on your routes and call it done. That works fine until you are building a multi-tenant SaaS platform with role-based rate limiting, row-level security, audit trails and a graceful shutdown lifecycle. Then you start realising that auth is not one thing. It is a two-phase pipeline.
We Wrote Our Own Circuit Breaker (And You Probably Should Too)
Building a fast Node.js backend usually means relying heavily on Redis and Postgres. But it doesn't take long to realize that your caching layer is actually a single point of failure. If Redis hangs, socket timeouts pile up, queues exhaust and the entire Node process can get dragged down with it.
How We Got Postgres to Enforce Multi-Tenancy Automatically
The problem with multi-tenancy is that it is easy to do loosely and nearly impossible to do right. Here is how we wired Postgres Row Level Security into our Node.js connection pool using AsyncLocalStorage so that tenant isolation runs automatically on every single query.
Connect
Let's talk.
Whether you need to scale system architecture, build a robust internal platform or discuss engineering operations, I'm open to conversations.