Skip to content
01Personal

Beyond the screen.

Engineering discipline does not switch off at the terminal. Outside technology it goes into training, consistency, and a standing willingness to be somewhere uncomfortable.

Subarna Poudel in a climbing harness at the Kushma swing, standing beside a staff member giving a thumbs up, with the gorge and suspension bridge behind them.

Clipped in at Kushma, a few seconds before the drop

Parbat, Nepal

01 / 08

Strength & fitness

I train consistently and pay attention to nutrition, discipline and steady improvement. Fitness is not about appearance for me — it is the cheapest available practice in doing something difficult on a schedule, which is most of what engineering is too.

Discipline in engineering.
Discipline in life.

Consistency
Showing up on the days it is inconvenient is the entire method.
Strength training
Structured progression, honest form, no shortcuts around the hard lifts.
Nutrition
Planned rather than improvised — the boring input that makes the rest work.
Resilience
Training the tolerance for difficulty, which transfers directly to debugging.

The rest of it: mountains, long rides, and the occasional very bad idea at height. Nepal makes all three easy to find.

Gokarna, Kathmandu, Nepal · Working Remotely

Subarna Poudel — Electronics Engineer · Senior Software DeveloperFrom the sensor to the screen.

I work at both ends of the stack — embedded C++ and hardware prototyping at one end, backends, APIs and mobile applications at the other — and on the problems that only appear where the two meet.

See the workStart a conversation

Currently Senior Software Developer at Expogenius, Copenhagen, Denmark — working remotely from Kathmandu.

A schematic of the system layers Subarna works across: hardware, embedded logic, backend, application, and interface, with a signal travelling from the lowest layer to the highest.
HardwareL0 · STM32 · Arduino · SensorsEmbedded LogicL1 · C++ · Registers · Bit-shiftsBackendL2 · Node.js · APIs · FirebaseApplicationL3 · Business logic · StateInterfaceL4 · React Native · Android

The stack, as the work actually sits in it

02Selected Work

Three systems, at three different heights of the same stack.

One mobile application with real computation under it, one embedded system with an unforgiving loop, and one piece of business-critical infrastructure where the hard part is keeping money and state in agreement.

Figures are structural schematics, not product screenshots

Mobile · Calculation Logic

Jyotish App

An Android application focused on Jyotish and Kundali functionality.

An astrology domain is deceptively computational: the interface is calendars and charts, but underneath it is deterministic calculation that has to agree with itself every single time. The work sits in the boundary between a mobile application architecture and the calculation logic it depends on.

Where the engineering sits

  • Application architecture
  • Kundali / chart generation flow
  • Deterministic calculation logic
  • Native computation in C++
  • Android
  • C++
  • Application Architecture
14710ENGINE
Embedded · Hardware Logic

Embedded Radar Speed Sign

Engineering and simulation work involving embedded systems, C++, bit-shifting logic, and hardware-oriented processing.

A speed sign is a small system with an unforgiving loop: a sensor produces a reading, embedded logic conditions it, and a display has to show the right number at the right moment. Working on it in simulation and on STM32/Arduino environments meant thinking in registers and bit-shifts rather than objects and abstractions.

Where the engineering sits

  • Sensor acquisition
  • Bit manipulation / bit-shifting logic
  • Embedded processing loop
  • Display output
  • Simulation before hardware
  • C++
  • STM32
  • Arduino
  • Embedded Systems
  • Simulation
SENSORPROCESSINGEMBEDDED LOGICDISPLAYvalue << 1
Systems · Business Logic

B2B Travel CRM Systems

System-design and development work involving travel workflows, CRM processes, financial integrity conditions, and structured business logic.

B2B travel is a workflow problem before it is a software problem: agents, bookings, and money move through states that must stay consistent with each other. The interesting engineering is in modelling those states, and in the financial integrity conditions that must hold no matter which path a record took to get there.

Where the engineering sits

  • System architecture
  • Workflow / state design
  • Structured business logic
  • Financial integrity conditions
  • B2B agent processes
  • Node.js
  • TypeScript
  • System Design
  • APIs
AgentB2B ACCOUNTBookingWORKFLOW STATEInventorySUPPLYLedgerFINANCIALINTEGRITY HOLDS
03Capability

One stack, worked top to bottom.

Read it the way a user meets a product and the way a signal travels back down to the board. Every technology appears once, at the layer it belongs to.

The work I want is between the layers

Most engineers are hired into one band of this stack. My training is in electronics and my practice is in software, so the problems I am most useful on are the ones that cross a boundary — a C++ calculation engine that has to feel instant behind a React Native screen, or a sensor reading that has to survive the trip into something a person relies on.

Comfortable at every layer below —
most useful at the joins

  1. Interface

    L3

    The part a person actually touches — mobile screens, application state, and the interactions between them.

    • Mobile applications
    • Application architecture
    • State and data flow
    • Practical user experience
    • React Native
    • Expo
    • Android

  2. Application & Backend

    L2

    Services, APIs and the business rules underneath them, including calculation engines that have to stay correct every time they run.

    • Backend systems
    • APIs and integrations
    • Structured business logic
    • High-performance calculation engines
    • Node.js
    • Firebase

  3. Embedded Logic

    L1

    Firmware-level work — registers, bit manipulation and processing loops with no room to be approximately right.

    • Bit manipulation and shifting logic
    • Embedded processing loops
    • Sensor acquisition
    • Simulation before hardware
    • Embedded C++

  4. Hardware

    L0

    Boards, sensors and prototypes. The layer that does not forgive — and the reason the ones above it get built carefully.

    • Hardware prototyping
    • Microcontroller platforms
    • Signals and circuits
    • STM32
    • Arduino

Languages

  • C++
  • TypeScript
  • JavaScript

Tooling

  • Expo EAS
  • Apidog
  • Locofy.ai
04Approach

Engineering is about systems, not just code.

Four things I keep coming back to. None of them are original — they are just the ones that have cost me enough time to become habits.

  1. 01

    Understand the whole system first

    A bug is rarely where it appears. Before writing code I want to see the whole path — where the signal starts, what transforms it, and what finally consumes it. Most hard problems dissolve once that path is drawn honestly.

  2. 02

    Solve the underlying problem

    It is easy to patch a symptom and call it shipped. I would rather spend the extra hour finding the condition that produced it, because the same condition will come back under a different name.

  3. 03

    Reliability comes from architecture

    Clear boundaries, predictable data flow, and one obvious place for every decision. Every dependency and configuration flag is something a future engineer has to carry, so complexity should justify itself before it is allowed in. When the structure is right, correctness is cheap to maintain.

  4. 04

    Respect the edge cases

    Hardware taught me this. A radar signal, a dropped connection, a rounding error in a financial condition — the edge case is not an exception to the system, it is the system on a bad day.

The same preference, in the tooling

The same preference shows up in how the machine is set up. I run Arch Linux with the Hyprland compositor, Waybar and a Kitty terminal — keyboard-driven, no window arranging, and identical every time it boots. A development environment that behaves predictably is the same thing I want from a build pipeline.

OS
Arch Linux
Compositor
Hyprland
Bar
Waybar
Terminal
Kitty
hyprlandktm
kitty — fastfetch

~ ❯ fastfetch

os
Arch Linux x86_64
wm
Hyprland
bar
Waybar
term
kitty
shell
zsh

~ ❯

nvim — engine.cpp

41uint16_t frame = (hi << 8) | lo;

42if (frame & STATUS_MASK) {

43emit(decode(frame));

44}

btop

hyprlandrunning

waybarrunning

kittyrunning

Tiling · keyboard-drivenMinimal environment · Maximum control

Interactive — select a workspace to re-tile the layout

05Profile

Equally at home in a datasheet and an application layer.

I think the two are the same job seen from different heights — which is why a habit learned debugging hardware keeps paying off three layers up.

Subarna Poudel, photographed outdoors in Nepal beneath strings of prayer flags.

Gokarna, Kathmandu, Nepal

I am an Electronics Engineer and Senior Software Developer driven by a passion for building robust systems that bridge the gap between hardware and software — from complex full-stack architectures down to prototyping embedded devices.

My training is in electronics, which means my instinct is to ask what is physically happening before asking what the code says. A dropped packet, a mistimed interrupt and an inconsistent database write are, structurally, the same class of problem: state that stopped agreeing with itself. That habit follows me up the stack.

Day to day I build applications — backends, APIs, mobile interfaces and the business logic underneath them. But the work I find most interesting sits at the seams, where a calculation engine written in C++ has to serve a React Native screen, or where a sensor reading has to survive the trip into a product someone actually uses.

I still prototype hardware because it keeps me honest. Software forgives; hardware does not. Between the two I have settled into a way of working that is curious, methodical and unfinished — there is always another layer worth understanding properly.

Discipline
Electronics Engineering
Practice
Senior Software Development
Based in
Gokarna, Kathmandu, Nepal
Arrangement
Remote · Full-time at Expogenius

How the range got built

An evolution of focus, not a chronology — no stage replaced the one before it

  1. Foundation

    Electronics Engineering

    Signals, circuits, and reasoning about a system you cannot simply restart.

  2. Firmware

    Embedded Systems

    Close to the hardware — embedded C++, bit-level logic, prototyping and simulation.

  3. Application

    Software Development

    Up the stack, where the same systems thinking applies to state and business rules.

  4. Product

    Full-Stack & Mobile

    End-to-end delivery: backends, APIs, and the mobile applications on top of them.

  5. Current

    Senior Software Development

    Architecture and delivery across software and hardware-adjacent systems.

06Photographs

The places the discipline gets spent.

Mostly Mustang and the roads to it. Each frame is shown at the proportions it was taken in — select any one to see it full size.

07Contact

Let’s build something interesting.

I take on technically demanding problems where software, hardware and systems engineering have to agree with each other.

Open to

  • Hardware / software integration
  • Embedded systems
  • System architecture
  • Full-stack & mobile products
  • Calculation-heavy applications
  • Technical due diligence

Gokarna, Kathmandu, Nepal · Working Remotely · Asia/Kathmandu

If a problem sits between disciplines — a calculation engine that has to feel instant on a phone, firmware that has to talk to a product, a workflow that has to stay financially consistent — that is the kind of work I want to hear about.