Software engineering — Kathmandu, Nepal
We build software
that holds up.
Quorlyn Technology designs, builds and runs web, mobile and AI-enabled systems. We start at the architecture, ship in slices you can use, and leave you with something your team can keep changing after we are gone.
Product engineering
Web · Mobile
AI engineering
LLM · Retrieval
Platform & cloud
Infra · CI/CD
Data engineering
Pipelines · Warehouse
00What we are
A small engineering team that takes a system from the first architecture decision to the release after launch.
Most software does not fail at launch. It fails eighteen months later, when a change that should take a day takes a quarter, and nobody left on the team knows why the system is shaped the way it is.
We build for that moment. Typed boundaries, migrations, tests where they earn their keep, and decisions written down while the reasoning is still fresh — so the second year of a product costs less than the first.
How we work
- Scope
- Fixed in writing before the build starts, with the trade-offs named.
- Visibility
- Running software in a real environment from the first week onward.
- Ownership
- You keep the code, the infrastructure and the accounts. No lock-in.
Six ways we tend to be useful
Engagements usually start with one of these and grow into the others as the system does.
- 01
Product Engineering
End-to-end delivery of web and mobile products — architecture, build, release and the iteration after.
- 02
AI Engineering
Language models, retrieval and automation wired into real systems — scoped to what measurably works.
- 03
Platform & Cloud
The infrastructure underneath: deployment, observability, cost control and the ability to change safely.
- 04
Data Engineering
Pipelines, warehouses and interfaces that turn operational data into something a team can act on.
- 05
Interface Design & Engineering
Design systems and front-end implementation held to the same standard as the systems behind them.
- 06
Technical Consulting
Architecture review, technology selection and a written path forward when a decision is expensive to reverse.
What you are actually choosing
Positioning, not credentials — we are new, and would rather be judged on how we work than on a client list.
Engineering-first
Scope, estimates and architecture come from the people who will write the code. There is no layer between the conversation and the build.
Built to be changed
Most of a system's cost arrives after launch. We optimise for the change you have not thought of yet: typed boundaries, migrations, tests where they earn their keep.
Design as engineering
Interfaces are held to the same standard as the systems behind them — tokens over one-off styles, accessibility and responsive behaviour as acceptance criteria.
Plainly stated trade-offs
Every technical decision costs something. We name the cost, including when the honest recommendation is a smaller build, a different tool, or nothing at all.
The stack, and why it is that stack
We work across these layers. Selection is driven by the problem and the team that will inherit the system — not by what is currently interesting.
Frontend
Typed, component-driven, server-rendered by default. The browser gets as little JavaScript as the feature actually needs.
- TypeScript
- React
- Next.js
- Tailwind CSS
- Vite
- React Native
Backend
Boring where it should be boring. Explicit boundaries, typed contracts, and no framework magic in the domain layer.
- Node.js
- TypeScript
- Python
- FastAPI
- REST
- GraphQL
AI & ML
Model choice is an implementation detail behind an interface. What matters is the evaluation set and the fallback path.
- Claude API
- Vector search
- RAG pipelines
- LangGraph
- PyTorch
- ONNX
Data
One definition per metric, versioned alongside the code that computes it. Pipelines are re-runnable by design.
- PostgreSQL
- dbt
- Airflow
- DuckDB
- Pandas
- SQL
Cloud & DevOps
Infrastructure as code from the first environment, so the path to production is reviewable like any other change.
- Docker
- GitHub Actions
- Terraform
- AWS
- Cloudflare
- Vercel
Databases & Storage
Relational until there is a measured reason not to be. Schema changes ship as migrations, never by hand.
- PostgreSQL
- Redis
- SQLite
- S3
- Prisma
- Drizzle
This list reflects what the team works with today. It is not a menu — if a project is better served by something not on it, we will say so.
Six stages, in the order they actually happen
The shape is consistent; the depth of each stage is not. A two-week integration and a nine-month platform build run the same sequence at different weights.
- 01
Discover
We map the problem before the solution: users, constraints, existing systems, and the decision that actually needs making. Where the scope is larger than the budget, we say so at this stage rather than the last one.
Output — Scope, constraints, success criteria
- 02
Design
Interface and architecture are designed together, because one constrains the other. Decisions become tokens, components and schemas — artefacts the build can use directly.
Output — Design system, data model, architecture
- 03
Engineer
Work ships in vertical slices behind a real deployment pipeline. Something usable runs early and keeps running, so progress is observable rather than reported.
Output — Working software, in an environment
- 04
Validate
Automated tests for the logic, real devices for the interface, and a pass against accessibility and performance budgets. Findings are fixed before launch, not filed after it.
Output — Test coverage, audit results, fixes
- 05
Launch
Release is a routine event: automated deploys, monitoring in place beforehand, and a rollback that has been tested. The first day in production should be uneventful.
Output — Production release, monitoring, runbook
- 06
Evolve
After launch the work is measurement and iteration — usage, cost, performance, and the next most valuable change. Or a clean handover, if that is what the team needs.
Output — Iteration cycle or documented handover
What we are built to take on
Quorlyn is new, and we have no client work cleared for publication yet. Rather than fill this space, here is the kind of problem the team is set up for.
Products from zero
A validated idea that needs architecture, an interface and a first production release — with the engineering set up so the second release is easier than the first.
Systems under strain
An existing codebase that has outgrown its original shape: slow deploys, fragile releases, or a data model fighting the product it now has to support.
AI with a real job
A specific task where language models measurably outperform the alternative — scoped, evaluated, and integrated with fallbacks rather than bolted on.
Next step
Have something worth building?
Tell us what you are trying to make work. If we are not the right team for it, we will say so — and point you at who might be.