Most development companies describe their process vaguely or make it sound more elaborate than it is. Here’s exactly how I work, phase by phase.
Phase 1: Discovery (1-2 Weeks)
Before writing a line of code, I need to understand your business.
This isn’t generic “requirements gathering” — it’s an actual effort to understand:
- What your current process looks like (the real one, not the documented one)
- Where the friction is and what it’s costing you
- What the edge cases are
- What “success” looks like in concrete, measurable terms
- What integrations exist with other systems
- Who uses the software and how technically comfortable they are
I do this through a combination of conversations, observing your current workflow, and reviewing any existing documentation or systems.
What I produce: A requirements document and data model draft. This is the source of truth for the project — what we’re building, what “done” looks like, and what’s explicitly out of scope.
What I need from you: 3-6 hours of your time (or your subject matter expert’s time) in the first two weeks. Uninterrupted, focused time. The discovery phase has compounding value — an hour here saves days later.
Phase 2: Architecture and Design (3-5 Days)
With requirements clear, I design the system architecture. This covers:
- Database schema
- Application structure (monolith vs. services)
- Authentication and authorization approach
- Integration design
- Deployment and infrastructure approach
For UI-intensive projects, this phase includes wireframes or a prototype — something you can look at and verify matches the intended experience before I build the full thing.
What I produce: An architecture document and (when relevant) UI wireframes or a prototype.
What I need from you: Review and approval of the architecture, with specific input on any UI wireframes. This is your last easy opportunity to change direction before significant investment has been made.
Phase 3: Development (Varies by Scope)
This is the building phase. My approach:
Incremental delivery. I don’t disappear for months and reappear with a finished product. Features get built, reviewed, and deployed to a staging environment continuously. You see working software throughout the project.
Weekly demos. Every week, I show you what was built. Not a status report — working software you can interact with. This creates natural checkpoints for scope decisions.
Pull request workflow. All code goes through a structured review process. Even when I’m the only developer, code review catches problems.
Test-driven where it matters. Business logic gets tested as it’s built. Not after, not as a phase at the end.
What I need from you: Responsiveness on questions (24-hour turnaround on business-day questions), timely reviews of demos, and scope decisions when they’re needed. Projects stall when clients disappear for a week during active development.
Phase 4: Staging and Review (1-2 Weeks)
Before production deployment, there’s a period on staging — an environment identical to production but without real data or real users.
This phase involves:
- Thorough end-to-end testing against real-world scenarios
- Performance testing under load
- Security review
- User acceptance testing with real users from your organization
- Documentation finalization
What I produce: A fully tested application on staging with documented deployment plan.
What I need from you: Committed time from the actual users to do acceptance testing. This isn’t optional. Finding problems here is far cheaper than finding them after production launch.
Phase 5: Deployment (1-3 Days)
Production deployment on a planned, low-traffic window. The process includes:
- Database migration plan and rollback plan
- Deployment execution
- Monitoring setup
- Initial production verification
I don’t flip a switch and disappear. I’m available for the first week after launch to address any issues that only show up in production.
After Launch: Ongoing Support
Most of my projects continue in some form after initial launch. New features, bugs, performance improvements, dependency updates. I offer monthly retainer arrangements for ongoing work.
What good post-launch support looks like: Bug fixes addressed within 24-48 hours. Security updates applied promptly. New feature discussions that consider architectural implications, not just “can we build this.”
The Part Most Developers Skip: Clear Communication
Every phase of this process depends on clear, responsive communication. The projects that go wrong almost always have a communication problem — unclear requirements, delayed approvals, scope changes without discussion.
My commitment: I communicate proactively. I tell you when something is harder than expected. I tell you when a scope decision is needed. I tell you when something I’m building isn’t going to work the way we planned.
My expectation: you do the same. Real partnerships require honest communication from both sides.
Schedule a conversation to talk through your project and how this process would apply to it.