Custom Software Development Process: From Discovery to Launch
A step-by-step walkthrough of how custom software is actually built — from the first discovery workshop to production deployment and beyond.
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 actually needs "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 because they keep 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, and 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), staff training, and a period of hyper-care support.
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
- Hypercare support rota agreed (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), and a 30-day post-launch support period. 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
Frequently Asked Questions
How long does the custom software development process take?
A typical custom software project takes 3–9 months from discovery to launch. A focused MVP with 3–5 core features can be delivered in 8–12 weeks. Discovery and architecture planning alone take 2–4 weeks. Adding scope, compliance requirements, or third-party integrations extends timelines.
What happens during the discovery phase?
During discovery, your development partner runs structured workshops to map your business processes, identify the problem to solve, define user roles, agree on success metrics, and assess technical constraints. The output is a scope document, user stories, and a preliminary architecture recommendation.
What is the difference between agile and waterfall for custom software?
Waterfall defines all requirements upfront and builds in sequence — suitable when scope is extremely well-defined and unlikely to change. Agile delivers working software in 2-week sprints, incorporating feedback regularly — better for most custom software projects where some requirements emerge during build. Most reputable agencies use agile or a hybrid approach.
What should be included in a custom software requirements document?
A custom software requirements document should include: business context and goals, user roles and personas, functional requirements (user stories), non-functional requirements (performance, security, compliance), integration requirements, data models, and acceptance criteria for each feature.
Ready to Start Your Custom Software Project?
We run a free discovery session to scope your project, estimate costs, and identify risks — before you commit to anything.
Book a Free Discovery Session