Last year, Priya, a founder building a HIPAA-compliant patient intake platform in Santa Monica, hired a development agency that told her they ran every project in Scrum. She didn’t know what Scrum was. She trusted the agency.
Nine months later, she’d spent $180,000, the product still wasn’t ready for a compliance audit, and half the features she’d approved in sprint demos didn’t match what regulators actually required. The problem wasn’t the team. The problem was the methodology. Healthcare compliance needs heavy upfront documentation, fixed requirements, and auditable sign-offs at each stage. Scrum gave her the opposite: loose scope, changing priorities, and working software that was moving faster than the paperwork behind it.
If she’d run the project in a Waterfall or V-Model approach, she’d have caught the compliance mismatches in week two, not month six.
Most non-technical founders and CTOs evaluating a custom software development partner don’t realize that the methodology choice matters as much as the vendor choice. Pick the wrong software development life cycle model and even a senior team will deliver the wrong thing on time.
This guide compares seven SDLC models, explains when each one fits, and gives you a decision framework to pick the right one before you sign a contract.
What Software Development Life Cycle Models Actually Are
A software development life cycle model is the structure a team uses to plan, build, test, and deliver software. It defines the phases (what happens when), the deliverables (what you see at each stage), and the feedback loops (when you can change direction).
Every project goes through roughly the same activities: discovery, design, development, testing, deployment, maintenance. The custom software development process covers these phases in detail. What changes between SDLC models is the order, the rigidity, and who controls the pace.
There’s no universally best model. There’s only the model that fits your project’s risk profile, regulatory environment, team maturity, and scope clarity. Below are the seven that matter.
Model 1: Waterfall
Waterfall is the original SDLC model. Each phase finishes completely before the next one starts. Requirements first, then design, then development, then testing, then deployment. You don’t go backward.
How it works in practice: Months one and two are requirements gathering and documentation. Months three and four are design. Months five through eight are development. Month nine is testing. Month ten is deployment. Everything is planned upfront. Scope changes after month two are painful and expensive.
Best for:
- Projects with fixed, legally binding requirements (government contracts, medical devices, aerospace)
- Regulated industries where every deliverable needs audit trails
- Projects where the cost of changing direction mid-build exceeds the cost of over-planning
Drawbacks:
- Unforgiving if requirements were wrong or incomplete at the start
- You don’t see working software until late in the project
- Change requests require contract renegotiation and usually a new budget
Typical timeline: 6-18 months, depending on scope.
Waterfall gets a bad reputation because people apply it to projects where requirements genuinely can’t be known upfront. That’s operator error, not a flaw in the model. When requirements are stable and compliance matters more than speed, Waterfall still wins.
Model 2: Agile
Agile isn’t a single process. It’s a set of principles codified in the Agile Manifesto in 2001. The core idea: instead of planning everything upfront, you build small, show it to the client, get feedback, and adjust.
The Project Management Institute’s overview of agile goes deeper, but the practical version is this: Agile projects work in short cycles (usually two weeks), deliver working software at the end of each cycle, and replan priorities based on what was learned.
How it works in practice: Week one the team builds version 0.1 of a login flow. Week two you look at it and say the validation messages are wrong. Week three they fix it and also ship a dashboard prototype. You see real software constantly. Direction changes constantly. Nobody knows exactly what the product will look like in six months.
Best for:
- Products where requirements will evolve as you learn (most consumer and B2B products)
- Startups and MVPs where validation is the goal, not specification matching
- Teams with high trust and strong communication
Drawbacks:
- Hard to give a fixed price upfront because scope evolves
- Requires significant client involvement (bi-weekly reviews minimum)
- Can drift if nobody enforces scope discipline
Typical timeline: Ongoing, but most projects target 3-6 months to initial launch.
Agile is popular because it fits most modern software work, especially for software development for startups where speed to market is everything. It’s not universally right, though. Healthcare, aerospace, and any project with a hard regulatory ceiling need more structure than raw Agile provides.
Model 3: Scrum
Scrum is the most common Agile framework. It adds specific roles, meetings, and artifacts to the Agile principles.
The core pieces of Scrum:
- Sprints: fixed two-week work cycles
- Product backlog: prioritized list of features waiting to be built
- Sprint backlog: the subset of features selected for the current sprint
- Daily standups: 15-minute team sync meetings
- Sprint review: demo of completed work at the end of each sprint
- Sprint retrospective: team meeting to improve the next sprint
Roles: Product Owner (defines priorities, represents the client), Scrum Master (removes blockers, enforces the process), Development Team (builds the software).
Best for:
- Product teams building long-running software with regular releases
- Organizations with an engaged Product Owner who can make fast decisions
- Projects where priorities shift often and the team needs a structured way to replan
Drawbacks:
- Overhead: the ceremonies (standups, planning, review, retro) consume 10-15% of team time
- Requires a trained Scrum Master or the process devolves into “sprint-shaped chaos”
- Doesn’t fit projects with fixed deadlines and fixed scope
Typical timeline: Usually ongoing. Initial product delivery in 3-6 months, then continuous iteration.
Scrum works well for most [SaaS development]/services/) projects and internal product teams. It works poorly for one-off client projects where the client expects a finished product on a fixed date.
Model 4: Kanban
Kanban is Agile without the sprints. Work flows continuously through a board with columns like “Backlog,” “In Progress,” “Review,” and “Done.” Team members pull new work when they finish what they were on.
How it works in practice: There’s a shared board (usually in a tool like Linear, Jira, or Trello). Each card represents a task. Work-in-progress limits keep the team from starting five things and finishing none. Priorities get re-sorted constantly. There are no fixed sprints.
Best for:
- Support and maintenance work where priorities change daily
- Teams handling a mix of planned features and reactive bug fixes
- Smaller teams or single developers working on well-defined backlogs
Drawbacks:
- Harder to forecast delivery dates because there are no time-boxed cycles
- Requires strong product management to keep priorities clear
- Can lead to drift if nobody reviews progress on a regular cadence
Typical timeline: Ongoing. No fixed delivery window.
Scrum vs Kanban, in one sentence: Scrum batches work into two-week commitments. Kanban flows work continuously and replans constantly. Scrum fits product development with regular releases. Kanban fits ops teams, maintenance, and support work.
Model 5: Spiral
The Spiral model combines Waterfall and Agile. Each “spiral” is a small loop: plan, build, test, evaluate risks, then decide whether to proceed, pivot, or stop. The project grows through repeated spirals until it’s complete.
How it works in practice: Spiral one might be a prototype of the riskiest technical component. If it works, spiral two adds core functionality. If the risk analysis flags a problem, the team might spend spiral three rebuilding infrastructure before continuing.
Best for:
- Large, high-risk projects where early technical decisions could sink the whole effort
- Research and development work with unknown technical feasibility
- Projects where risk management needs to be as explicit as feature delivery
Drawbacks:
- Expensive: each spiral adds overhead for risk analysis and review
- Requires senior technical leadership that can accurately assess risk at each stage
- Hard to apply to small projects where the overhead exceeds the benefit
Typical timeline: 12-36 months for projects big enough to justify it.
Spiral isn’t something you’ll ask for by name. But if you’re building a complex fintech or defense system and your vendor proposes “iterative delivery with risk gates,” that’s Spiral in practice.
Model 6: V-Model
The V-Model is Waterfall with a parallel testing track. For every design and development phase on the left side of the V, there’s a corresponding testing phase on the right side. Requirements get matched with acceptance testing. Architecture gets matched with system testing. Module design gets matched with unit testing.
How it works in practice: You don’t wait until the end to test. Testing plans get written at the same time as the specs they’ll validate. If a requirement can’t be tested, that’s a red flag in week two, not month nine. The IEEE Computer Society’s publications on software engineering standards cover the test-driven rigor that makes V-Model work in regulated environments.
Best for:
- Safety-critical software: medical devices, automotive, aviation, industrial controls
- Projects requiring formal validation documentation (FDA, FAA, ISO 26262)
- Contracts where testing coverage is a legal deliverable
Drawbacks:
- All the rigidity of Waterfall plus more documentation
- Expensive: testing artifacts often equal or exceed the code in volume
- Not suited to exploratory work or changing requirements
Typical timeline: 12-24 months for projects big enough to need it.
V-Model isn’t overkill for safety-critical work. It’s the minimum. If you’re building software that could kill someone when it fails, you want V-Model or something even stricter.
Model 7: DevOps
DevOps isn’t a pure SDLC model. It’s an operational philosophy that wraps around Agile, Scrum, or Kanban. The core idea: development and operations are the same team, and software ships to production many times per day through automated pipelines.
How it works in practice: Every code change triggers automated testing. If tests pass, the code deploys to production automatically. Monitoring watches for issues in real time. When something breaks, the developer who wrote the code fixes it, not a separate ops team.
Best for:
- SaaS products with continuous delivery needs
- Products where rapid iteration on live users is a competitive advantage
- Teams that have already mastered Agile and need to compress release cycles
Drawbacks:
- Requires significant infrastructure investment (CI/CD pipelines, monitoring, feature flags)
- Not appropriate for software that can’t be updated live (embedded systems, regulated releases)
- Team needs both development and ops skills, which raises hiring costs
Typical timeline: 2-3 months to set up the pipelines, then continuous delivery from there.
DevOps layered on top of Scrum is how most modern SaaS companies operate. It’s not a replacement for the underlying SDLC model, though. You still need to pick Waterfall, Agile, Scrum, or Spiral as the baseline.
SDLC Models Compared Side-by-Side
Here’s how the seven models compare across the factors that matter most when you’re choosing:
| Model | Best For | Drawbacks | Typical Timeline | Scope Flexibility |
|---|---|---|---|---|
| Waterfall | Fixed-requirement, regulated projects | Brittle if requirements change | 6-18 months | Very low |
| Agile | Evolving products, MVPs, startups | Hard to fix-price; needs client involvement | 3-6 months per release | Very high |
| Scrum | Product teams with regular releases | Ceremonies add overhead; needs trained Scrum Master | Ongoing, 3-6 mo to v1 | High |
| Kanban | Support, maintenance, reactive work | Harder to forecast dates | Ongoing | High |
| Spiral | Large, high-risk, complex systems | Expensive; needs senior technical leads | 12-36 months | Medium |
| V-Model | Safety-critical, safety-regulated software | Heavy documentation burden | 12-24 months | Very low |
| DevOps | SaaS with continuous delivery | Infrastructure overhead; mixed skill requirement | Continuous | N/A (layers on top) |
Agile vs Waterfall: The Decision Most Projects Actually Face
Most projects aren’t choosing between all seven. They’re choosing between Agile (or one of its flavors) and Waterfall. Here’s how to think about it.
Pick Waterfall if any of these are true:
- Requirements are fixed by contract, regulation, or external dependency
- Compliance audits require sequential sign-offs
- Scope changes after week four would blow the budget
- The client can’t or won’t be involved every two weeks
Pick Agile (or Scrum) if any of these are true:
- You’re building a product for users who will give feedback as you learn
- Requirements will evolve as you validate with real usage
- The client is committed to bi-weekly reviews
- You’d rather learn fast and change direction than specify perfectly upfront
There’s a middle ground people miss: you can run discovery in a Waterfall-like way (detailed requirements, formal sign-off) and then run development in Agile. That hybrid works for most MVP development projects where the scope needs rigorous definition but the build needs flexibility.
Scrum vs Kanban: Choosing Between Agile Flavors
If you’ve picked Agile, the next choice is Scrum vs Kanban. The difference comes down to predictability versus flow.
Pick Scrum if:
- You need predictable release cadence (every two weeks, every month)
- Your team benefits from structured ceremonies and roles
- The work can be reasonably planned a sprint at a time
- Stakeholders want regular, scheduled demos
Pick Kanban if:
- Work is unpredictable (bug fixes, support tickets, reactive requests)
- Planning a sprint in advance doesn’t match reality
- The team is small (1-3 people) and ceremonies feel heavy
- Continuous flow matters more than time-boxed commitments
Many mature teams run a hybrid: Scrum for feature development, Kanban for support and bug fixes. The product engineers are on a two-week sprint cadence; the ops team works a Kanban board.
Decision Tree: Pick Your SDLC Model in Five Questions
Answer these in order. The first “yes” points you to a model.
1. Is the software safety-critical (could cause death or serious harm if it fails)? Yes → V-Model. Don’t negotiate this.
2. Are the requirements locked by contract, regulation, or external dependency that can’t change? Yes → Waterfall. Build the scope document carefully, then execute.
3. Is the project large ($500k+), novel, and technically risky? Yes → Spiral. You need explicit risk gates between phases.
4. Is this a product that will have regular releases and evolve with user feedback? Yes → Scrum (with DevOps if you want continuous delivery). Budget for the ceremonies.
5. Is this reactive work, support, maintenance, or fast-changing priorities? Yes → Kanban. Skip the sprints.
If none of the above: You probably want a hybrid. Waterfall for discovery to lock the scope, Agile or Scrum for the build. This is what most custom software projects look like in practice.
The Methodology Trap Most Founders Fall Into
Vendors love to advertise their methodology. “We’re an Agile shop.” “We do pure Scrum.” “We run DevOps.” This sounds sophisticated. It’s usually a mistake to take it at face value.
A methodology is a tool. The question isn’t “does the vendor use Scrum?” but “is Scrum the right tool for my project?” A good development partner picks the methodology to fit your project. A mediocre one runs every project the same way regardless of fit.
When you’re evaluating a software development company, ask them directly: “Which SDLC model do you think fits this project and why?” If the answer is “we always use Scrum” without a why, keep shopping. If they explain the trade-offs and match the model to your constraints, that’s a partner worth considering.
The same logic applies to the build vs. hire decision. Freelancers usually work in Kanban or ad-hoc modes. Agencies default to Scrum. In-house teams can adopt any model. The freelancer vs agency vs in-house comparison covers which fits which situations.
When Methodology Doesn’t Actually Matter
Here’s a truth most methodology consultants won’t tell you: for projects under $50,000 with a single developer or a two-person team, the methodology choice is mostly irrelevant. At that scale, communication happens in real time, scope is already tight, and ceremonies add more overhead than value.
What matters at that scale is clear scope, weekly check-ins, and working software every two weeks. Call it whatever you want. If you’re building an MVP with a tight team, don’t spend more time choosing a methodology than choosing what to build.
Methodology starts to matter at around $100k and 3+ people. Below that, just talk every week and ship every two. Understanding custom software development cost helps you judge whether a project is big enough to warrant formal methodology selection.
How LCGC Approaches SDLC Selection
We don’t run every project the same way. For a fixed-scope custom software build, we’ll usually run a Waterfall-style discovery (detailed requirements, formal scope sign-off) followed by Scrum or Kanban development. For an MVP where validation is the goal, we’ll skip heavy upfront documentation and run Kanban with weekly client reviews. For regulated work, we’ll pull elements of V-Model into the test plan from day one.
The SDLC model gets picked based on your project, not our preference. That choice happens during discovery, before we sign a build contract, so you know exactly how the work will run before you commit.
Making the Call
The best SDLC model is the one that fits your constraints, not the one your vendor likes. Waterfall for rigid requirements. Agile for evolving products. Scrum for product teams with regular releases. Kanban for reactive work. Spiral for large, risky systems. V-Model for safety-critical software. DevOps layered on top when you need continuous delivery.
If you’re not sure which fits your project, that’s normal. The right conversation happens with a development partner who will walk through your constraints and recommend a model before quoting a price.
Want a second opinion on which SDLC model fits your project? Learn about our team, browse our full service list, or book a free 30-minute consultation. Bring your requirements, your timeline, and your budget. We’ll tell you which methodology fits and why, even if the answer is “you don’t need us for this.”