Romesh Niriella
Software engineer · Technical leader · Systems builder
I have spent 14+ years building software for financial and regulated businesses, travel booking engines and CRM systems. I publish the decisions and the evidence behind them, not the highlights.
The work is the same in each case: grow faster, reduce risk, and scale without depending on heroics.
In each case the job is the same: find what is actually happening, decide what to build first, and keep the next change cheap.
Turn a rough idea into a technical plan and a first version people can use.
understanding the real problem · deciding what the first version must do · identifying what can wait · choosing a simple technical structure · building or guiding the initial implementation
Read an existing product or plan before more money and time go into it.
architecture review · workflow mapping · hidden assumptions · failure points · security and operational risks · practical next steps
Map software and operations that have become expensive to understand or change.
mapping the current system · finding where responsibility is unclear · identifying fragile dependencies · reducing manual work · making future changes safer
Founders and teams who understand a real problem and intend to ship something useful.
I work often with teams in Sri Lanka, parts of Africa and other markets where budgets are tighter, specialists are fewer and infrastructure cannot be assumed.
Local knowledge leads. I bring engineering, system design and regulated-product experience.
Accumulated experience, an active project and an experiment. Each one is real and still in use.
Lessons from building and improving software for financial and regulated businesses.
operational workflows · architecture · failure handling · compliance-sensitive changes · automation · production delivery
Simple play ideas and notes from learning to be a more present father.
play · attention · family · writing
A place where I test unusual ideas in software, AI, sound and interaction.
experiments · sound · interaction · rendering
Small experiments. Linked, not sold.
A small experiment in reframing assumptions by looking at their opposite.
Before writing software, read the people, constraints and environment around it.
Build the smallest version that can prove or kill the idea.
A system that works in a demo has not been tested.
Code, decisions and ownership should be legible to whoever inherits them.
Sanitised summaries of past work. No client names, no numbers I cannot show.
Send a short description of the problem, who it is for and what already exists.
I will tell you whether I can be useful, and where I would start.