Making software can be hard. It will most likely be long. The fact that every software is different and tailored for different needs makes every case unique, and uniquely difficult. But there are ways to deal with it: the approaches to development that determine the workflow and the way of achieving the end result.

Despite the fact that the process itself may vary, they have a lot in common. In most cases, they share the Software Development Life Cycle (SDLC), a general idea about how software gets done. This is a framework that can hold different specific approaches. In this article, we want to show you that combining SDLC with Lean Software Development may just be one of the best ways to go.

What is the Software Development Life Cycle?

SDLC as a concept was created to lower the cost of software development while shortening the time needed to get it done. It’s not the only way to perceive the development process, but it’s widely accepted in the dev community as something that works. It’s there so the teams don’t have to reinvent the wheel every time they start working on new software. Coincidentally, the graph explaining the Software Development Life Cycle resembles a wheel.

As the name suggests, SDLC is a cycle, which means that it repeats. There are six stages, and this fact can be utilized by your team in different ways, depending on the methodology that you adopt. If it’s Agile, each sprint will consist of these phases, rinse and repeat in short cycles, while in Waterfall, you finish a phase completely before moving to the next one. There’s also the approach unique to Lean Software Development, but before we get there, let’s take a closer look at the cycle itself.

The phases of SDLC

1. Planning

This is where you plan not only your software, but also the place it’s going to take in the market. Why do you need it and what’s the desired perception of your product? How will it answer the needs of the users? Who are your users, what do they expect, and what are their pain points? And while we’re at it, what are your pain points that can hamper progress? It’s the stage when you think not only about your software, but also about its business function, and about the way your team is going to realize it.

2. Designing

Having determined all of the above, you can plan out the big picture, meaning roadmap and architecture. What deadlines do you want to need? What are your priorities? What will be the milestones, and what kind of technology stack are you going to use? 

3. Development

This part is quite self-explanatory. You have set the deadlines, now you have to meet them. This is also where your approach can get more customized, and where the methodology kicks in. Note that you don’t have to 100% complete the development to move on to the next stage, which is…

4. Testing

Time to see how the software you’re making measures up to expectations. It’s good to have a QA team to get a professional and unbiased analysis.

5. Deployment

That’s the part that can be misunderstood the most. Deployment doesn’t mean a release of the complete product. It means delivering parts of it, preferably building up from the MVP, adding new functionalities or improvements. This lets you maintain a feedback loop and save time you’d otherwise waste on delivering unnecessary or secondary features. 

Once this stage is complete and feedback is taken, it’s back to phase one. The difference is, you don’t start from scratch–only re-evaluate and keep building. 

SDLC vs Lean Software Development (LSD)

We’ve established the phases, now time to clash them with the strategy of Lean Software Development. This approach also has its well-defined stages. However, it’s all based on seven key principles.

  • Don’t bother with anything that doesn’t add value to your product.
  • Quality is key, and this means quality as perceived by your customer, not in your subjective view.
  • Defer your commitment. Test things as long as you can before you decide which way to go.
  • Create knowledge by learning from a constant feedback loop.
  • Aim at fast delivery: implement small changes often, and always get feedback.
  • Optimize the big picture. Don’t obsess over details when there are matters more pressing in the context of the full feature.
  • Respect your team.

The stages of LSD

1. Feasibility check

We could pretty much copy-paste the first stage of SDLC as the basic idea is the same. You need to set the goals and requirements of your project. The reason behind it is to make sure you’re doing something worthwhile, and in a way that’s going to resonate with the target user. It’s not uncommon to hire an expert to help plan out the process in the case of less experienced software houses, or when the product scope is unusually large.

2. Proof of concept

This means checking if your idea is going to work at all. After all, you can’t theorize your way to success. There isn’t a single correct form your proof should take. It can be as simple as a mock-up or a white paper. The goal is to make something that showcases your idea and is comprehensible to your target users, so you can ask them for their opinion. Their feedback will let you make course corrections before the development even begins, which saves time, money, effort, and nerves.

3. Making a prototype

In other words, creating something that actually works. The most basic version of your software you can launch. It doesn’t have to have every feature you ultimately want, but it should already show why your product will be worthwhile. You could say this is to create enough hype to validate the development that will follow. 

Note that a prototype isn’t an MVP. This isn’t a releasable version. This is the bare-bones, basic version that showcases your value, created to get feedback from the client who commissioned this project and also from the target users.

4. Minimum Viable Product

The MVP will stem from the prototype, but it’ll probably be significantly different. After all, you will implement all the changes inspired by the feedback you got from the previous stages. At this point, your software should be good enough to be usable, and actually sellable. As the name suggests, it will have all the basic functionalities, and additional features will come with updates. 

It’s quite possible that the MVP will be different from what you had initially designed at the earliest of stages, but that’s fine. It’s exactly why you put so much effort into validating the feasibility of your concept.

5. The Full Thing

From MVP, your goal is to reach the final version of your product, with all the features you want. This is the real moneymaker, the product that will get its audience. 

However, as you know, in today’s world, products don’t just get made. They continue to get made. You need to keep updating the software, improving it or introducing new elements, to keep your user base and attract new customers.


So what does comparing the two acronyms tell us?

First of all, the Software Development Life Cycle is the most general idea of how you can, or should, develop software in an efficient manner. It’s not a detailed plan–it’s a set of principles that’ll guide you through the most crucial phases.

On the other hand, Lean Software Development is an approach that adds detail to the structure of your process. The best thing about it is that you can expand and adopt other principles, for example of the Agile methodology. It’s always good to have this wiggle room, because software is made by people, and every team should have a place for personality.

Good luck with your projects! See our other articles, or, if you’re looking for a software house, check out what we do at

If you liked what you read, consider contacting us at – meet us, tell us about your needs, and we’ll think together about a possible course of action. This won’t cost you a dime and might open up some nice new possibilities. Stay in touch!