Building software in public · Architecture · Developer experience
I’m Savi Saluwadana, a software engineer based in Sri Lanka. I build software in public, sharing repositories, architecture, and the decisions and trade-offs behind my projects.
I’m also exploring platform engineering, especially containers, CI/CD, and developer experience. My project code and setup notes show what I have worked on so far.
01 / Projects
I keep all 16 project overviews here. Repositories you can inspect appear first; other products are listed below. Browse the product directory ↗
Property marketplace + transactions
A Sri Lankan property platform spanning rentals, property sales and short-term bookings with role-based users, geospatial search, availability, booking workflows, payments and property operations.
Commerce + recurring delivery
A premium food-commerce platform for Colombo bringing together fresh groceries, local products, prepared meals, recurring delivery and business ordering in one customer experience.
Operational SaaS architecture
A rental operations platform covering properties, units, tenants, leases, rent, maintenance, documents, notifications and controlled agent-assisted operations.
Publishing + discovery
A developer publication and tool-discovery product with editorial workflows, comments, likes, search, tool profiles, media uploads and a deliberately small CMS.
Local-first HRIS + desktop operations
A hybrid HR information system with an employee web portal, a native HR/admin desktop console, tenant-scoped access, policy-backed leave, schedule-aware attendance, audit history and durable offline synchronization.
Student, fees & academic operations
A SaaS workspace for tuition centres and private institutes combining student CRM, classes, attendance, assessments, fee collection, communications, reporting and multi-site institute operations.
Evidence-backed research + MCP
An early community research project for exploring recurring needs using source-linked evidence. The current repository provides a local Next.js and Rust web app and a separate desktop app.
Practitioner discovery + secure consultations
Product and frontend work for practitioner discovery and consultation journeys.
Developer intelligence platform
A self-hosted beta for discovery, engagement and outcome measurement.
Point of sale + Electron desktop
Checkout and store operations with an optional Electron desktop shell.
Single-company double-entry accounting
Single-company financial operations backed by a double-entry ledger.
POS + kitchen + direct ordering
Restaurant point of sale and coordinated order operations.
Campaign analysis + reporting
An advertising analytics and reporting prototype.
Patient records + scheduling + billing
Patient administration, appointments, clinical records and billing.
See the code and its limitations. Each public project links to its code and documents how to run it.
Browse repositories02 / Public source
My public repositories show code, setup steps and design choices. Publicly visible source is not always open-source licensed.
Read the public source index ↗03 / Platform engineering interests
I am learning how teams turn source code into repeatable builds and deployments. My public projects show Docker files, Compose setups and CI workflows; they do not establish production platform experience.
Stack / Technologies I build with
Technologies used in the projects linked above. These are implementation references, not a claim of expertise in every tool.
For implementation details, see each repository's code and setup instructions. I am still exploring platform engineering.
05 / Engineering focus
The technologies matter, but the more important part is designing systems with clear behavior, durable boundaries and operational consequences that can be understood.
End-to-end products where customer experience, domain rules, payments, workflows, data and operational constraints fit together as one system.
Designing domain boundaries, service responsibilities, data ownership, API contracts and architecture that can evolve without turning every change into a cross-system rewrite.
Go services, modular monoliths, background workers, durable workflows, PostgreSQL and server-authoritative business rules designed for reliability and change.
I am learning from the Docker, CI and deployment configuration in my projects. I want to explore Kubernetes and developer self-service next.
I’m interested in tool-using agents, workflow orchestration, retrieval and multi-agent collaboration for real product and developer workflows, with clear permissions, evaluation, observable execution and human oversight. Explore the agentic systems architecture ↗
I publish code, setup instructions and design decisions for the projects linked in my public source index. Clear examples and documented design decisions help others inspect, run and improve a project. Browse the public source index ↗
06 / Project domains
My projects cover property listings and rental operations, food commerce, home-service bookings, healthcare workflows, education, accounting, retail and event coordination. I use these domains to work through API design, data ownership, permissions and operational workflows; the project pages show what is implemented and what is still incomplete.
07 / Engineering notes
Short working principles pulled from the architecture decisions behind the projects above. Read the architecture reference ↗
Good architecture makes ownership, state and change easier to reason about. The goal is not more services or diagrams; it is keeping the cost of change understandable as the system grows.
The UI, domain model, payments, operational workflow, infrastructure and support path all shape the product. Good engineering keeps those pieces coherent instead of treating them as separate projects.
A good platform removes repetitive infrastructure work while keeping state, ownership and failure modes visible enough that engineers can understand and debug what is happening.
08 / Engineering insights
Focused technical writing on the boundaries behind reliable systems: permissions, durable workflows, Go backend structure, platform contracts and tenant isolation. Browse all engineering insights ↗
Why agent tools should reuse authenticated domain boundaries instead of creating a second authority path.
A modular-monolith approach that keeps transactions simple while preserving explicit domain ownership.
Authorization-first guidance for tenant isolation, repository contracts and database defense in depth.
Proposed, not published
Three ideas come from project decisions; two explore platform engineering without choosing a vendor.
A project-backed note on routing tool actions through authenticated domain APIs rather than a second access path.
How I separated repeat delivery scheduling from payment capture and what that leaves unfinished.
A look at the Rust API, local data layer and the trade-offs between the web and desktop editions.
A tool-neutral exploration of build inputs, configuration, ownership, health and failure signals.
A tool-neutral exploration of the gap between passing checks and operating a diagnosable deployment.
09 / About
I’m Savi Saluwadana, a software and product engineer based in Sri Lanka. I build products and publish implementation notes. I am exploring platform engineering through the build, container and deployment setup visible in my repositories.
I’m particularly interested in architecture and systems design: how domain models, APIs, data, workflows, deployment and operational constraints fit together, and how those choices hold up as a product grows.
I’m also interested in agentic systems: tool use, MCP, retrieval, durable workflows and multi-agent collaboration that automate useful work with clear permissions and human oversight. Open-source development matters to me too—contributing code, fixing bugs, improving documentation and collaborating on software people can inspect and build on.
I want to contribute across industries where technology can have a real operational effect, including healthcare, real estate, food and commerce, logistics, shipping, financial services and infrastructure-heavy businesses.
I prefer building things that can be inspected: clear contracts, explicit state, straightforward deployment paths and enough observability to explain what happened when something goes wrong. Full profile and engineering focus ↗
08 / Contact
I’m interested in technically meaningful product, software architecture, agentic systems, platform and DevOps work, plus open-source collaboration where strong engineering can improve real operational systems.