NODE:0

Romesh Niriella

Software engineer · Systems builder · Father

I help founders turn an idea into working software.

I have spent more than 12 years building software for financial and regulated businesses, travel booking engines and CRM systems.

I help founders understand what needs to be built, choose a practical first version and create software that can grow without becoming difficult to change.

01

What are you trying to build?

I can help you understand the problem, decide what must be built first and create a system that can grow without becoming a trap.

02

How I can help

From idea to first working version

Turn a rough idea into a clear technical plan and a usable first version.

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

System review

Review an existing product or technical plan before more money and time are committed.

architecture review · workflow mapping · hidden assumptions · failure points · security and operational risks · practical next steps

Difficult systems

Help untangle software and operations that have become difficult to understand or change.

mapping the current system · finding where responsibility is unclear · identifying fragile dependencies · reducing manual work · making future changes safer

03

Who I want to work with

I want to work with founders who understand a real problem and care about building something useful.

I am especially interested in working with founders in Sri Lanka, parts of Africa and other markets where products often have to be built with tighter budgets, fewer specialists and infrastructure that cannot be assumed.

Local knowledge comes first. I bring software engineering, system design and experience building regulated products.

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

How I work

  1. 01

    Understand the real problem

    Before building software, understand the people, constraints and environment around it.

  2. 02

    Build the smallest useful thing

    Start with the smallest version that can prove whether the idea works.

  3. 03

    Test it in real conditions

    A system is not finished because it works in a demonstration.

  4. 04

    Leave it clearer

    Code, decisions and responsibilities should be understandable by the people who inherit them.

06

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
    Problem
    A legacy onboarding provider had to be replaced while the service stayed live for customers.
    What made it difficult
    Every step had to be explainable afterwards, and customers could not notice the change.
    What I did
    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
    Problem
    A workflow kept failing across several teams and tools, and nobody could say where it broke.
    What made it difficult
    The work was spread across systems with partial documentation, and it could not be paused.
    What I did
    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
    Problem
    A team wanted to ship AI-assisted features but had nothing around them to keep the behaviour and cost under control.
    What made it difficult
    Sensitive production data, a cost ceiling, and a small team that could not stop to build a platform.
    What I did
    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.
07

Writing

Read all writing →

08

Building something?

Send me a short description of the problem, who it is for and what currently exists.

I will tell you whether I can be useful.

Message me on LinkedIn →

Elsewhere