Custom software built around how your business already works

Custom software is worth building when the part of your work that matters most is something no standard tool can do, such as a booking rule or a report someone rebuilds by hand every Monday. Zoftaa is a small custom software development company in Pakistan, based in Lahore and fully remote. In the UK this is usually called bespoke software development; it's the same work. This page also says when to buy a product instead.

What we build

We build four kinds of system. The examples below are hypothetical, not past projects.

Booking and scheduling systems

A booking page for customers, a calendar for staff, reminders, and the rules that make your business different: gaps between appointments, deposits, who can take which service, what happens on a late cancellation. Behind it sits an admin panel for staff, services and opening hours.

Example: a tutoring centre with 6 teachers and 3 rooms, where a booking only counts if a teacher and a room are both free. If your booking tool can't express that rule, someone checks the rooms by hand every day.

Here is how we would approach it: write the booking rules as plain sentences, agree them in the plan, and test them against a real week of your bookings before building the customer screens.

Inventory and order management

Stock across locations, purchase orders, transfers between branches, low-stock alerts and barcode scanning with a phone camera. Orders can come from your online store, a marketplace or the counter, and stock drops in one place whichever channel made the sale.

Example: a shop with two branches and a website, where one item can sell in three places within the same hour. The system has to put those sales in order and never sell the last unit twice.

Dashboards and reports

One screen with the numbers someone checks every morning, pulled from your database, spreadsheets, online store or accounting tool. The owner sees sales and margins, a branch manager sees their branch. Slow reports run in the background and arrive by email.

Example: an owner who wants yesterday's sales, refunds and low-stock items on one page at 9am, without anyone opening four tools to collect them.

Internal tools and admin panels

Software your staff use and your customers never see: approvals, job tracking, rotas, customer records, the admin panel behind an app. These usually replace a shared spreadsheet, and come with staff roles and an audit log of who changed what and when.

Example: a delivery company tracking jobs in a shared sheet where three people edit the same row and nobody knows which change came last.

Most of these are web apps that open in a browser on a laptop or phone. If people need an installed phone app (offline use, push notifications, the camera), see mobile app development.

Who it's for

Businesses and founders abroad, in the US, the UK, Europe and the Gulf, who have outgrown a spreadsheet or a SaaS tool and want a small team to build the replacement without hiring in-house.

Businesses in Pakistan: shops, distributors, schools, restaurants and agencies with more than one branch, where the process lives in WhatsApp groups, registers and Excel. We're a software house in Lahore, reachable on WhatsApp during PKT working hours as well as by email.

You don't need to be technical. You need to know how the work runs today and where it goes wrong.

Build or buy: when off-the-shelf software is the better answer

Buy first if a product already does most of what you need. It costs less to start, someone else maintains it, and you can stop paying when you stop using it. If that's our view, we'll tell you on the scope call.

Products we would try before building anything (limits checked 1 November 2026):

• Booking for one person: Cal.com's free plan covers 1 user with unlimited event types and calendars.
• Stock for a small shop: Zoho Inventory has a free plan for 1 user, 50 orders and 2 locations, with paid plans above it.
• Dashboards over Google data: Data Studio, called Looker Studio until April 2026, is "easy and free" in Google's words and has Google-built connectors for Sheets and Analytics. If your numbers sit there, start with it.
• Internal tools for a small team: Retool's free plan covers up to 5 users, in production only, without audit logs, granular roles or external users.
• Tools that don't talk to each other: an automation between them is often enough. That's our workflow automation work with n8n.

Custom software starts to make sense when staff keep a side spreadsheet to work around the product (that workaround is the spec), when data is spread across several tools and nobody trusts the totals, or when you need to own the data and code because a product you rent can change its prices or close.

What we would do: run the closest product with real work for a few weeks and write down every workaround. If the list keeps growing, bring it to the scope call. It's the most useful brief we can get.

How a project runs

1. Scope call. One call to understand the problem and check that we're the right team for it. Bring the spreadsheet, screenshots and workaround list.
2. Fixed written plan. A written scope with milestones, price and dates before any code is written. It lists each role (owner, manager, staff, customer), what each can see and do, the systems it connects to, and what's out of scope.
3. Weekly builds. Every week you get a version you can open and try: a test link in your browser, or a test build on your phone. Try it with real cases, so changes stay small and cheap.
4. Handover. You get the code, accounts and keys, with documentation on how to run and change the system.

To keep improving the system after launch, the product retainer keeps the same engineers on it every month. Payment terms and the rest of the contract are set out in the written agreement for each project.

What you own

Everything the system needs to run is yours, and where we can, it's in your name from the first day:

• The source code, in a repository on your own GitHub or GitLab account.
• The database and every record in it, with a way to export it.
• The hosting and cloud accounts (AWS, Cloudflare, Supabase or Firebase), so the bills come to you.
• The domain, the email sending account and the admin logins.
• The API keys for every outside service, such as a payment provider or an AI model.
• Documentation: how to run it, deploy a change, restore a backup and replace a key, plus every service it depends on.

This matters most on the day you change developers: nothing should depend on us holding a password. How ownership passes to you is written into the project agreement; this page is not legal advice.

Stack and tools

We pick the stack for the system and for whoever maintains it after us. Our defaults:

• Web app and admin panel: React and Next.js (this website runs on Next.js 16).
• API and background jobs: Node.js, or Python with FastAPI for data processing and AI work.
• Database: PostgreSQL. Supabase adds sign-in and file storage on top of it. Firebase suits live updates and phones that go offline.
• Hosting: AWS or Cloudflare, with Docker when the system needs its own servers.
• Phone apps: Flutter, with Swift or Kotlin where a feature needs native code.
• Connecting tools: n8n.
• AI features, such as reading invoices or answering staff questions from your documents: the OpenAI and Claude APIs. See AI chatbots and LLM features.

Habits from the apps and Python backends we've shipped:

• Anything that takes more than about a minute runs as a background job with a progress bar, instead of a page that hangs and times out. In our apps that was video and long documents. In a business system it's a large export or a month-end report.
• Each job gets its own working folder. We learned that when two jobs running at once used the same fixed temporary file names and swapped their outputs.
• A failed step fails the whole job, visibly. One of our jobs once reported 100% complete after its last step had failed, and returned the wrong kind of file.
• New fields are optional and only saved when set, so records saved before an update still open the same way, and older app versions keep working against the new backend.

Timelines

These are the ranges we would plan around. They aren't quotes or averages from past projects. Your written plan gives the real dates.

What moves a project along its range:

• Roles. Each extra type of user adds screens, permissions and tests.
• Integrations. Every outside system (payments, accounting, an online store, WhatsApp) has its own rules and ways to fail.
• Your existing data. Moving years of spreadsheets into a clean database often takes longer than the code that reads it, because real data has duplicates and gaps.
• Offline use. An app that works without signal needs rules for when two people change the same record.
• Review speed. Weekly builds only help if someone on your side tries them that week.

Working with us from abroad

Pakistan time is UTC+5 all year, with no daylight saving (Pakistan Standard Time). Our hours are Monday to Friday, 10am to 7pm PKT, which is 05:00 to 14:00 UTC. Against a 9am to 5pm day:

For US clients we also take calls from 6pm to 10pm PKT (13:00 to 17:00 UTC), Monday to Friday. In New York that's 8am to 12pm in winter (EST) and 9am to 1pm in summer (EDT).

Gulf teams share our full day, though Saudi Arabia works Sunday to Thursday, so with Riyadh that's Monday to Thursday. UK and European teams overlap with us from their morning into the early afternoon. US teams get live calls and urgent replies in their morning, through that 6pm to 10pm PKT window, and can leave notes later in their day for us to pick up the next morning. We agree a weekly call time inside the overlap at the start.

Messages and emails get a reply, usually within one business day.

When we're not the right fit

• You need a standard ERP, POS, payroll or accounting system. Buy a product built for that job.
• You need someone watching the system around the clock. We work Monday to Friday, 10am to 7pm PKT, with no 24-hour on-call desk.
• The system has to pass a formal compliance assessment, such as PCI DSS, which covers anyone who stores, processes or transmits card data. We hold no certifications, so let a payment provider handle the cards.
• You want a large team next month. We stay small on purpose, so the people you talk to are the people who write the code.
• You want coding to start before the scope is agreed. To test an idea fast, see MVP development.
• The budget is fixed below what the scope needs. We would rather cut the scope with you than promise the whole list and miss the dates.

Frequently asked questions

How much does custom software cost?

We don't publish prices on the site. After the scope call you get a fixed price in the written plan, before any code is written. The things that stretch a timeline (roles, integrations, messy data, offline use) also move the price.

Can you work with our existing spreadsheets and tools?

Yes. We can import spreadsheet data once, cleaned up, and connect to tools that offer an API or a data export. If a system has neither, that limits what we can connect, and we'll say so on the scope call.

Do I own the code?

Yes. The code, accounts and keys are handed over with documentation, so you can run the system yourself or give it to another developer. The details go in the project agreement.

Do you build the phone app as well?

Yes, when the system needs one. We build Android and iOS apps in Flutter, with Swift or Kotlin where needed. See Flutter app development.

Can your engineers join our team instead of running a fixed project?

Yes, through the monthly product retainer. See hire developers in Pakistan.

Send a few lines on the contact page: what the system should do, who uses it and what you use today. An engineer will reply, usually within one business day.