Discovery: understanding the problem before writing code
Discovery is where we earn the right to build. We spend the first one to two weeks interviewing your team, mapping current workflows, and reviewing any existing systems, spreadsheets, or third-party tools. For a healthcare scheduling client, that meant shadowing front-desk staff for two days to see how appointments, cancellations, and provider availability actually interact. For a logistics tracking client, it meant tracing a single shipment from order entry to proof of delivery.
We produce a written problem statement, a prioritized backlog, and a rough architecture sketch. We name the stack early: for example React and TypeScript on the front end, Node.js with PostgreSQL on the back end, and AWS Lambda for asynchronous jobs. We do not commit to a fixed scope until we understand the constraints. The Agile Manifesto values working software over comprehensive documentation, and we take that seriously, but we still write down what we heard so you can correct us before code exists.
Client involvement during discovery is high: roughly two workshops per week, each 90 minutes, plus asynchronous review of the problem statement. We ask for one decision maker who can approve scope changes within 48 hours. Without that, discovery stalls and the timeline slips.
Design: prototypes and user feedback
Design starts with low-fidelity wireframes, not polished mockups. We sketch the five to eight screens that carry the most risk, then test them with five to seven real users from your customer base. For an e-commerce checkout, that means watching someone add an item, apply a discount code, and complete payment while we note where they hesitate. For a scheduling tool, it means testing how a patient picks a slot and how a receptionist reschedules it.
We build clickable prototypes in Figma and, when interaction matters, a thin React prototype that runs in the browser. We follow established usability guidance rather than inventing new patterns. Martin Fowler's writing on evolutionary design informs how we keep the interface and the domain model aligned as we learn. We do not treat design as a one-time phase; we revisit it when feedback contradicts our assumptions.
Client involvement is moderate: one review session per week, plus a shared Figma file where you can leave comments directly. We ask that feedback arrive within three business days so the next iteration stays on schedule. If your team cannot review weekly, we extend the design phase rather than guess.
Development: iterative delivery and weekly demos
We work in two-week iterations and demo working software every Friday. A demo is not a slide deck; it is a running build you can click through. For a logistics tracking dashboard, that might mean showing live map updates for a test shipment. For a scheduling system, it might mean booking, canceling, and rescheduling an appointment end to end.
Our default stack is React with TypeScript, Node.js with Express or Fastify, PostgreSQL for relational data, and Redis for caching. We deploy to AWS using containers or Lambda depending on traffic shape. We use GitHub for version control and GitHub Actions for continuous integration. Atlassian's agile guidance describes the value of short feedback loops, and weekly demos are how we shorten them.
Client involvement is high: one 30-minute demo per week, plus access to a staging environment where you can file bugs directly. We ask for a product owner who can answer questions within one business day. If priorities change mid-iteration, we finish the current work and replan at the next boundary rather than thrash.
Quality: testing, security, and performance
Quality is not a final phase; it is a constraint on every commit. We write unit tests for business logic, integration tests for API boundaries, and end-to-end tests for the three or four critical user journeys. We target 80 percent line coverage on core modules, not as a vanity metric but as a signal that regressions will be caught before they reach staging.
On security, we follow the OWASP Top Ten as a baseline: parameterized queries, output encoding, dependency scanning, and least-privilege access for AWS roles. We run automated dependency updates weekly and review high-severity advisories within two business days. On performance, we set explicit budgets: for example, a 200 millisecond server response at the 95th percentile and a 2.5 second largest contentful paint on mobile. We measure with real user monitoring, not just synthetic tests.
Client involvement is moderate: we share test reports and performance dashboards, and we ask you to review security findings that affect your data. If a finding requires a design change, we bring it to the next demo rather than hiding it in a backlog.
Delivery: deployment and handover
Delivery means your team can run the system without us. We deploy to production with blue-green or canary releases, automated rollback, and a documented runbook. We hand over source code, infrastructure definitions, environment variables, and a written architecture decision record. For a healthcare scheduling client, that included a training session for two administrators and a recorded walkthrough of the deployment pipeline.
We offer a 30-day support window after launch for defect fixes, and an optional retainer for ongoing maintenance. We do not disappear at launch. We also do not lock you in: everything we build is yours, and we document how to extend it. If you later hire an in-house team, they inherit a codebase with tests, CI, and readable history.
Client involvement is high in the final two weeks: acceptance testing, deployment rehearsal, and handover sessions. We ask for a named operations contact who can approve the production cutover.
| Phase | Duration | Key deliverables | Client involvement |
|---|---|---|---|
| Discovery | 2 weeks | Problem statement, backlog, architecture sketch | Two 90-minute workshops per week |
| Design | 3 weeks | Wireframes, clickable prototype, usability notes | One review session per week |
| Development | 10 weeks | Working increments, weekly demos, staging access | One 30-minute demo per week |
| Quality | Continuous | Test reports, security review, performance dashboards | Review of findings affecting your data |
| Delivery | 2 weeks | Production release, runbook, handover sessions | Acceptance testing and cutover approval |
For a typical mid-sized project, that is roughly 17 weeks from kickoff to handover, with a team of three to five people and an illustrative cost range of 90,000 to 180,000 USD. Smaller scopes compress to 8 to 10 weeks; larger ones extend past 24 weeks.
Before a discovery call, gather your current workflow notes, a list of systems you already use, and one decision maker who can approve scope. Ask any consultancy for a written problem statement and a phased estimate before you sign. Compare proposals on clarity of deliverables, not on hourly rate alone.
Sources
Background for this page was drawn from the published guidance below. Both are independent of this site and were read in full before writing.