Open to backend roles & freelance · Kathmandu, Nepal

I build the systems governments and businesses run on.

Ajay K. Singh — software engineer with 5+ years of PHP and Laravel behind enterprise and public-sector software in Nepal: municipal management, electronic building permits, hospital reservations, and my own business products in production. I take a requirement to a schema, an API, an integration, and the maintenance after it ships.

Email me CV
  • 5+ yrsPHP & Laravel in production
  • GEA 2.0Gov’t standard delivery
  • 2 liveProducts built solo
Ajay K. Singh
Kathmandu, Nepal · NPT (UTC+5:45)
5+years in production
10+systems contributed to
4engineering teams
2products live & mine
GEA 2.0gov’t standard
M.E.in progress, NCIT

Selected work

Three case studies

Same structure every time: the problem, what I owned, how it works, what it cost. Open one to read the detail.

Problem
A building permit is a chain of custody: an applicant submits, a ward verifies, an engineer reviews, a municipality approves — each step binding, each step contestable later. The software has to prove who did what, hold up against the Government Enterprise Architecture 2.0 review, and exchange data with systems built by other vendors.
What I owned
Application features and backend services inside the engineering team: data models, Laravel services, RESTful APIs consumed by internal and external systems, SQL and query performance work, and defect triage on live municipal deployments. name the specific modules — permit intake? plan approval? reporting?
How it works
Every application is a state machine rather than a status column, so an approval can only follow a verification. Role-based access is checked at the service layer, state transitions are written with the record in one transaction, and the integration surface is a versioned REST contract rather than direct database access by other vendors.
Tradeoffs
Modelling permits as explicit state machines cost more up front than a status field and made ad-hoc change requests slower to land. It paid for itself the first time somebody asked who approved a permit eleven months earlier.
Outcome
Systems running in municipal use. add the number you can defend: municipalities or wards live, permits processed, or “passed GEA 2.0 review”
Applicantsubmits Wardverifies Engineerreviews Municipalityapproves Append-only audit logwho · what · when, per transition REST contractother agencies & vendors
No transition writes without its audit row — they share a transaction.
  • Laravel
  • PHP
  • PostgreSQL
  • MySQL
  • REST
  • RBAC
  • GEA 2.0

Government deployments — not publicly linkable. Happy to walk through the architecture in a call.

Problem
Small business owners in Nepal often run several entities out of one notebook. Mixing them makes the year-end impossible; separating them into different apps makes the daily entry too slow to actually do. And Nepali fiscal years don’t line up with the Gregorian calendar, so “this year’s books” is not a date range you can hardcode.
What I owned
All of it — design, schema, backend, interface, deployment, and the support afterwards. Built independently, running in production.
How it works
Every record is scoped to a business and a fiscal year at the query layer, so a forgotten filter can’t leak one business’s cash into another’s report. Users and roles are per business, meaning an owner can give a staff member entry rights on one shop without opening the books on the rest. Reports read from the same scoped queries, so the summary and the ledger can’t disagree.
Tradeoffs
Enforcing scope globally means any genuinely cross-business view has to be written deliberately — slower to add, but it makes a data leak between tenants a conscious act rather than an accident.
Outcome
In production and in daily use. add what you can verify: businesses registered, transactions recorded, or how long it has run without data loss
Ownerone login Business A Business B Business C Fiscal year scopeB.S. aware Rolesper business Ledgercash in / out
Scope is applied before the query runs — reports and ledger share one source of truth.
  • Laravel
  • MySQL
  • RBAC
  • Multi-tenant
  • Reporting

Open BizBook ↗

Problem
A reservation isn’t confirmed until it’s paid, and payment lives in a point-of-sale system built by somebody else. If the POS confirms and the application doesn’t hear about it, a patient holds a receipt for a slot the system thinks is free.
What I owned
Reservation and scheduling workflows, the integration against the external POS, and the payment-related application functionality — including what happens when the two sides disagree.
How it works
A slot is held the moment a reservation starts, so the window can’t be double-sold while payment is in flight. Confirmation comes from the POS, not the browser, and is applied idempotently on its reference, so a repeated callback changes nothing. Anything left holding is re-queried rather than assumed failed, and released only after that check.
Tradeoffs
Holding slots pessimistically costs availability during busy periods and needs a release path for abandoned attempts. The alternative — optimistic booking — trades that for double-booked patients, which is not a tradeoff worth making in a hospital.
Outcome
add what improved: reservations handled, mismatches between POS and app, or support load before and after
Reservationslot held External POStakes payment Confirmationidempotent Bookedslot committed Reconciliation sweepre-queries every slot still held
The POS is the source of truth; the sweep makes sure the application eventually agrees with it.
  • Laravel
  • REST
  • POS integration
  • Payments
  • Idempotency

Client system — architecture walkthrough available on request.

Also shipped

The rest of the shelf

Contributions and independent builds, grouped by what they are.

Government & public sector

  • Municipality Project Management SystemMunicipal plans, programmes and the workflows around them.
  • EPISInformation management system — application features and system functionality.
  • Red Cross MISOrganisational information and operational process management.

Enterprise & commerce

  • E-commerce & POS systemsBackend operations, application features and system integrations.
  • Service-commerce integrationsThird-party services wired into business applications.

Independent builds

  • Shivam Group HolidayTravel and tour platform — packages, destinations, enquiries. shivamholiday.com ↗
  • Multivendor e-commerceLaravel marketplace — vendor onboarding, catalogue, order splitting. repo link
  • News portalPHP, Bootstrap and jQuery publishing portal with an editorial workflow. repo link

Experience

Five years,
four teams

Written as what I was responsible for, not what the team shipped around me.

Download CV

  1. Sep 2022 — Present

    Software Engineer · Code For Core Innovation

    Durbarmarg, Kathmandu

    • Build and maintain enterprise and government web applications in PHP and Laravel, including systems aligned to GEA 2.0.
    • Design and integrate RESTful APIs between internal applications and external systems.
    • Own database design, SQL and performance work on relational data.
    • Translate business requirements into features; debug, harden and maintain what’s already live.
  2. May 2021 — Aug 2022

    PHP / Laravel Developer · Ekbana Solutions

    Lalitpur

    • Built and maintained in-house and client web applications.
    • Designed REST APIs for application communication and third-party integration.
    • Implemented data models and backend workflows against client requirements.
  3. Dec 2020 — May 2021

    PHP / Laravel Developer · Next Nepal

    Kathmandu

    • Integrated payment gateways and the transaction workflows behind them.
    • Built application APIs for data exchange with third-party systems.
    • Debugging, bug fixing and performance optimisation on live applications.
  4. Nov 2019 — Feb 2020

    Web Developer, Intern · Multitech Support & Development

    Kathmandu

    • First production PHP and Laravel work, on real client projects.

Stack

Rated honestly

Grouped by how much of it I touch in a normal week, so an interview starts in the right place.

Daily

  • PHP
  • Laravel
  • REST APIs
  • MySQL
  • PostgreSQL
  • JavaScript
  • Git / GitHub

Comfortable

  • Vue.js
  • jQuery
  • Bootstrap
  • Tailwind CSS
  • HTML5 / CSS3
  • Payment gateways
  • Third-party integration

Working knowledge

  • React.js
  • MongoDB
  • GitHub Actions
  • CI/CD
  • Application testing

Across all of it: system integration and interoperability, SDLC practice, debugging live systems, and performance work on applications that got slow as they grew.

About

Engineer first,
framework second

I’ve written production PHP since an internship in 2019 and have spent most of the years since on software that other people depend on being correct — municipal permits, hospital reservations, cashbooks that have to balance. Laravel is the tool I reach for; the part I care about is the data model underneath and whether the thing still behaves when a request fails halfway.

I’m currently taking a Master’s in Computer Engineering at NCIT alongside full-time work, with the interest pointed at enterprise software, system integration and the digital transformation of public services — which is, conveniently, what I do all day.

I like inheriting a messy codebase and leaving it legible. I like requirements that arrive as a problem rather than a spec. And I like it when the system is still running a year later without anybody calling me.

Based in
Kathmandu, Nepal — open to remote
Studying
M.E. Computer Engineering, NCIT — 2022 to present
Degree
B.E. Information Technology, Cosmos College — GPA 3.74/4.00, Dean’s List
Training
PHP with Laravel, Broadway Infosys · Basic MATLAB, Cosmos & RAIT
Languages
Nepali & Maithili (native) · English (professional)

Contact

Got something
that has to keep working?

Hiring for a backend role, outsourcing a build, or sitting on a system nobody wants to touch — send it over. I read everything that comes in and answer within a day.

Email me