Most business owners who decide to get custom software built have a clear picture of the problem they want solved. Stock is going missing between the warehouse and the shop. Orders are tracked across three WhatsApp groups and an Excel sheet. The sales team spends Friday afternoons copying figures into Tally. What is usually less clear is what happens between "we need a system for this" and "the system is live and people are using it".
That gap is where projects go well or go badly. A good development process is not paperwork for its own sake. It is a sequence of decisions, each one made at the right time, so that you are not paying to rebuild things later. This guide walks through each stage of a typical custom software project, whether it is an internal tool for a 20-person team in Jaipur or a platform for a distributor network, and what your own team needs to contribute.
Stage 1: Discovery and Requirement Gathering
Discovery is where the development team learns how your business actually works, not how the org chart says it works. This is the most underrated stage of the whole process, and skipping it is the single most common reason software ends up unused.
During discovery, expect your development partner to:
- Interview the people who will use the software daily, not just the owner or manager
- Sit with (or screen-share with) staff while they do the current process, including the workarounds
- Collect sample documents: invoices, purchase orders, challans, reports, Excel sheets
- Ask about existing systems such as Tally, Zoho, a payment gateway or a GST filing tool, and whether the new software must talk to them
- Identify who approves what, and what happens when something goes wrong
The output of discovery should be a written requirements document, sometimes called a scope document or SRS (software requirements specification). It does not need to be a hundred pages. It needs to be clear enough that you and the developer agree on what is being built and, just as importantly, what is not.
What you should contribute
Give the team access to the real people and the real data. If your accountant is the one who knows how credit notes are handled, they need an hour on the call. Owners often try to answer every question themselves to save staff time, and the software ends up reflecting how the owner thinks the work is done rather than how it is done.
Stage 2: Planning, Scope and Estimation
Once requirements are clear, the team breaks them into features, estimates effort, and proposes a plan. This is also where the first version is defined. Very few projects should build everything at once. A sensible plan separates the must-haves for launch from the features that can follow in a second or third phase.
A good plan should tell you:
- The list of features in the first release, in plain language
- The technology choices and the reasons for them (web app, mobile app, or both; hosting; database)
- Milestones with dates and what you will be able to see at each one
- Payment terms linked to those milestones
- Assumptions and exclusions, such as "data migration from the old system is not included"
The length of each stage scales with the size of the project. A small internal tool may have a discovery phase of a few days; a multi-user platform with integrations may need several weeks.
Fixed price or time-and-material?
Fixed-price contracts work when the scope is well understood and unlikely to change. Time-and-material (paying for hours or developer-months used) suits projects where you expect to learn and adjust as you go. Many Indian agencies offer a hybrid: a fixed price for a clearly defined first phase, then monthly billing for further work. Whichever model you choose, make sure the change-request process is written down.
Stage 3: UI/UX Design
Before any serious coding starts, the design team turns requirements into screens. This usually happens in two passes:
- Wireframes – rough, black-and-white layouts showing what goes where on each screen and how users move between them.
- Visual designs or clickable prototypes – the finished look, with your branding, which you can click through on a laptop or phone as if it were real.
This is the cheapest point in the whole project to change your mind. Moving a button on a prototype takes minutes. Moving it after the screen has been built, connected to a database and tested takes much longer.
Design for the people who will use the software daily. A warehouse supervisor on a mid-range Android phone needs large buttons and minimal typing; a finance team on desktops needs dense tables and filters.
Stage 4: Development
Development is the longest stage, and the one most people picture when they think of software projects. Modern teams generally work in short cycles, often called sprints, of one to two weeks. At the end of each cycle, a working piece of the software is shown to you.
Development usually covers several layers:
- Frontend – the screens users see and interact with, in a browser or mobile app
- Backend – the business logic, rules and calculations, such as how GST is computed on a mixed invoice or who gets notified when stock drops below a level
- Database – where your data is stored and how it is structured
- Integrations – connections to Tally, payment gateways like Razorpay, SMS and WhatsApp providers, e-invoicing portals, or AI services
- Admin and reporting – the dashboards and exports managers rely on
If you are building a browser-based system, our page on web app development explains the common approaches in more detail.
Your role during development
Attend the sprint demos; fifteen to thirty minutes every week or two is enough. Give feedback quickly and in one consolidated message. Projects slip most when the client goes quiet for weeks, then returns with a long list of changes.
Stage 5: Testing and Quality Assurance
Testing happens throughout development, but there is usually a dedicated phase before launch where the whole system is checked end to end. Testing typically includes:
- Functional testing – does each feature do what the requirements say?
- Integration testing – do the connections to Tally, payment gateways and other systems work with real-world data?
- Performance testing – does it stay fast when many people use it at once, or when reports cover a full financial year?
- Security testing – are logins, user permissions and data access properly controlled?
- Device and browser testing – does it work on the phones and browsers your team actually uses?
After internal testing comes User Acceptance Testing (UAT). This is where your own staff use the software with realistic data and confirm it works for them. Do not treat UAT as a formality. Assign specific people, give them specific scenarios to try (for example, "create a sales return for a partial shipment"), and ask them to log issues in one shared place.
Stage 6: Deployment and Launch
Deployment means moving the software onto live servers where your team and customers can use it. This stage involves more than pressing a button:
- Setting up hosting, domain, SSL certificates and backups
- Migrating existing data from spreadsheets or an older system
- Creating user accounts and setting permissions
- Publishing mobile apps to the Google Play Store and Apple App Store, if applicable (store review can add a few days)
- Training staff, usually through short live sessions and recorded videos
Many businesses choose a phased rollout: one branch or department goes live first, problems get fixed in a smaller group, and the wider rollout goes more smoothly. Avoid launching during Diwali season or March year-end closing.
Stage 7: Support, Maintenance and Improvement
Launch is not the end of the project. In the first few weeks, users will find small issues and ask for adjustments. Over the following months, you will think of features that would make the system more useful. Operating systems, browsers and third-party APIs also change, and the software needs updates to keep up.
Most agencies offer an annual maintenance contract (AMC) or a monthly support retainer. As a rough guide, annual maintenance for custom software in India is typically in the range of 15–25% of the original build cost per year, depending on how much change and support you need. Clarify what is included: bug fixes, minor changes, server monitoring, response times, and how new features are billed.
The Process at a Glance
| Stage | Main output | Your team's main contribution |
|---|---|---|
| Discovery | Requirements document | Access to users, sample data and current process |
| Planning | Scope, milestones, estimate | Agree priorities for the first release |
| Design | Wireframes and clickable prototype | Review screens with actual users |
| Development | Working software in increments | Attend demos, give timely feedback |
| Testing and UAT | Tested, approved system | Staff test real scenarios and sign off |
| Deployment | Live system, migrated data, trained users | Plan rollout, make staff available for training |
| Support | Fixes, updates, new features | Report issues, plan next improvements |
Common Mistakes to Avoid
- Skipping discovery to "save time". It almost always costs more time later.
- Trying to build everything in version one. Launch with the essentials, learn from real use, then expand.
- Having no single decision-maker. When five people give conflicting feedback, the developer cannot move forward.
- Leaving data migration to the last week. Cleaning years of inconsistent Excel data takes longer than most people expect.
- Not planning for training. Even well-designed software fails if staff are not shown how and why to use it.
- Not owning your code and data. Make sure the contract gives you ownership of the source code and access to your servers and database.
If you are still deciding whether custom software is the right route at all, our article on how custom software development helps businesses in India grow covers when it makes sense compared to off-the-shelf tools. You can also read more about custom business software for operations like inventory, billing and CRM.
FAQ
How involved do I need to be during the development process?
Most involvement is needed at the start (discovery and design) and the end (testing and launch). During development, a short weekly or fortnightly review is usually enough. Nominate one person from your side who can answer questions and make decisions within a day or two.
Can requirements change after development starts?
Yes, and some change is normal. A good partner will have a clear change-request process: the change is described, its effect on cost and timeline is estimated, and you approve it before work begins. Small adjustments are often absorbed; larger new features are usually moved to a later phase.
What is an MVP and should I start with one?
An MVP (minimum viable product) is the smallest version of the software that solves the core problem and can be used in real conditions. Starting with an MVP reduces upfront cost and risk, and lets you base later features on real feedback rather than guesses. For most SMEs, it is a sensible way to begin.
Will the new software work with Tally or our existing tools?
In most cases, yes. Tally, Zoho, common payment gateways, SMS and WhatsApp providers and many other tools offer ways to exchange data. Mention every system you use during discovery so the integration effort is included in the plan rather than discovered halfway through.
Who owns the software once it is built?
This depends entirely on your contract. You should insist on full ownership of the source code, documentation and data, plus admin access to hosting and any third-party accounts. Check this before signing, not after launch.
Getting Started
A clear process does not guarantee a perfect project, but it removes most of the surprises that make software late, over budget or unused. If you have a process in your business that you know could run better with the right system, we are happy to talk it through and help you work out a sensible first step. Learn more about our custom software development services, or contact us to start the conversation.
