Every piece of software that has ever been deployed -- from a simple mobile app to a mission-critical election system -- followed some version of the Software Development Life Cycle. The SDLC is not a specific methodology. It is a framework that describes the phases every software project passes through, regardless of whether the team follows waterfall, agile, or something in between. Understanding these phases, and the different approaches to sequencing them, is fundamental to delivering software that works, on time, and within budget. At Pepla, we have refined our SDLC approach across hundreds of projects over more than a decade, and the principles that follow reflect what we have learned.
Phase 1: Planning
Planning is where a project goes from "we need software" to "here is what we are going to build, why, and how." It is the most strategic phase, and skipping or rushing it is the most expensive mistake a project can make.
During planning, the team defines the project's objectives, scope, timeline, and budget at a high level. They identify stakeholders, assess feasibility, and establish governance -- who makes decisions, how changes are approved, how progress is reported. The output is typically a project charter or business case that secures funding and organisational commitment.
Effective planning also includes a preliminary risk assessment. What are the biggest unknowns? Where is the technical risk highest? What dependencies exist on external parties? Identifying these early allows the team to build mitigation strategies into the plan rather than reacting to surprises later.
At Pepla, we start every engagement with a discovery phase that overlaps with planning. We meet with stakeholders, understand the business context, assess the existing technology landscape, and produce a high-level roadmap before any development begins. This investment typically represents 5-10% of the total project effort and saves multiples of that in avoided rework.
Phase 2: Requirements
Requirements define what the software must do. This phase transforms business objectives into specific, documented, testable requirements that the development team can implement.
Requirements come in two categories. Functional requirements describe what the system does: "The system shall allow users to reset their password via email." Non-functional requirements describe how the system behaves: "Password reset emails shall be delivered within 30 seconds, and the reset link shall expire after 24 hours."
The requirements phase involves elicitation (gathering requirements from stakeholders through interviews, workshops, observation, and document analysis), analysis (resolving conflicts, identifying gaps, and prioritising), specification (documenting requirements in a structured, unambiguous format), and validation (confirming with stakeholders that the documented requirements match their intent).
The quality of requirements directly determines the quality of the final product. Studies consistently show that defects originating in the requirements phase cost 50 to 200 times more to fix after deployment than if caught during the requirements phase itself. This is why Pepla's business analysts invest significant effort in getting requirements right -- it is the highest-leverage activity in the entire lifecycle.
Seven phases are universal: planning, requirements, design, development, testing, deployment, and maintenance. How you sequence them is the methodology choice.
Requirements defects cost 50-200x more to fix after deployment. The SDLC exists to catch problems when they are cheapest to solve.
Phase 3: Design
Design translates requirements into a technical blueprint. It operates at multiple levels: high-level design defines the system architecture -- components, their responsibilities, and how they communicate. Detailed design specifies the internal structure of each component -- data models, algorithms, interface contracts, and error handling strategies.
Key design decisions include technology stack selection, database design, API architecture, security architecture, integration patterns, and deployment topology. These decisions are documented in architecture decision records and design documents that serve as references throughout development.
The design phase also includes UX design for user-facing applications. Wireframes, prototypes, and user flows define how users will interact with the system. At Pepla, design and development teams collaborate during this phase to ensure that designs are technically feasible and that developers understand the reasoning behind design decisions.
A common pitfall is over-designing -- spending weeks perfecting a design before writing any code. The appropriate level of design detail depends on the project's complexity and risk. A straightforward web application needs less upfront design than a distributed payment processing system. The goal is enough design to guide development confidently, not a perfect blueprint that anticipates every detail.
Phase 4: Development
Development is where the design becomes working software. This is the phase most people think of when they think of software development -- writing code, building features, implementing business logic.
Effective development practices include version control (every line of code tracked in Git), coding standards (consistent style and patterns across the codebase), code review (every change reviewed by at least one other developer before merging), and continuous integration (automated builds and tests running on every commit).
Development is rarely a solo activity. Modern software is built by teams, and coordination within and between teams is essential. Daily standups, sprint planning, and regular design discussions keep everyone aligned. Pair programming and mob programming accelerate knowledge sharing and catch issues early.
At Pepla, our development teams -- the Orange, Green, and Blue teams -- each have a team lead who ensures code quality, manages technical decisions within the team, and coordinates with the solutions architect on cross-cutting concerns. This structure scales to handle multiple concurrent projects without losing quality.
Maintenance accounts for 60-80% of total software cost. Design decisions made during development determine how expensive that maintenance will be.
Phase 5: Testing
Testing verifies that the software works correctly and meets its requirements. It operates at multiple levels: unit testing verifies individual functions and methods, integration testing verifies that components work together, system testing verifies the complete application end-to-end, and user acceptance testing (UAT) verifies that the software meets the user's needs in their context.
Testing is not just about finding bugs. It is about building confidence. Each level of testing provides a different kind of confidence: unit tests confirm that the building blocks are sound, integration tests confirm that the plumbing works, system tests confirm that the features function correctly, and UAT confirms that the software solves the business problem it was built for.
Modern testing practice emphasises automation. Automated tests run on every code change, providing immediate feedback to developers. Manual testing is reserved for exploratory testing (where human intuition finds issues that scripted tests miss) and scenarios that are impractical to automate.
Phase 6: Deployment
Deployment moves the software from the development environment to production where users can access it. This phase includes environment preparation, data migration, deployment execution, smoke testing, and go-live support.
Modern deployment practices aim to make deployment routine rather than risky. Continuous delivery pipelines automate the deployment process so that deploying to production is a single button press (or fully automated). Blue-green deployments maintain two production environments, allowing instant rollback if issues are discovered. Feature flags enable deploying code to production without exposing it to users until it is ready.
At Pepla, we treat deployment as an engineering problem, not an event. Every project has a documented deployment process, automated where possible, with clear rollback procedures. The goal is for deployments to be boring -- routine, predictable, and unremarkable.
Phase 7: Maintenance
Maintenance begins the moment the software reaches production and continues for the remainder of its operational life -- which is typically years or decades. It includes bug fixes, security patches, performance tuning, feature enhancements, and infrastructure updates.
Maintenance is often underestimated in project planning. Industry research suggests that maintenance accounts for 60-80% of the total cost of ownership for a software system. Design decisions made during development -- code quality, documentation, test coverage, architectural modularity -- directly impact how expensive maintenance will be.
Pepla provides ongoing maintenance and support for the systems we build, because we understand that software is never "done." The technology landscape evolves, business needs change, user expectations increase, and security threats emerge. A system that is not actively maintained is a system that is gradually becoming a liability.
Approaches to the SDLC
The seven phases above are universal, but the way teams sequence and iterate through them varies significantly across methodologies.
Waterfall
The waterfall approach executes phases sequentially: each phase is completed before the next begins. Requirements are fully specified before design starts, design is complete before development begins, and all development is finished before testing starts. Waterfall provides clear milestones and predictable timelines, making it suitable for projects with well-understood, stable requirements -- regulatory systems, hardware-software integration, and projects with fixed-scope contracts.
The weakness of waterfall is that feedback comes late. If a requirement was misunderstood, the team may not discover it until testing or even deployment. By then, fixing it is expensive.
Iterative
The iterative approach divides the project into cycles, each producing a working version of the software with increasing functionality. Each iteration includes mini-versions of all phases (requirements, design, development, testing). This provides earlier feedback and allows the team to incorporate learning from each iteration into subsequent ones.
Spiral
The spiral model, proposed by Barry Boehm, adds explicit risk analysis to the iterative approach. Each cycle through the spiral includes planning, risk analysis, engineering, and evaluation. It is particularly suited to large, complex, high-risk projects where the cost of failure is significant. The emphasis on risk analysis ensures that the team addresses the biggest uncertainties early.
Agile
Agile approaches (Scrum, Kanban, XP) take iteration to its logical extreme, with cycles typically lasting one to four weeks. Each sprint delivers a potentially shippable increment of software. Requirements are continuously refined, design emerges incrementally, and testing is integrated into every sprint. Agile provides maximum flexibility and fastest feedback, making it ideal for projects where requirements evolve, innovation is important, or time-to-market is critical.
The choice of SDLC approach is not a religious decision. It is an engineering decision based on the project's characteristics: requirement stability, risk profile, team size, stakeholder availability, and contractual constraints.
The choice of SDLC approach is an engineering decision, not a religious one. Base it on requirement stability, risk profile, and team size.
How Pepla Implements the SDLC
At Pepla, we do not prescribe a single SDLC approach for all projects. We assess each project's characteristics and select the approach that best fits.
For most of our projects, we use an agile approach with strong upfront discovery. We invest two to four weeks in planning and requirements before sprints begin, ensuring the team has sufficient context to make good decisions during development. We run two-week sprints with all standard ceremonies (planning, daily standups, reviews, retrospectives). We maintain a continuous delivery pipeline that enables deployment to staging after every sprint and to production on client approval.
For projects with regulatory requirements or fixed-scope contracts, we incorporate more structure: detailed requirements documentation, formal design reviews, comprehensive test plans, and staged deployment with sign-off gates. The agile cadence continues within this structure -- we deliver in sprints but organise those sprints within a more predictable overall timeline.
For maintenance and enhancement work, we use Kanban -- a continuous flow model where work items are pulled from a prioritised backlog as capacity becomes available. This avoids the overhead of sprint ceremonies for work that is inherently unpredictable in volume and urgency.
Pepla follows this lifecycle on every project we deliver. From requirements gathering through to production monitoring, our teams own every phase -- and our weekly client check-ins ensure nothing falls through the cracks.
The common thread across all approaches is our commitment to the fundamentals: clear requirements, thoughtful design, disciplined development practices, comprehensive testing, and reliable deployment. The SDLC phases exist in every project. The approach determines how we traverse them.
