Software Development Lifecycle (SDLC) sounds like something enterprise consultants sell you. It conjures images of Gantt charts, requirement documents, and approval meetings.
But SDLC, at its core, is just a answer to one question: how do you go from idea to running software without breaking everything?
The enterprise version
The traditional SDLC has phases:
- Planning — gather requirements, estimate effort, create timeline
- Analysis — understand the problem domain, document constraints
- Design — architect the solution, create technical specifications
- Implementation — write the code
- Testing — verify it works
- Deployment — ship it
- Maintenance — fix bugs, add features
This is fine for teams of 50 shipping banking software. For a solo developer building a portfolio site, it’s overhead that slows you down.
The solo developer version
My SDLC has four phases:
1. Think (5 minutes)
Before writing any code, I answer three questions:
- What problem does this solve?
- What does “done” look like?
- What’s the simplest version that works?
If I can’t answer these, I’m not ready to code. I’m ready to think more.
2. Build (hours to days)
I build the simplest version that works. No abstractions, no patterns, no “we might need this later.” Just working software.
I commit early and often. Each commit should leave the project in a working state. If I’m experimenting, I use a branch. If I’m confident, I commit to main.
3. Verify (minutes)
After building, I verify:
- Does it work? (manual testing)
- Does it build? (
pnpm build) - Does it lint? (
pnpm lint) - Does it deploy? (push and watch)
If any of these fail, I fix before moving on. Technical debt is fine. Broken builds are not.
4. Ship (minutes)
I deploy. Not when it’s perfect — when it works. Imperfect software that ships teaches you more than perfect software that doesn’t.
Then I move to the next thing.
The rhythm
The key insight is that SDLC isn’t a one-time process — it’s a rhythm. Think → Build → Verify → Ship. Repeat.
Some cycles take 30 minutes (a typo fix). Some take 3 weeks (a new feature). The phases are the same. The rhythm keeps you productive without getting bogged down in process.
What I actually do
Here’s my real workflow for a typical feature:
Monday morning: Think. What does the user need? What’s the simplest version? Write it down (usually in a markdown file or a GitHub issue).
Monday-Thursday: Build. Code, commit, test locally. I don’t write tests first (controversial, I know) — I write tests after the feature works, for the parts that are likely to break.
Friday morning: Verify. Full build, lint, manual testing. Fix anything that’s broken.
Friday afternoon: Ship. Deploy, monitor for a day, fix any issues that come up.
Monday: Start the next cycle.
The tools that help
- Git — version control is non-negotiable. Even for solo projects.
- Linting — catches errors before they reach production. Set it up once, benefit forever.
- CI/CD — even a simple GitHub Actions pipeline saves time and catches mistakes.
- Error tracking — Sentry or similar. You can’t fix what you can’t see.
- Monitoring — uptime checks and basic metrics. Know when things break before your users do.
What I skip
- Requirements documents — for solo projects, the requirements are in my head
- Design documents — I design in code, not in documents
- Code reviews — no one to review (but I do review my own PRs before merging)
- Staging environments — I deploy to production and fix quickly if something breaks
- Formal testing — I test manually and add automated tests for critical paths
These aren’t bad practices. They’re just not worth the overhead for my scale. If I were building software for a bank, I’d do all of them.
The lesson
SDLC isn’t about process — it’s about rhythm. Find a rhythm that works for your scale, your team, and your projects. The enterprise version exists for good reasons. But for solo developers and small teams, the best SDLC is the one you actually follow.
Think → Build → Verify → Ship. Repeat.