NODE:0

Romesh Niriella

Software engineer · Technical leader · Systems builder

Technology should increase what a company is capable of.

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.

01

Where this usually starts

In each case the job is the same: find what is actually happening, decide what to build first, and keep the next change cheap.

03

Who this is for

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.

04

What has grown here

Accumulated experience, an active project and an experiment. Each one is real and still in use.

Software for regulated businesses

EXPERIENCE
node:regulated-systems · cultivated

Lessons from building and improving software for financial and regulated businesses.

operational workflows · architecture · failure handling · compliance-sensitive changes · automation · production delivery

RORA+DAD

PROJECT
node:rora-dad · active

Simple play ideas and notes from learning to be a more present father.

play · attention · family · writing

See RORA+DAD →

Silicone Life

EXPERIMENT
node:silicone-life · experimental

A place where I test unusual ideas in software, AI, sound and interaction.

experiments · sound · interaction · rendering

Visit Silicone Life →

05

Pet projects

Small experiments. Linked, not sold.

Invert

EXPERIMENT

A small experiment in reframing assumptions by looking at their opposite.

Open Invert →

06

How I work

  1. 01

    Find what is actually happening

    Before writing software, read the people, constraints and environment around it.

  2. 02

    Ship the smallest useful thing

    Build the smallest version that can prove or kill the idea.

  3. 03

    Test it in real conditions

    A system that works in a demo has not been tested.

  4. 04

    Leave it cheaper to change

    Code, decisions and ownership should be legible to whoever inherits them.

07

Work and evidence

Sanitised summaries of past work. No client names, no numbers I cannot show.

  1. Moving onboarding to a new compliance provider

    Regulated financial platform
    Why this mattered
    A legacy onboarding provider had to be replaced while the service stayed live for customers.
    What was getting in the way
    Every step had to be explainable afterwards, and customers could not notice the change.
    The bet I made
    Built the migration tooling, a dry-run harness to test each step first, and reports that compared the data before and after the cut-over.
    What changed
    The migration was completed, and each step could be checked rather than assumed.
    What I learned
    Being able to re-run the migration end to end against real data surfaced problems that reviewing the written plan did not.

  2. Finding why a workflow kept breaking

    Financial operations
    Why this mattered
    A workflow kept failing across several teams and tools, and nobody could say where it broke.
    What was getting in the way
    The work was spread across systems with partial documentation, and it could not be paused.
    The bet I made
    Mapped the real process from tickets, logs and interviews, then narrowed the failures down to two hand-off points.
    What changed
    The team received a plain findings document and an ordered list of fixes.
    What I learned
    Here the failures sat at hand-offs between teams rather than inside any one system, so reading code alone would not have found them.

  3. Making AI features safe to ship

    Internal tooling
    Why this mattered
    A team wanted to ship AI-assisted features but had nothing around them to keep the behaviour and cost under control.
    What was getting in the way
    Sensitive production data, a cost ceiling, and a small team that could not stop to build a platform.
    The bet I made
    Added prompt versioning, a test harness for outputs, and limits wired into the existing build and monitoring.
    What changed
    The team shipped the features with costs they could predict and behaviour they could trace.
    What I learned
    Without versioned prompts and recorded outputs, we could not tell whether a behaviour change came from our own code or from the model.
08

Writing

Read all writing →

09

Building something

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.

Write to me directly →

Elsewhere