Build — App
Mobile app development in Kathmandu.
Nine Technology builds Android and iPhone apps for businesses in Nepal, engineered to feel fast on mid-range phones and weak connections. Every app is priced in a written proposal — and where a progressive web app meets the need at far lower cost, that is what we recommend.
- One app, both stores
- Android and iOS
- Real devices, weak networks
- Mid-range tested
- Submission and approval handled
- Store-ready
- Post-launch support
- 60 days
What we build
One app for both stores, and the dashboard your team uses to run it.
-
Customer apps
Ordering, booking, loyalty and customer accounts.
-
Staff and field apps
Orders, deliveries, attendance and stock checks on the move.
-
Apps that take payment
eSewa, Khalti and Fonepay, and store billing for subscriptions.
-
Logins and accounts
Phone-number sign-in with a one-time code, profiles and roles.
-
Apps on your existing system
Connected to the software or website you already run.
-
An admin dashboard
Manage content, users and orders without a developer.
The right product for the job
Most businesses are best served by a mobile website or a progressive web app. We recommend a native app only when the product requires one — and we make that recommendation before any money is spent.
| Aspect | Progressive web app | Native app |
|---|---|---|
| Installed from | The browser, on any phone | The App Store and Play Store |
| Typical timeline | A few weeks | 8–16 weeks |
| Relative cost | Lower | Higher |
| Store approval | Not required | Required for every release |
| Offline use and notifications | Basic | Full |
| Best suited to | Most businesses | Products customers use every day |
A native app is the right choice when
- Your customers use it daily
- You need push notifications
- It must work offline
- You need in-app payments
- The app is the product, not a brochure
Risks we design out
The four most common reasons apps fail after launch, and how each one is prevented before development begins.
-
Store rejection
Privacy details, permissions and store policies are prepared before submission, not after a rejection.
-
Payments against store rules
The correct billing method is chosen at design stage, so payments are not blocked at review.
-
Slow on weak networks
Screens show stored content first and update when the connection allows.
-
A first screen that asks too much
Onboarding shows value before it asks the customer for details.
Payments and subscriptions
Physical goods and services — food, bookings, deliveries — can be paid with eSewa, Khalti or Fonepay inside the app. Digital content and subscriptions usually have to use Apple's and Google's own billing. We set up whichever the store rules require for your app, so it is not rejected at review.
Built for Nepali phones and networks
- Tested on mid-range Android phones, not only flagships
- Loads what it can while the connection catches up
- Keeps working offline where your app needs it
- Clear type and large tap targets
- Nepali and English interface where you need it
What you receive
Delivered complete: built, tested, published and supported.
The product
- One app, both stores — Android and iPhone
- Push notifications set up and ready
- In-app payments if you need them
Quality
- Tested on the phones your customers actually own, not just a flagship
- Works on a weak connection, and degrades gracefully without one
- Crash tracking after launch, so we find problems before your users tell you
Launch and support
- Store listings, screenshots and the approval process handled
- 60 days support
How we release it
Four stages from plan to store. A native app usually takes 8–16 weeks.
-
Plan
Screens, features and store requirements agreed in writing.
-
Build
In stages, with test versions on your own phone as it takes shape.
-
Test
On real mid-range phones and weak connections, not only a simulator.
-
Ship
Store listings, screenshots and approval handled; crash tracking on from day one.
Delivery models
We do not fit every project into one model. How a project is delivered depends on how settled the requirements are, how much certainty you need on cost, and how the product is expected to grow. After the consultation we recommend a model — or a combination, such as a prototype followed by incremental delivery — and name it in the written proposal.
-
Clarity of requirements
Fully defined, partly known, or still to be discovered with you.
-
Certainty of cost
One fixed price for the whole scope, or a fixed price per stage.
-
Pace of change
Whether the product is finished at launch or keeps evolving.
Prototyping Common for apps See and test a working prototype before development begins.
- Requirements
- Prototype
- Your feedback
- Refinement
- Development
A clickable prototype of the key screens is built first. You and your users test it, and it is refined until it is right. Only then does full development begin.
- Best suited to
- New products and unclear requirements — especially apps and customer-facing systems, where seeing the flow changes the brief.
- Pricing and approval
- The prototype is priced on its own. Development is priced once the prototype is approved.
Agile (Scrum) Common for apps Short sprints, with priorities reviewed with you every two weeks.
- Backlog
- Sprint planning
- Two-week sprint
- Review and demo
- Next sprint
Work is organised into a prioritised backlog and delivered in two-week sprints. Each sprint ends with a demonstration of working software and a review of what comes next, so the plan adapts as you learn.
- Best suited to
- Products whose requirements will evolve: mobile apps, customer platforms and systems that grow after launch.
- Pricing and approval
- Priced per sprint or per phase, agreed in writing, with priorities set by you.
Incremental Common for apps Delivered in usable parts, the most important first.
- Core release
- Increment 2
- Increment 3
- Further increments
The system is divided into increments. Each is designed, built, tested and handed over as working software, so your team uses the first part while the next is built.
- Best suited to
- Business software replacing several manual processes — for example, billing first, then inventory, then reporting.
- Pricing and approval
- A fixed price for each increment, agreed before that increment starts.
Iterative Waterfall Common for apps Waterfall with a review and correction point at every phase.
- Requirements
- Design
- Development
- Testing
- Launch
The same sequence as waterfall, but each phase ends with a formal review. Anything the review finds is corrected in that phase, or fed back to the previous one, before work moves on.
- Best suited to
- Defined projects where early approval matters — for example, a website whose design is signed off before development starts.
- Pricing and approval
- One fixed price. Corrections found at a review within the agreed scope are included.
Waterfall Sequential phases, one fixed scope and price.
- Requirements
- Design
- Development
- Testing
- Launch
Each phase is completed and approved before the next begins. The full scope is agreed at the start, so cost and timeline are known in advance.
- Best suited to
- Projects with clear, stable requirements: most business websites, landing pages and well-defined systems.
- Pricing and approval
- One fixed price for the whole scope, approved in the proposal.
V-Model Every build phase paired with a planned test phase.
- Requirements — acceptance tests
- System design — system tests
- Module design — integration tests
- Development — unit tests
Testing is planned alongside each phase of design, not left to the end. Each level of the build is verified against the matching level of requirements before handover.
- Best suited to
- Systems where accuracy is critical: billing, payments, financial records and anything audited.
- Pricing and approval
- One fixed price, with the test plan agreed as part of the scope.
Kanban A continuous flow of improvements after launch.
- Request
- Prioritised
- In progress
- Review
- Done
Requests are placed on a shared board, prioritised with you and worked through continuously, with a limit on work in progress so each item is finished properly.
- Best suited to
- Ongoing improvements, maintenance and support once a website, system or app is live.
- Pricing and approval
- Covered by a monthly care plan or an agreed monthly scope.
Not sure which applies to your project? That is what the consultation is for — the proposal states the model we recommend and why.
Common add-ons
Added when the product needs them, and included in the proposal.
- Admin dashboard
- Push notification campaigns
- Content management
- Sales and usage reports
- AI chat inside the app
- Payment integrations
- Delivery and order tracking
- Analytics
Engagement and pricing
Two apps that sound alike can require very different work behind them, so every app is priced individually. After the consultation you receive a written proposal with the scope, a fixed price and the timeline. Where a progressive web app meets the need, we propose that instead — at far lower cost.
What determines the price
- Number of screens and features
- Android, iPhone or both
- Whether it needs its own backend and admin dashboard
- Payments, logins and other integrations
App questions
Do I need an app or a website?
Most businesses need a website, not an app. A well-built mobile website or a progressive web app works on every phone, costs far less and needs no app-store approval. A native app makes sense when customers use it daily, or you need push notifications, offline use or in-app payments. We tell you which you need before you spend anything.
How much does an app cost in Nepal?
It depends on the number of screens and features, whether it is for Android, iPhone or both, and whether it needs its own backend and admin dashboard. Each app is priced individually in a written proposal after a consultation. A progressive web app costs far less, and for many businesses it does the same job.
How long does an app take?
A native app usually takes 8 to 16 weeks, depending on the features. A progressive web app usually ships in a few weeks.
Will it work on cheap phones?
Yes. We test on the mid-range Android phones your customers actually own, not just a flagship, and build it to keep working on a weak connection.
Can the app take eSewa and Khalti payments?
Yes, for physical goods and services such as food, bookings and deliveries. Digital content and subscriptions usually have to go through Apple's and Google's own billing; we set up whichever the store rules require.
Can the app be in Nepali?
Yes. The app can have a Nepali interface, an English one, or both with a switch. Tell us on the first call so it is part of the scope.
Which development model do you use for apps?
Most apps start with a clickable prototype, so you and your users can test the flow before development begins. The app is then built in agile two-week sprints, with a working demonstration at the end of each one. Where the scope is fully defined, an iterative waterfall model can be used instead. The proposal names the model.
Do you handle the Play Store and App Store?
Yes. We prepare the store listings and screenshots and take the app through the approval process. The developer accounts are registered in your name, and their fees are paid by you directly to Google and Apple.
Plan your app with our team
Tell us who will use it and what it must do. If a progressive web app meets the need, we will recommend it — before you commit to the larger investment.