Every agency, freelancer, and dev shop on the planet will tell you they have a "proven process." They'll throw around terms like Agile, Scrum, Lean, Design Thinking — and most of the time those words mean absolutely nothing in practice. The developers still wing it. Requirements still change every week. And the final product still arrives late, over budget, and half-broken.
After building 100+ software products over 12+ years as CEO of Lasting Dynamics — across industries like fintech, healthtech, defense, real estate, government, and luxury — I stopped trying to be "Agile-certified" and started doing what actually works. Our process isn't pure Agile and it isn't Waterfall. It's a field-tested hybrid that borrows from both, discards what doesn't work, and adds hard-won lessons from projects that ranged from $10K MVPs to multi-million-dollar enterprise platforms.
In this article, I'm going to walk you through every single phase of how we build software — from the first conversation to post-launch iteration. No buzzwords. No vague promises. Just the actual steps, the actual timelines, and the actual costs. Whether you're a founder scoping your first MVP, a CEO evaluating agencies, or a product manager looking for a better way to ship — this is the playbook.
And if you want to understand how much your specific product might cost, read my companion piece where I break down real numbers and ranges.
Phase 0: Discovery & Strategy (2 Weeks)
This is the phase that separates serious teams from code factories. Before we write a single line of code — before we even open a design tool — we spend two focused weeks understanding the problem we're actually solving. Not the problem you think you have. The real one.
During Phase 0, we work directly with you (the founder, CEO, or product owner) to map out four critical dimensions:
- Business context: What's the business model? Who pays? How do you make money? What are your constraints (budget, timeline, regulatory)?
- Market & competitors: Who else is doing something similar? What's your differentiation? Where are the gaps you can exploit?
- Users: Who are the primary users? What are their pain points? What does success look like for them — not for you, for them?
- Technical landscape: Are there existing systems to integrate with? Data to migrate? Compliance requirements (GDPR, HIPAA, SOC 2)?
The output of Phase 0 is a Product Brief — a concise, actionable document that includes: validated user personas, a prioritized feature list using the MoSCoW method (Must have, Should have, Could have, Won't have), a high-level architecture sketch, and a preliminary technology recommendation. If you're curious about how we choose the right stack, I've written a complete guide to tech stack selection.
Phase 0 typically costs between $3,000 and $8,000 depending on complexity. I know what you're thinking: "Why would I pay $5K before development even starts?" Because this phase regularly saves our clients $50,000 or more. It kills bad ideas early. It prevents scope creep. It aligns the entire team before a single euro is spent on development.
Michele's Take
Here's the red flag I want you to watch out for: if an agency is willing to start coding in week one without a discovery phase, walk away. It means they don't care about building the right thing — they care about billing hours. We've inherited dozens of projects from teams that skipped discovery. Every single one cost more to fix than it would have cost to do properly from the start. Every. Single. One.
At the end of Phase 0, you have total clarity. You know what you're building, why you're building it, roughly how long it will take, and what it will cost. And here's the best part: Phase 0 is standalone. If you decide not to move forward with us, you still own the Product Brief. You can take it to any other team. Zero lock-in.
Phase 1: Design & Prototyping (2–3 Weeks)
With the Product Brief in hand, our design team gets to work. But we don't jump straight to pretty mockups — that's a mistake I see junior designers make constantly. Good design follows a deliberate sequence:
The Design Sequence
- UX Research: We map user flows — the exact paths a user takes to accomplish their goals. Where do they start? What decisions do they make? Where might they get confused or drop off?
- Wireframes: Low-fidelity layouts that establish information hierarchy, navigation, and interaction patterns. No colors, no fancy fonts — just structure.
- UI Design: High-fidelity visual design built on top of the validated wireframes. This is where brand identity, typography, color systems, and visual polish come in.
- Clickable Prototype: A fully interactive prototype in Figma that looks and feels like the real product. You can click through it, navigate screens, and experience the product before a single line of code is written.
Here's the step most teams skip — and it's the one that matters most: we test the prototype with real users before development begins. Using tools like Maze, we run moderated and unmoderated usability tests with people who match your target audience. We watch where they get confused, where they hesitate, where they try to click something that doesn't exist.
This testing phase catches 80% of UX problems before they become $20K development mistakes. Changing a wireframe takes 20 minutes. Changing a fully built feature takes 2 weeks and $15K.
The deliverables from Phase 1 are:
- Design System: A reusable component library (buttons, forms, cards, modals) that ensures consistency and accelerates development.
- Validated Prototype: Tested with real users, with documented feedback and iterations applied.
- Technical Specification: A detailed document that translates the design into development requirements — API endpoints, data models, state management, third-party integrations.
When Phase 1 is done, there are zero surprises left. The client knows exactly what the product will look like. The developers know exactly what they need to build. And the estimates we gave in Phase 0 are now refined to within 10-15% accuracy.
Phase 2: Development — Sprint-Based (8–16 Weeks)
Now we build. This is where the hybrid nature of our process becomes clear. We use 2-week sprint cycles — borrowed from Scrum — but without the dogmatic ceremony overhead that makes pure Scrum feel like a bureaucratic exercise. Each sprint follows a disciplined rhythm:
The Sprint Cycle
| Day | Activity | Who's Involved |
|---|---|---|
| Day 1 | Sprint Planning — select stories from backlog, estimate, commit | Dev team + Product Owner |
| Days 2–9 | Development — coding, code review, unit testing | Dev team |
| Day 10 | Internal QA — testing on staging environment | QA team + Dev team |
| Day 10 (afternoon) | Sprint Demo — live walkthrough of completed features | Everyone + Client |
| End of sprint | Retrospective — what worked, what didn't, what we improve | Dev team + PM |
Communication: No Black Boxes
One of the biggest complaints I hear from founders who've worked with other agencies is: "I had no idea what was happening for weeks at a time." That doesn't happen with us. Here's how we keep you in the loop:
- Daily async standup: Every morning, the team posts a brief update in Slack — what they did yesterday, what they're doing today, any blockers. You can read it or ignore it.
- Weekly sync call: A 30-minute video call where we discuss progress, flag risks, and align on priorities for the next week. Camera on, screen sharing, real conversation.
- Board access: You have full read access to our project board (Linear or Jira). Every task, every status, every comment — fully transparent.
- Sprint demo every 2 weeks: You see the actual product running on a staging server. Not slides. Not screenshots. The real thing.
Engineering Standards: Non-Negotiable
This is where we're strict and unapologetic about it:
- Code review on every pull request. No exceptions. Every line of code is reviewed by at least one other senior developer before it's merged. This catches bugs, enforces consistency, and spreads knowledge across the team.
- CI/CD from day one. We set up continuous integration and continuous deployment pipelines in the first sprint. Every merge to the main branch triggers automated tests and deploys to a staging environment. You always have a working version to look at.
- Git branching strategy. We use trunk-based development with feature branches. Clean history, easy rollbacks, no merge nightmares.
- Documentation. API docs, architecture decision records, runbooks. If our team got hit by a bus, another competent team could pick up the codebase and keep going.
If you're a non-technical founder wondering whether you need a technical co-founder to manage all this — the answer is no. But you do need a team that operates with this level of discipline. That's what you're paying for.
Phase 3: QA & Testing (Continuous)
I need to address a misconception that persists in this industry: testing is not a phase. It's not something you do "at the end" after the developers are "done." Testing is integrated into every single sprint from the very first one. Here's our testing pyramid:
Automated Testing
- Unit tests: Individual functions and components tested in isolation. These run in seconds and give instant feedback. We target 70-80% code coverage on business logic.
- Integration tests: Groups of components tested together — API endpoints, database queries, service interactions. These verify that the pieces work together, not just individually.
- End-to-end (E2E) tests: Full user journeys automated with tools like Playwright or Cypress. These simulate a real user clicking through the application. We cover every critical path: signup, login, core workflows, payment flows.
Manual QA
Automated tests catch regressions and logic errors. But they don't catch bad UX, visual glitches, or edge cases that only a human eye spots. Our QA specialists perform exploratory testing on every feature — testing on different browsers, screen sizes, and devices. They try to break things. They use the product the way a confused, impatient, real-world user would.
Bug Triage System
When bugs are found (and they will be — that's the whole point of testing), they're triaged immediately:
| Severity | Definition | Response Time | Example |
|---|---|---|---|
| Critical (P0) | System down or data loss | Fix within 4 hours | Payment processing fails, user data deleted |
| Major (P1) | Core feature broken, no workaround | Fix within 24 hours | Users can't complete signup, dashboard won't load |
| Minor (P2) | Feature impaired but workaround exists | Fix in next sprint | Filter doesn't reset, export misses one column |
| Cosmetic (P3) | Visual or text issue | Backlog, fix when convenient | Typo in footer, 1px alignment issue |
This system means you never have to wonder "is this bug being taken seriously?" Every issue has a clear severity, a clear owner, and a clear SLA.
Phase 4: Launch & Post-Launch
Launch day is not "deploy and pray." It's a choreographed event with a detailed checklist that we've refined over hundreds of launches. Here's what our launch readiness checklist covers:
- Performance: Load testing completed. Core Web Vitals in green. Time to first byte under 200ms. Lighthouse score above 90.
- Security: OWASP Top 10 reviewed. SSL configured. Authentication hardened. Rate limiting in place. Dependencies scanned for vulnerabilities.
- Monitoring: Error tracking (Sentry), uptime monitoring (Better Uptime), performance monitoring (Vercel Analytics or Datadog), and log aggregation — all configured and tested.
- Backup & recovery: Database backup automated. Recovery procedure documented and tested. Rollback plan in place if deployment fails.
- SEO & analytics: Meta tags, sitemap, robots.txt, structured data. Google Analytics / Plausible configured. Conversion tracking set up.
Soft Launch vs. Hard Launch
We almost always recommend a soft launch first — releasing to a small group of beta users (10-50 people) for 1-2 weeks before the public launch. This catches real-world issues that no amount of staging testing will find: unexpected user behavior, performance bottlenecks at scale, confusing onboarding flows.
A hard launch (public release with marketing push) comes after the soft launch feedback has been incorporated. The only exception is when there's a hard external deadline — a conference, a funding milestone, a regulatory date. Even then, we plan for a rapid iteration cycle in the first two weeks post-launch.
“The launch isn't the end. It's the beginning. Everything you built was based on assumptions. Now you find out which assumptions were wrong — and that's where the real product development starts.”
— Michele Cimmino · CEO, Lasting Dynamics
Post-launch, we shift into monitoring and rapid response mode. We watch error rates, performance metrics, user behavior analytics, and support tickets like hawks. Hotfixes ship within hours. Non-critical improvements get queued for the next sprint. Every decision is now driven by real user data, not assumptions.
Phase 5: Scale & Iterate
The MVP is live. Users are coming in. Now what? This is where many teams lose their way. They either freeze the product and stop iterating (death by stagnation) or they try to build everything at once (death by over-engineering). The answer is disciplined iteration.
From MVP to V1 to Mature Product
We think about product evolution in clear stages:
- MVP (Month 0-3): Core value proposition. One user type, one workflow, one market. The goal is to validate that people want this thing. Read my detailed breakdown of MVP costs and scope.
- V1 (Month 3-9): Based on real user feedback, expand the feature set. Add the "Should have" features from the MoSCoW list. Harden security, improve performance, add integrations that users are asking for.
- Mature Product (Month 9+): Now you're optimizing, not exploring. A/B testing, conversion optimization, advanced analytics, enterprise features, API for third-party integrations.
Scaling the Team
When and how to scale the team is a decision we help our clients think through carefully. Adding developers too early creates coordination overhead that slows you down. Adding them too late creates burnout and missed deadlines. The general pattern we follow:
- MVP phase: 2-3 developers, 1 designer, 1 PM/QA. Keep it small and fast.
- V1 phase: 4-6 developers, 1-2 designers, dedicated QA, PM. Feature teams can start forming.
- Scale phase: Multiple feature squads, platform team, DevOps/SRE, dedicated design team. This is when hiring your own team starts to make financial sense.
Throughout this entire phase, we focus on analytics-driven development. Every feature decision is backed by data — user behavior analytics, funnel analysis, cohort retention, NPS scores. We stop guessing and start measuring. Strategic refactoring happens alongside new features — we continuously improve code quality, reduce technical debt, and optimize performance so the product gets better as it grows, not worse.
Realistic Timelines and Budgets
I'm going to give you the table that I wish someone had shown me when I started building products. These numbers are based on our actual project history — not aspirational marketing numbers, but what things actually cost and how long they actually take when done properly.
| Product Type | Discovery + Design | Development | Total Timeline | Total Budget Range |
|---|---|---|---|---|
| Landing Page / Validation MVP | 1 week | 1–2 weeks | 2–3 weeks | $5K – $15K |
| Simple SaaS / Web App | 3–4 weeks | 8–12 weeks | 3–4 months | $30K – $80K |
| Complex SaaS / Multi-tenant Platform | 4–5 weeks | 12–20 weeks | 4–6 months | $80K – $200K |
| Mobile App (Cross-platform) | 3–4 weeks | 10–16 weeks | 3–5 months | $50K – $150K |
| Marketplace / Two-sided Platform | 4–6 weeks | 16–24 weeks | 5–8 months | $100K – $250K+ |
| Enterprise System / Custom ERP | 6–8 weeks | 24–40 weeks | 8–12 months | $200K – $500K+ |
A Warning About Unrealistic Promises
If someone promises you a complex, multi-feature product in 4 weeks for $20K, they are either lying, incompetent, or planning to deliver something held together with duct tape. I've seen it hundreds of times. The initial quote looks great. Then come the change orders, the "unexpected complexities," the delays. By the end, you've paid 2-3x the original quote and you still don't have a product you're proud of. Realistic expectations upfront save you a fortune in the long run.
These timelines assume a competent, dedicated team working on your project — not a team split across five clients. They include discovery, design, development, QA, and launch. They don't include the post-launch iteration phase (Phase 5), which is ongoing.
The budget ranges are wide because every product is different. A "simple SaaS" with three user roles, complex permissions, and five integrations costs more than a simple SaaS with one user type and basic CRUD. The complexity of your specific requirements drives the final number — which is exactly why we start with Phase 0.
Why This Process Works (When Others Don't)
I want to be direct about why I'm sharing all of this. It's not because our process is some secret sauce that no one else can replicate. It's because most teams don't follow any process consistently. They have a process on their website and a completely different reality in their Slack channels.
Our process works because of three principles we never compromise on:
- Validation before execution. Phase 0 and Phase 1 exist specifically to make sure we're building the right thing before we spend the bulk of the budget building it. This sounds obvious but you'd be shocked how many projects start with "just start coding, we'll figure it out."
- Transparency as a default. You see everything — the board, the code, the staging server, the bugs. There's nowhere for us to hide, and we don't want to hide. Trust is built on transparency, not on polished progress reports.
- Continuous quality, not end-of-project quality. Testing, code review, and CI/CD happen every day, not in a "QA phase" at the end. This means the product is always in a shippable state. If you need to launch early, you can. If priorities change, we adapt without starting over.
Michele's Take
I've been in this industry long enough to know that process without discipline is just theater. Anyone can draw a nice diagram of their "agile process" on a slide deck. What matters is: do they actually do code reviews? Do they actually write tests? Do they actually deploy to staging every sprint? Ask for proof. Ask to see their project board. Ask for references. If they hesitate, you have your answer.
Let's Apply This Process to Your Product
This is how we build software. Not sometimes — every time. Whether it's a $15K MVP or a $500K enterprise platform, the process is the same. The phases scale, the team size adjusts, but the discipline and the standards never change.
If you're reading this and thinking "this is the kind of team I want to work with" — here's what I'd suggest: start with Phase 0. A 2-week discovery session where we dig into your business, your users, your market, and your product idea. At the end, you get a validated Product Brief, a recommended tech stack, a realistic timeline, and a detailed budget estimate.
It costs between $3K-$8K depending on complexity, and it gives you total clarity on what it takes to turn your idea into a real product. No commitment beyond that. If you love the plan but want a different team to execute it — you own the deliverables, no strings attached.
Most clients who do Phase 0 with us end up staying for the full build. Not because they're locked in — because they finally feel confident they know exactly what they're getting, when they're getting it, and what it costs. And that confidence? That's the whole point.
Book a free intro call and let's talk about your project. No pitch deck required — just tell me what you're trying to build, and I'll tell you honestly whether (and how) we can help.