On this page
TL;DR: Custom software development follows 7 phases — Discovery, Requirements, Architecture, Development, QA, Deployment, and Maintenance — with realistic total timelines ranging from 3 months (MVP) to 18+ months (enterprise platform). 97% of software organisations now use Agile to some degree (Digital.ai State of Agile 2026), delivering in 2-week sprints rather than one long build. The single biggest timeline killer is not technical complexity — it is unclear requirements that cause developers to stop and wait, and changing priorities mid-sprint that destroy throughput. Both are planning problems, not engineering problems.
What Is the Custom Software Development Process?
The custom software development process is the structured sequence of activities an engineering team follows to design, build, test, and deliver software built specifically for one organisation’s workflows — as opposed to configuring an off-the-shelf product.
What distinguishes a well-run process from a poorly-run one is not the phases — every team has roughly the same phases. It is the quality of decisions made at each gate, the clarity of what “done” means at each phase, and how the team handles the inevitable divergence between original assumptions and production reality.
In 2026, Agile delivery has become the near-universal standard: 97% of software organisations use some form of Agile (Digital.ai State of Agile 2026). Projects using Agile methods have a 75% success rate versus significantly lower rates for pure waterfall approaches (State of Agile 2026). Agile delivers working software in 2-week increments, making problems visible early when they are cheap to fix rather than late when they are expensive.
“What distinguishes successful Agile delivery is not the ceremony — it is decision quality. Daily standups and sprint reviews only add value when senior engineers are actively evaluating tradeoffs, surfacing risks, and adjusting course based on real system behaviour.”
— Keyhole Software, Enterprise Development Best Practices, 2026
The 7 Phases of Custom Software Development
Phase 1: Discovery and Planning (2–4 Weeks)
Discovery establishes the project foundation by aligning stakeholders on what is being built, why, and for whom — before any architecture decisions are made. The goal is not a perfect specification; it is a shared understanding precise enough to make good architecture decisions and scope estimates.
Key activities:
- Stakeholder interviews to document business objectives, success metrics, and constraints
- Technical assessment of existing systems, integration dependencies, and legacy formats
- Risk analysis with probability/impact scoring and documented mitigation strategies
- Budget planning with a realistic 5-year total cost of ownership projection
Deliverables: Project roadmap, high-level requirements document, risk register, initial cost estimate with assumptions stated
What slows this phase: Competing stakeholder priorities that require trade-off decisions, hidden integration dependencies with legacy systems, regulatory requirements (HIPAA, SOX, GDPR) discovered late rather than upfront.
The cost of skipping discovery: Requirements that are unclear at kickoff get re-scoped mid-project at a premium — typically adding 15–30% to the original estimate in scope changes. Discovery is the cheapest phase; mid-build re-scoping is the most expensive.
Phase 2: Requirements Analysis (3–6 Weeks)
Requirements analysis translates business objectives into specific, testable specifications. A well-run requirements phase produces user stories, acceptance criteria, and integration specifications that developers can act on without constant clarification.
Key activities:
- User story mapping with prioritised acceptance criteria per story
- Functional specification for each business workflow
- Integration specification for each external system connection (API contracts, data formats)
- Non-functional requirements: performance targets, security requirements, compliance constraints
Deliverables: Detailed user stories, functional specifications, acceptance criteria, integration specs
What slows projects more than anything else: Vague requirements. Developers who stop and wait for answers — while mid-sprint — are the single largest controllable cause of timeline extension. A developer waiting for a requirements clarification burns a full sprint day. Multiply by five engineers and a three-week ambiguity period and the math is blunt.
The test for a well-defined requirement: A developer can write a failing test for it before writing any implementation code. If that is not possible, the requirement is not ready.
Phase 3: Architecture and System Design (2–5 Weeks)
Architecture decisions made in this phase affect every team member, every deployment, and every debugging session for the life of the system. This is the most expensive phase to revisit later.
Key activities:
- System architecture selection: see Software Architecture Patterns for the full decision framework
- API contract definition between components and external systems
- Database schema design and data model
- Security model: authentication, authorisation, encryption at rest and in transit
- Infrastructure-as-code plan: cloud provider, compute, storage, networking
Deliverables: Architecture diagrams, API contracts, database schemas, security model, infrastructure plan
At InApps: Architecture decisions are written down and signed off before any sprint begins. The document includes the options considered, the trade-offs evaluated, and the assumptions that would change the decision. When assumptions change during the build, the document changes first. No undocumented architecture decisions.
What slows this phase: Scope that is not yet clear enough to make architecture decisions with confidence. The solution is not to skip architecture — it is to return to Phase 2 until clarity is sufficient. Architecture designed against vague scope produces the wrong structure for the eventual requirements.
Phase 4: Agile Development (8–24+ Weeks)
Development runs in 2-week sprints, each producing a working, tested increment of software. The sprint cadence provides a regular forcing function for stakeholder feedback, problem visibility, and course correction.
Sprint structure:
- Sprint planning: Team commits to a scope of work from the prioritised backlog, sized to fit two weeks
- Daily standup: 15-minute coordination on progress and blockers — not a status report, a blocker clearance
- Development: Feature implementation, code review, automated testing, CI/CD pipeline validation
- Sprint review: Working software demonstrated to stakeholders — real, running software, not slides
- Sprint retrospective: Process improvement, not blame — what slowed the sprint, what would speed the next one
Development timelines by complexity (Keyhole Software 2026 benchmarks):
| Complexity | Duration | Sprints | Characteristics |
|---|---|---|---|
| Simple | 8–12 weeks | 4–6 | Single database, 3–5 API endpoints, 1–2 integrations, basic auth |
| Moderate | 12–20 weeks | 6–10 | Multiple systems, 10–20 endpoints, 5–8 integrations, real-time sync |
| Complex / Enterprise | 20–30+ weeks | 10–15+ | Distributed architecture, 30+ endpoints, 10+ integrations, compliance |
Code review as an architectural checkpoint: In the InApps process, code review is not a style check. Senior engineers use it to catch architectural drift, prevent technical debt from accumulating sprint-over-sprint, and mentor through the review. Enterprise shortcuts that look acceptable in a single sprint frequently reappear as stability or compliance issues six months later.
The biggest throughput killer in development: Changing priorities mid-sprint. A developer context-switching from one feature to an urgent new priority mid-sprint loses one to two days of productive time in the transition alone. Sprint commitments protect throughput — the product owner’s job is to prioritise before the sprint, not during it.
Phase 5: Quality Assurance (Continuous, Throughout Development)
QA in a well-run process is not a phase that happens after development. It runs continuously alongside development, with automated tests running on every commit and blocking merge on failure.
Testing layers:
- Unit tests: Individual functions and components behave as designed. Written by developers, run in CI on every commit
- Integration tests: Components and external systems communicate correctly — API contracts, authentication, error handling
- Performance tests: The system handles realistic load under expected operating conditions — before go-live, not after
- Security tests: OWASP Top 10 checks against staging; SAST and dependency scanning in the CI pipeline
- User acceptance testing (UAT): Named users complete priority tasks using realistic data — the system solves the original problem
What prevents quality from being treated as an afterthought: Automated test gates in the CI/CD pipeline that cannot be bypassed. If a merge fails tests, it does not merge. This is not optional — it is infrastructure.
The cost of defects by phase: Research consistently finds that defects discovered in production cost 5–10x more to fix than defects discovered during development. Automated test coverage that catches defects in the sprint they are introduced is the highest-ROI quality investment available.
Phase 6: Deployment and Production Transition (1–3 Weeks)
Deployment strategy determines how much operational risk the organisation carries at go-live. The choice depends on the system’s criticality, user base size, and tolerance for downtime.
| Approach | Method | Best for | Risk |
|---|---|---|---|
| Phased rollout | Pilot group (50–100 users) → departments → full release | Large user bases (500+), customer-facing systems | Low — blast radius limited to pilot group |
| Parallel operation | Old and new systems run simultaneously (30–90 days), data reconciled daily | Mission-critical: financial, healthcare | Low — full fallback available; doubles operational overhead |
| Blue-green deployment | Two identical production environments; traffic switched after validation | Cloud-native, containerised applications | Zero downtime; requires duplicate infrastructure |
| Cutover | Maintenance window; data migrated; switch at defined time | Clear boundaries, minimal integrations, planned downtime acceptable | High — rollback is complex once users have created data |
At InApps: No production deployment without a written runbook, a documented rollback procedure, and a named rollback authority with a defined decision window. The runbook specifies each action owner, approval requirement, and next trigger. Rollback decisions cannot wait for an unavailable committee.
What slows deployment: Infrastructure surprises (production environment behaves differently from staging) and last-minute scope additions. Both are preventable with staging environments that accurately mirror production and a strict feature freeze period before go-live.
Phase 7: Maintenance, Support, and Continuous Evolution (Ongoing)
Deployment is not the end of the development process — it is the end of the first delivery phase. Most of a system’s life happens after launch. The team that builds it should maintain it.
Maintenance budget allocation (Keyhole Software 2026):
| Maintenance type | % of maintenance budget | Examples |
|---|---|---|
| Perfective (new features) | 60–70% | User-requested features, UX improvements, new integrations |
| Adaptive (platform updates) | 15–20% | Framework upgrades, API version migrations, regulatory changes |
| Corrective (bug fixes) | 10–15% | Production defects, data corrections, system recovery |
| Preventive (tech debt) | 5–10% | Code refactoring, dependency updates, documentation |
Annual maintenance cost: Plan for 15–20% of initial development cost per year. A $200,000 system costs $30,000–$40,000/year to maintain. Organisations that omit this from their total cost of ownership projections consistently face budget surprises in year two.
At InApps: The team that built the system is the team that maintains it. No handoff to a maintenance vendor who was never in the codebase. Application Maintenance & Support →
What Actually Slows Software Projects Down
These seven factors account for the majority of timeline extensions. Each is preventable.
| Factor | Impact | Prevention |
|---|---|---|
| Vague requirements | Developers stop and wait; rework when direction changes | Discovery phase + testable acceptance criteria before sprint begins |
| Changing priorities mid-sprint | 1–2 days of context-switch cost per developer per change | Sprint commitment respected by product owner; new priorities enter next sprint |
| Undiscovered integration complexity | Weeks of unplanned work when an API does not behave as documented | Integration spec and API contract validation during requirements phase |
| Insufficient access to stakeholders | Decisions delayed; wrong assumptions baked in | Named stakeholder available for sprint review and async questions within 24 hours |
| Technical debt accumulation | Increasing cost of every subsequent change | 20% of each sprint allocated to tech debt; no corner-cutting on test coverage |
| Poor data quality in migration | Data errors discovered in UAT or production | Data profiling and cleansing as a separate workstream in Phase 1–2 |
| Production environment differences | Staging passes; production fails | Staging mirrors production exactly; infrastructure-as-code applied to both |
Source: ZTabs software timeline analysis, Keyhole Software enterprise benchmarks, InApps engineering practice
Timeline Summary: Realistic Expectations by Project Type
| Project type | Discovery | Build | Deployment | Total |
|---|---|---|---|---|
| MVP (core features only) | 2 weeks | 8–12 weeks | 1 week | 3–4 months |
| Internal business tool | 3 weeks | 12–16 weeks | 1–2 weeks | 4–5 months |
| SaaS platform (mid-complexity) | 4 weeks | 16–24 weeks | 2 weeks | 5–8 months |
| Enterprise / compliance platform | 4–6 weeks | 24–36 weeks | 2–3 weeks | 8–12+ months |
Assumes 3–5 dedicated senior engineers. A single developer takes 2–3x longer; a team of 10 is not twice as fast as a team of 5 due to coordination overhead.
How InApps Runs the Custom Software Development Process
InApps runs the same 7-phase process outlined above, with three structural commitments that distinguish it from a generic delivery shop:
1. Architecture before sprint, in writing. No sprint begins without a signed-off architecture document. The document includes trade-offs considered and the assumptions that would change the decision. Architectural drift is caught in code review, not in production incidents.
2. The same team builds and maintains. The engineers who write the code in sprint one are the engineers who debug it in month 18. No handoff to a maintenance vendor who is reading the codebase for the first time when something breaks.
3. One interface, direct access. Clients talk directly to the engineers building their product — not through a project manager, not through account management. Standups, code review, architecture discussions: direct. This is how engineering decisions get made in days rather than weeks.
Two engagement models for the custom development process:
Custom Software Development → — your product roadmap, your architecture decisions, InApps engineers on a monthly rate. Best for: ongoing product development with an evolving roadmap.
Software Product Development → — fixed scope, fixed price, InApps carries delivery risk. Best for: a defined build with stable requirements where budget certainty matters more than scope flexibility.
Frequently Asked Questions
What is the custom software development process?
The custom software development process is the structured sequence of activities used to design, build, test, and deliver software built specifically for one organisation’s workflows. The 7 standard phases are: Discovery and Planning, Requirements Analysis, Architecture Design, Agile Development (in 2-week sprints), Quality Assurance (continuous), Deployment, and Maintenance. In 2026, 97% of software organisations use Agile delivery within this structure.
How long does custom software development take?
Timelines range from 3–4 months for a focused MVP to 12+ months for a complex enterprise platform. A mid-complexity business application with several integrations typically takes 5–8 months. The single biggest cause of timeline extension is unclear requirements — developers who stop mid-sprint waiting for answers burn days of throughput per person. Teams of 3–5 dedicated senior engineers deliver faster than larger teams due to lower coordination overhead.
What are the phases of custom software development?
7 phases: (1) Discovery and Planning (2–4 weeks) — business objectives, risk register, cost estimate. (2) Requirements Analysis (3–6 weeks) — user stories, acceptance criteria, integration specs. (3) Architecture Design (2–5 weeks) — system architecture, API contracts, database schema. (4) Agile Development (8–24+ weeks) — 2-week sprints delivering working software increments. (5) QA (continuous) — automated tests on every commit, UAT before launch. (6) Deployment (1–3 weeks) — phased or parallel rollout with documented rollback. (7) Maintenance (ongoing) — 15–20% of initial dev cost per year.
What is Agile development and why does custom software use it?
Agile development builds software in short, repeatable 2-week cycles called sprints. Each sprint delivers a working, tested increment — making problems visible early when they are cheap to fix, and allowing requirements to evolve with market and user feedback. 97% of software organisations use Agile in 2026 (Digital.ai); Agile projects have a 75% success rate versus significantly lower rates for waterfall. Agile does not eliminate planning — it enables controlled adaptation when original assumptions meet reality.
What should I look for in a custom software development partner?
Five questions that separate strong partners from transactional vendors: (1) Will the same engineers who build it maintain it? (2) Are architecture decisions written down before any sprint begins? (3) Can I talk directly to the engineers building my product? (4) What is the process when requirements change mid-build? (5) How do you handle a sprint where the delivery falls short? Ask for specific answers, not principles. Get the architecture governance process in writing before signing.
What is the biggest mistake companies make in custom software development?
Two tie for first: (1) Starting development before requirements are clear enough to write testable acceptance criteria — this produces rework and schedule extensions that are always more expensive than the discovery time they were trying to avoid. (2) Treating QA as a final phase rather than a continuous process throughout development — defects caught in production cost 5–10x more to fix than defects caught in the sprint they were introduced.
Key Takeaways
- 7 phases: Discovery → Requirements → Architecture → Development (Agile sprints) → QA (continuous) → Deployment → Maintenance.
- 97% of software organisations use Agile (Digital.ai 2026); Agile projects have 75% success rate.
- Realistic timelines: MVP 3–4 months; mid-complexity 5–8 months; enterprise 8–12+ months. Single developers take 2–3x longer; large teams are not proportionally faster.
- Annual maintenance = 15–20% of initial development cost. Plan it in year-one TCO.
- The biggest timeline killers: vague requirements, mid-sprint priority changes, undiscovered integration complexity. All are planning problems, not engineering problems.
- Code review is an architectural checkpoint, not a style review. It is where technical debt is caught before it compounds.
- Architecture decisions in writing, before any sprint. The most expensive decisions to revisit are the ones made implicitly.
Work with us
Need a team that can do this on your codebase?
Tell us what you are shipping and we will send back a scope, a team shape and a fee. No obligation.
Book a free call