Taking on two new projects this quarter

We build your software. You talk to the people buying it.

Firnex is a small software studio in Pakistan working with US companies. SaaS products, AI where it actually pays off, and the internal tools your team has been doing by hand. We work evenings so your mornings are covered.

Your morning is our evening, on purpose

We hold a fixed window every working day that covers your morning and runs into your early afternoon. Inside it you get answers in minutes rather than tomorrow. Outside it we work asynchronously, which is where most of the actual building happens.

New YorkET

--:--

7am – 2pm shared working window

IslamabadPKT

--:--

4pm – 11pm shared working window

Teams we have built for

Services

Three things we do

We do not take on everything. These are the problems we are good at, and what an engagement actually produces.

SaaS product development

Net-new products, built to be maintained. From a written spec, or from a rough idea you have been carrying around for months.

First usable version in 3–6 weeks

What we build

  • Multi-tenant web apps
  • Auth and billing
  • Customer dashboards
  • Admin and back-office
  • Public APIs
  • Third-party integrations

Best for. Founders with funding and a product that needs real users, not another design file.

You end up with. A deployed application and the infrastructure it runs on, in your GitHub organisation from the first commit.

AI in a business that already runs

Putting language models into work that already happens every day. The hard part is not the model — it is knowing how often it is wrong and what that costs you.

Scoped pilot on your data in 2–3 weeks

What we build

  • Document extraction
  • Support triage
  • Retrieval over internal docs
  • Drafting and summarising
  • Evaluation harnesses
  • Human-in-the-loop review

Best for. Companies with real volume and a process that quietly eats hours every week.

You end up with. A working integration inside the tools your team already opens, plus an evaluation set so accuracy is measured rather than assumed.

Internal tools and automation

The unglamorous software your operations run on. Usually this starts as a spreadsheet nobody is willing to touch any more.

Most tools in 2–6 weeks

What we build

  • Approval workflows
  • Reporting and exports
  • System-to-system sync
  • Data cleanup and migration
  • Scheduled jobs
  • Internal admin panels

Best for. Operations and finance leads whose team repeats the same manual sequence every week.

You end up with. A tool your team uses without training, and the boring documentation that keeps it usable after we are gone.

How an engagement runs

Four steps. The point of writing them down is that you can hold us to them.

  1. Step 1: A call

    30 minutes

    You describe the problem. We ask about the parts that usually go wrong. At the end you get a straight answer on whether we are the right team and what we would do first. No deck, no discovery invoice.

  2. Step 2: A written scope

    Two to four days

    What we build, in what order, what it costs, and — the part most scopes leave out — what we are deliberately not building. Fixed price on the first milestone so you are not underwriting our estimate.

  3. Step 3: The build

    Weekly rhythm

    A demo of working software once a week, on the same day. A written update mid-week covering what moved, what is stuck, and what we decided without you. Repository access from the first commit.

  4. Step 4: Handover

    End of engagement

    Deployed, documented, and yours: code, infrastructure, credentials, and a written record of why things are the way they are. We stay reachable afterwards, and we do not hold anything hostage to a retainer.

How we work

Four commitments that shape everything above.

Small on purpose
A small team. No account manager relaying your question to someone who has not read the code. When you send a message, an engineer reads it.
Written by default
Decisions live in writing where you can find them six months later, not in a call nobody took notes on. Meetings are for the things that genuinely need a conversation.
We tell you no
If a feature is going to cost more than it returns, or the thing you asked for is not the thing you need, you will hear it before the invoice, not after.
Your code is yours
Your repository, your cloud accounts, your dependencies, permissively licensed and documented. Nothing about the handover requires us to still be involved.

What clients say

“I have been working with Abdul for over 18 months and the outcome has been a delight. Communicates clearly and delivers within promised timeline. Plus, he always kept me in the loop about his availability, which was super helpful.”
Shariq AnsarFoundermyTpen · via Upwork
“I was extremely impressed with Abdul's work on our summer camp matching system. His expertise in TypeScript, OpenAI, and Postgres was evident in the clean and efficient code he produced.”
Carl NganCTOThe Camp Stack · via Upwork

Who you will be working with

Directly, and from the first call. No account manager relaying your question to someone who has not read the code.

Why Firnex exists

Most software gets built with a stack of people between whoever is paying and whoever is typing. Requirements get relayed, context is lost in the relay, and the person who understands the tradeoff is not in the room when it gets decided.

Firnex removes the relay. You talk to the engineer doing the work, in a fixed window every day that covers your morning, so distance costs you hours instead of days.

We are early, and we would rather say that than pad a client list. What is here is real.

  • Abdul Rehman, Principal engineer

    Abdul Rehman

    Principal engineer

    Abdul leads development at myTpen, where he has shipped nine EdTech applications in under two years, and built The Camp Stack's matching engine across 100,000+ profiles and 1,500+ camps. He works in TypeScript, Node, and Python on AWS and Cloudflare, and spends most of his time on the part that decides whether an AI feature ships at all: knowing how often it is wrong.

What we take responsibility for

Four kinds of system. Most engagements are one of them; some are two that have to talk to each other.

Product platforms
The application your customers log into — accounts, permissions, billing, and the admin surface your team runs it from.
AI engines
Retrieval, extraction, and classification pipelines with evaluation built in, so accuracy is a number you can see rather than a promise.
Cloud workflows
The automated middle of a business: systems kept in sync, scheduled work that runs unattended, and the alerting for when it does not.
Data and reporting
Getting numbers out of the systems holding them, cleaned and reconciled, into something a person can actually make a decision from.

Built with TypeScript, Python, Postgres, and the major cloud providers. We pick boring, well-supported tools and reserve the novelty for your problem.

Tell us what you are trying to build.

A 30-minute call. You describe the problem, we tell you whether we are the right team for it and what we would do first. If we are not, we will say so.

Shared working window

7am – 2pm ET