Galle, LK--:--5/6 sites live
S·SSithum Sithara

How I think

How I think

The habits behind the work — how I research, decide what matters first, test things until they break, use automation and AI, find opportunities, pay for things, and work with people. Every principle here links to a project or story where it actually happened.

Problem solving

The loop I repeat

Six steps, in order, on almost every project. The last one feeds the first.

  1. 01

    Start from a real constraint

    A competition brief, a CCTV storage bill, a Sinhala font that breaks in a renderer, a client losing leads to email. The constraint defines the problem better than any idea does.

    Seen in: Quintrix ITSO research question
  2. 02

    Research before building

    Read the docs, the papers and the existing code first. Cite where every equation and number comes from, and mark which ideas are mine.

    Seen in: 14 cited equations in EC06
  3. 03

    Draw it, then prototype the riskiest part

    Sketch states and edge cases on paper, then build the smallest thing that proves the hardest rule works.

    Seen in: The Part Timer's 42-sheet drawing set
  4. 04

    Measure — and believe the numbers

    Run it on real data. Measurement finds the bugs that reading code never will, including the ones in your own success metrics.

    Seen in: A '78% saving' that was really −3%
  5. 05

    Fix what measuring found, then lock it in

    Every defect found by measuring gets a regression test, so it can't come back quietly.

    Seen in: 173 tests, one per defect
  6. 06

    Write it down for the next person

    READMEs, runbooks, limitations and 'what I'd change next'. If someone can't redeploy it without me, it isn't finished.

    Seen in: How I Ship 23 Projects

Principles

What I consider, area by area

Research & findings

“Ask a question you can answer with a number, then report the boundary of the evidence — not just the headline.”

  • Frame the research question precisely: can content-aware tiering reduce storage while prioritising important footage?
  • Correct my own documents when the build disagrees — Flask, X3D-S and 84.6% became FastAPI, R3D-18 and a measured 60.0%.
  • State limitations as the edge of the evidence: 17 videos, one platform, an expert-made rubric.
Quintrix ITSO

Optimisation & connected routing

“Optimise the path, not just the step — and show what the optimiser saved.”

  • Route planning uses a nearest-neighbour seed plus 2-opt over road-factored distance tuned for Sri Lankan roads, and reports optimizer_saved_km.
  • Network routing: when api.binance.com is unreachable, requests fail over to api1–api4 — but an order that may already have been delivered is never re-sent.
  • Pipeline routing: path filters send a push to only the service that changed.
  • Storage routing: each 15-second segment is routed to HIGH, MEDIUM or LOW by what happens in it.
Nora Labs routing CryptoEdge failover

OTAs & integrations

“Integrate honestly: generate what you can stand behind, never claim data you don't have.”

  • Nora's OTA agent turns a sentence into structured Agoda and Booking.com searches and deep links.
  • It never scrapes or claims live availability or prices — query generation, not scraping.
  • Affiliate IDs are configuration, so a commercial partner can be added without code changes.
Nora Labs OTA agent

Prioritisation

“Prioritise against the worst mistake, not the average case.”

  • In Quintrix the dangerous error is a critical event stored LOW — so thresholds were calibrated on the critical-to-LOW miss rate (6.43% → 1.27%).
  • A critical hazard floors the decision to HIGH, whatever the score says.
  • Error budgets decide when to ship features and when to stop and fix reliability.
  • Scaling limits are written next to the flags that enforce them, so the priority is visible.
Threshold calibration SRE in practice

Stress testing

“If it hasn't failed under load in front of me, I don't know how it fails.”

  • Quintrix's first concurrency test failed 0/100; a bounded worker pool fixed it to 100/100 in 551 s.
  • 15,576 of 15,576 load-test requests answered; P99 ≤ 18 ms on every endpoint.
  • Nora's smoke script walks all 155 route calls before a demo.
  • React Content Studio runs 145 end-to-end checks on the real bytes written to disk.
Quintrix results

Automation with human gates

“Automate the loops; keep a person in front of anything irreversible.”

  • Two trading bots taught me that logs are activity, not outcomes — 61 trades, −$67.88, a 'profitable' file full of test rows.
  • Deploy scripts print what they would do and only create resources with --apply.
  • Real money needs a typed LIVE; LOW-tier deletion waits 72 hours in a review queue.
The $67.88 lesson Human effort story

How I use AI

“AI is a collaborator and a component — never the only path, never the final decision.”

  • Every Nora agent has a deterministic fallback; responses say which engine answered.
  • In The Part Timer, twelve verification agents recommend; a human approves.
  • MCP tools let AI act on real systems through verifiable tools — the open-source cisco-pt-mcp in my network labs, React Content Studio in my own work.
  • When AI assistants work in parallel on a codebase, a human reconciles and decides what survives.
Nora Labs AI Network Labs

Grabbing opportunities

“Say yes to deadlines that come with an audience — then ship something real for them.”

  • Tourthon 2026 became Nora Labs: 11 agents and a live demo, not just slides.
  • InOrbit: Quintrix placed 2nd among all technology projects.
  • SLUG 2025: the university games needed fixtures, results and a leaderboard online — at zero cost.
  • Found cisco-pt-mcp, a well-made open-source tool, and built a course and labs around it instead of reinventing it.
Achievements

Funding & cost

“Spend money only where the code needs it; pay for identity, not idle servers.”

  • Budget alerts before the first VM.
  • Seasonal, read-heavy sites run on zero-cost hosting; permanent ones pay only for the domain.
  • One Coolify VM under $10/month instead of many paid plans.
  • A competition, a client or a sponsor funds the work best when the demo already runs.
Paying for cloud as a student Zero-cost hosting

Letters, proposals & writing

“Write so the reader can decide quickly — the ask, the evidence, the risk, the next step.”

  • Competition proposals include a risk table — and Nora's architecture was built to honour it.
  • Project documents move from proposal to SRS, SDS and evaluation reports, each answering the last round of comments.
  • Every project ends with a README that a stranger (or a client's nephew) can follow.
Every EC05 comment answered

What I read

“Read primary sources — official docs, papers, source code and error messages — before tutorials.”

  • Cloud provider docs for the edge cases tutorials skip (new projects have no Cloud Build default service account).
  • Papers for methods I reuse, cited where they're used (weighted late fusion, Atrey et al. 2010).
  • Course notes rewritten in my own words — and in Sinhala — until I can teach them.
Networking, bilingual W3DevOps course

Human connections

“The work is for people, and it's built with people. Prioritise the ones who depend on it.”

  • First: the people who depend on the work — users, clients, the student reading results between matches.
  • Then the team I'm accountable to, and the supervisors and mentors who review it.
  • Then the wider community — AIESEC, InFocus, classmates — where helping is the point.
  • Protect people's trust in what I build: clients' sites store no enquiries; budgets are hidden in the API, not with CSS.
Achievements & roles

Teamwork & shared goals

“Shared goal, clear ownership: everyone knows which part is theirs and how it connects.”

  • Quintrix was five people with five owned areas — mine was upload, segmentation, tiered storage and the review queue.
  • Running several things at once works when each has its own goal, its own owner and its own write-up.
  • Dual control where trust matters: payouts need two different people.
Team Quintrix

Helping & education

“Explain it in the language people think in; keep the terms they'll be examined on.”

  • Bilingual networking chapters, SRE labs and DevOps notes.
  • A Self Guide so anyone can follow the same path at their own pace.
  • Keep the failures in the screenshots — learners trust material that admits things break.
Self Guide Teaching in Sinhala

Think like me

The questions I ask before I build.

Use it on your next project. If any answer is “I don't know yet”, that's the next thing to find out.

Start the Self Guide Talk to me
  1. 01What is the real constraint — and who feels it?
  2. 02What's the worst mistake this could make, and how will I know if it makes it?
  3. 03What number would prove it works? What number would embarrass it?
  4. 04Which part is irreversible — and where is the human in front of it?
  5. 05What happens when the AI, the network or the free host is down?
  6. 06What does it cost per month, and who pays when I'm gone?
  7. 07Who owns each part, and do we share the same goal?
  8. 08Could a stranger redeploy this from the README?
  9. 09Who else would benefit if I explained this well?