# The Custom Software Development Process, Step by Step

> The custom software development process is the sequence of phases that turns a business problem into working, supported software: discovery, architecture and estimation, user experience design, iterative development, testing and security review, deployment, and ongoing support. For small businesses and nonprofits, short iterations with frequent demos keep scope, cost and risk visible throughout.

- URL: https://www.desaiinfo.net/software-development/custom-software-development-process
- Publisher: Desai InfoTech (https://www.desaiinfo.net)
- Last updated: 2026-10-17
- Topics: custom software development process, software development life cycle, software development phases, agile software development process, sdlc for small business


## Key takeaways

- Discovery is the cheapest place to remove risk; skipping it is the most common cause of budget overruns.
- Agree a minimum viable scope and success measures before choosing technology.
- Build in one- to two-week sprints with a working demo at the end of each one.
- Automated tests and a CI/CD pipeline belong in the first sprint, not the last.
- Plan for post-launch support and ownership from the start, including who holds the code.

Custom software succeeds or fails long before the first line of code. The process below is the one most small businesses and nonprofits can use whether the project is a simple integration or a customer portal. It is part of our broader [custom software development](https://www.desaiinfo.net/software-development) guidance.

## What are the phases of custom software development?

Custom software development has seven practical phases: discovery, architecture and estimation, UX design, iterative development, testing and security review, deployment, and support. Phases overlap in agile delivery, but each produces a distinct output that reduces risk.

| Phase | Main output | Typical duration |
|---|---|---|
| 1. Discovery | Problem statement, user stories, success measures | 1-3 weeks |
| 2. Architecture and estimate | Platform choice, data model, phased ranged estimate | 1-2 weeks |
| 3. UX design and prototyping | Validated wireframes and clickable prototype | 1-3 weeks |
| 4. Iterative development | Working, tested increments every sprint | 6-16 weeks |
| 5. Testing and security review | Acceptance sign-off, security findings resolved | 1-3 weeks |
| 6. Deployment and launch | Production release, monitoring, user onboarding | 1 week |
| 7. Support and iteration | Patches, fixes, enhancement roadmap | Ongoing |

## Why does discovery matter so much?

Discovery is where misunderstandings are cheapest to fix. A change that takes a conversation during discovery can take weeks once it is built, tested and deployed.

Good discovery answers four questions:

1. **What problem are we solving, and for whom?** Name the users and the job they are trying to get done.
2. **How is it done today?** Map the current workflow, including spreadsheets, emails and workarounds.
3. **How will we know it worked?** Define measures such as hours saved per week, errors avoided or online bookings completed.
4. **What are the constraints?** Budget range, deadlines, compliance requirements, existing systems and who will support the software afterward.

The output is a prioritized backlog of user stories ("As a volunteer coordinator, I want to see open shifts so I can fill gaps quickly") and a short list of risks to investigate.

## How are architecture and technology chosen?

Architecture is chosen to fit the requirements, the organization's existing platforms and the skills of whoever will maintain it. A Microsoft 365 organization will often favor Azure and Entra ID for single sign-on; a team already on AWS may prefer serverless services there.

Key decisions at this stage include:

- **Build, buy or integrate** for each capability. Identity, payments, email and search are almost always better bought as managed services.
- **Data model and system of record.** Decide which system owns each piece of data to avoid conflicting copies.
- **Hosting model.** Managed platform services, containers or serverless functions. Our [cloud-native application architecture](https://www.desaiinfo.net/software-development/cloud-native-application-architecture) guide covers the trade-offs.
- **Integration approach.** Document which APIs are consumed and exposed, following [API development best practices](https://www.desaiinfo.net/software-development/api-development-best-practices).

The estimate should be a range, not a single number, and should separate the MVP from later phases. See [software development cost estimation](https://www.desaiinfo.net/software-development/software-development-cost-estimation) for how ranges are built.

## What happens during UX design and prototyping?

UX (user experience) design turns user stories into screens and flows that real people test before development starts. Clickable prototypes in tools such as Figma let users try a workflow in minutes and expose confusing steps early.

For internal tools, a few rounds of feedback with three to five actual users is usually enough. For public-facing portals, accessibility should be part of the design brief from the start, aiming for WCAG (Web Content Accessibility Guidelines) conformance.

## How does iterative development work in practice?

Iterative development delivers working software in short, fixed-length sprints, typically one or two weeks. Each sprint takes the highest-priority stories from the backlog, builds and tests them, and ends with a demo to stakeholders.

A healthy sprint rhythm includes:

- **Sprint planning** to agree what will be delivered.
- **Daily coordination** within the delivery team.
- **Code review** on every change through pull requests.
- **Automated tests** that run on every commit.
- **A demo** of working software in a shared test environment.
- **Backlog refinement** so the next sprint is ready.

The CI/CD (continuous integration and continuous delivery) pipeline should exist from sprint one. It builds the code, runs tests and deploys to a test environment automatically. The practices in [CI/CD pipeline best practices](https://www.desaiinfo.net/devops-consulting/ci-cd-pipeline-best-practices) apply directly, and [DORA metrics](https://www.desaiinfo.net/devops-consulting/dora-metrics-guide) are a useful way to track delivery health.

## What testing is needed before launch?

Testing runs throughout development, but a final stage confirms the system is ready for real users and real data.

Pre-launch testing checklist:

- [ ] Automated unit and integration tests pass in the pipeline
- [ ] User acceptance testing completed and signed off by the product owner
- [ ] Performance tested at expected peak load plus headroom
- [ ] Security review: dependency scanning, secrets scanning, authentication and authorization checks
- [ ] Accessibility checks on public-facing pages
- [ ] Data migration rehearsed, if replacing an existing system
- [ ] Backups configured and a restore tested
- [ ] Monitoring, logging and alerting in place
- [ ] Rollback plan documented and rehearsed

Security deserves explicit attention. Building scanning into the pipeline, as described in our [DevSecOps guide](https://www.desaiinfo.net/devops-consulting/devsecops-guide), catches most common issues before they reach production.

## How should a launch be handled?

Launch should be a non-event technically, because the same pipeline has deployed to test environments dozens of times already. The real work is people: training, communication and support during the first days.

Consider a soft launch with a pilot group, feature flags to switch new functionality on gradually, and a clear channel for users to report problems. Keep the delivery team on standby for the first week.

## What happens after launch?

After launch, software needs monitoring, security patching and a path for improvements. Dependencies receive security updates constantly, and an unpatched application becomes a liability within months.

A typical support arrangement covers:

- Monitoring and alerting with agreed response times
- Monthly dependency and platform updates
- Bug fixes and small enhancements from a prioritized list
- A quarterly review of usage data and the product roadmap

Ownership matters here. The organization should hold the source code repository, cloud accounts and documentation so that support can move to another team if needed.

## How Desai InfoTech runs this process

Desai InfoTech follows this process at a scale that fits small teams: short discovery, a clear MVP, fortnightly demos and automated delivery from day one. If you are weighing whether to start small, our [MVP development guide](https://www.desaiinfo.net/software-development/mvp-development-guide) is a good next read, or [contact us](https://www.desaiinfo.net/contact) to talk through your project.

## How to run a custom software development project: steps

1. **Discovery:** Interview stakeholders, map the current process and define measurable outcomes and constraints.
2. **Architecture and estimate:** Choose the platform and data model, identify integrations and produce a phased, ranged estimate.
3. **UX design and prototyping:** Create wireframes and clickable prototypes and validate them with real users.
4. **Iterative development:** Build prioritized features in short sprints with code review, automated tests and demos.
5. **Testing and security review:** Run acceptance, performance and security testing in a production-like environment.
6. **Deployment and launch:** Release through a CI/CD pipeline with monitoring, a rollback plan and user onboarding.
7. **Support and iteration:** Monitor, patch and improve the application based on usage data and feedback.

## Frequently asked questions

### How long does a custom software project take?

A focused internal tool or MVP typically takes 8 to 14 weeks from discovery to first production release. Integrations between two or three systems are often 3 to 6 weeks, while multi-role portals with payments and several integrations commonly run 12 to 24 weeks. Duration depends heavily on scope clarity and how quickly decisions and feedback come back from the business.

### Is agile or waterfall better for small business software projects?

Most small projects benefit from an agile, iterative approach because requirements become clearer once people see working software. A light amount of up-front planning is still essential, including discovery, architecture and a ranged estimate. A fixed-scope, waterfall-style plan can suit very small, well-understood jobs such as a single integration with a clear specification.

### What does the client need to provide during development?

The most important contribution is a product owner with authority to make decisions, available for a few hours each week to answer questions, review demos and prioritize the backlog. The client also provides access to existing systems and test data, subject-matter experts for workflow questions, and a small group of real users for prototype and acceptance testing.

### What is the difference between the SDLC and agile?

The software development life cycle (SDLC) is the general set of activities every project performs, such as requirements, design, build, test, deploy and maintain. Agile is one way of organizing those activities, running them in short repeated cycles rather than one long sequence. An agile project still does every SDLC activity, just in smaller increments.


## Related

- [MVP Development Guide for Small Businesses and Startups](https://www.desaiinfo.net/software-development/mvp-development-guide)
- [How to Estimate Custom Software Development Cost](https://www.desaiinfo.net/software-development/software-development-cost-estimation)
- [Cloud-Native Application Architecture for Small Teams](https://www.desaiinfo.net/software-development/cloud-native-application-architecture)
- [CI/CD Pipeline Best Practices for Small Teams](https://www.desaiinfo.net/devops-consulting/ci-cd-pipeline-best-practices)
- [DORA Metrics Guide for Small Software Teams](https://www.desaiinfo.net/devops-consulting/dora-metrics-guide)