TL;DR
- Custom software development follows 6 phases: Discovery → Requirements → Architecture → Build → Testing → Launch
- Discovery and architecture planning are non-negotiable: skipping them is the leading cause of cost overruns
- Agile sprint-based delivery means you see working software every 2 weeks, not just at the end
- A full project typically takes 3–9 months depending on scope; an MVP can be done in 8–12 weeks
- Post-launch support and iteration is as important as the initial build
Overview: The 6 Phases
Every custom software project at SpiderHunts follows the same six-phase process. The phases are sequential at a macro level but overlap in practice. Architecture work begins during requirements, and testing begins during build.
| Phase | Duration | Output |
|---|---|---|
| 1. Discovery | 1–2 weeks | Problem definition, user roles, success metrics, risk register |
| 2. Requirements | 1–3 weeks | User stories, data model, integration map, acceptance criteria |
| 3. Architecture | 1–2 weeks | Tech stack decision, system design, security model, infrastructure plan |
| 4. Build (Sprints) | 6–24 weeks | Working software, sprint demos, updated backlog |
| 5. Testing & QA | 2–4 weeks | UAT sign-off, bug-free staging environment, performance benchmarks |
| 6. Launch & Handover | 1–2 weeks | Production deployment, documentation, training, support plan |
Phase 1: Discovery
Discovery is the most underestimated phase. Many clients want to skip it and "just start building." That almost always results in expensive rework halfway through the project.
Discovery workshops surface the real problem, not just the symptom. A client who says "we need a reporting dashboard" often has a deeper underlying need. What they actually need is "we need our sales team to stop asking the finance team for weekly numbers." These lead to very different solutions.
What We Cover in Discovery
- Current state process mapping: how does the work actually get done today?
- Pain points and root causes: what is slowing people down or causing errors?
- User roles and permissions: who uses the system and what do they need to do?
- Success metrics: how will we know if the project succeeded in 6 months?
- Technical constraints: existing systems that must be integrated or replaced
- Compliance requirements: GDPR, ISO, industry-specific regulations
- Risk register: what could go wrong, and how do we mitigate it?
Phase 2: Requirements
Requirements translate the discovery findings into a buildable specification. We use user stories (as a [role], I want to [action], so that [outcome]) as the primary format. This keeps requirements grounded in user value rather than technical implementation.
Example User Stories
As a warehouse manager, I want to scan incoming stock barcodes, so that inventory levels update automatically without manual data entry.
As an operations director, I want a real-time dashboard showing fulfilment rates by SKU, so that I can identify bottlenecks before they delay orders.
As a customer, I want to track my order status via a branded portal, so that I don't need to call the support team.
Requirements also capture non-functional requirements:
- Response time targets (e.g., "all pages load in under 2 seconds")
- Uptime SLAs
- Concurrent user capacity
- Security requirements (encryption at rest, audit logging, RBAC)
Phase 3: Architecture and Tech Stack
Architecture decisions made here are the hardest to reverse later. The key decisions:
| Decision | Options | Key Consideration |
|---|---|---|
| Frontend framework | React, Next.js, Vue | SEO needs, team familiarity, SSR requirement |
| Backend language | Python, Node.js, Java | AI/ML integration, team, performance targets |
| Database | PostgreSQL, MongoDB, MySQL | Data structure, query complexity, compliance |
| Deployment model | AWS, Azure, GCP, on-premise | Data residency, cost, scale requirements |
| Auth model | Auth0, Cognito, custom JWT | SSO requirement, user volume, compliance |
Phase 4: Build: Agile Sprints
Development happens in 2-week sprints. Each sprint has a defined goal, a set of user stories, and ends with a demo of working software. You never wait months to see progress. You see it every two weeks.
Typical Sprint Structure
- Sprint planning (day 1): Team selects stories from the backlog, estimates effort, commits to sprint goal
- Daily standups: 15-minute sync on progress, blockers, and priorities
- Development: Features built, code reviewed, merged to staging branch
- Sprint demo (day 14): Working software demonstrated to stakeholders
- Retrospective: What went well, what to improve next sprint
Sprint reviews give you the opportunity to reprioritise the backlog. If a feature turns out to be less important than you thought, you can deprioritise it in favour of something more valuable. This is the fundamental advantage of agile over waterfall for custom software.
Environments We Maintain During Build
Development
Local developer machines: fast iteration, no approval needed
Staging
Shared environment for demos, UAT, and QA testing
Production
Live environment: only receives tested, approved code via CI/CD
Phase 5: Testing and QA
Testing isn't a phase that happens at the end. It runs throughout development. But before launch, there is a dedicated QA and UAT (user acceptance testing) phase.
| Test Type | Who Runs It | What It Covers |
|---|---|---|
| Unit tests | Developers | Individual functions: automated, run on every commit |
| Integration tests | Developers | API endpoints, database interactions, third-party integrations |
| End-to-end tests | QA engineer | Complete user journeys in a browser (Playwright/Cypress) |
| Performance testing | QA engineer | Load testing, response times under concurrent users |
| Security testing | QA + senior dev | OWASP Top 10 checks, auth bypass attempts, SQL injection |
| UAT | Client stakeholders | Real-world scenarios against acceptance criteria |
Phase 6: Launch and Handover
Launch is not a single event. It's a 1–2 week process that includes final deployment, data migration (if applicable) and staff training.
Launch Checklist
- Production infrastructure provisioned and hardened
- CI/CD pipeline tested end-to-end
- SSL certificates and domain configuration confirmed
- Database backups configured and tested
- Monitoring and alerting active (uptime, error rates, performance)
- Data migration scripts tested on staging with production data snapshot
- Staff training sessions completed
- Rollback plan documented and rehearsed
- Any post-launch support retainer agreed in writing (who to call if something breaks)
Handover Deliverables
You receive:
- Full source code in your own Git repository
- Architecture documentation
- Deployment runbook
- API documentation (auto-generated via OpenAPI)
Ongoing support, feature development, and SLA agreements can be arranged separately.
Common Causes of Cost and Time Overruns
| Cause | How to Prevent It |
|---|---|
| Scope creep: adding features mid-build | Use a formal change request process; new scope = new budget line |
| Vague requirements leaving room for interpretation | Invest in detailed discovery; use acceptance criteria for every story |
| Delayed client feedback on sprint demos | Commit a named stakeholder to review each sprint within 48 hours |
| Integration complexity not discovered until late | Map all third-party dependencies in requirements phase |
| Changing direction after architecture is locked | Front-load decision-making; major pivots cost 4–8 weeks minimum |
How Long Will Your Project Take?
Timeline depends almost entirely on scope and complexity. Here are reference ranges from our past projects:
8–12 weeks
MVP / Internal Tool
3–5 core features, one user role, one integration
3–5 months
Mid-Complexity Platform
Multiple user roles, 3–5 integrations, reporting
6–12 months
Enterprise System
Complex workflows, compliance, legacy integration, 5+ integrations