What to Expect During a Custom Software Project (Week by Week)

Weeks 1–2: Discovery, Scoping, and Kick-Off

The first two weeks of a project are the most important and the most often rushed. This is the discovery phase: a structured series of working sessions in which your development team learns everything they need to know about what you are building, why, for whom, and in what technical and business context. You should expect a kick-off call in week one to introduce the teams, agree the communication protocol, and confirm the project goals. This is followed by one or more discovery workshops — detailed sessions in which the team asks questions about your users, workflows, integrations, business rules, and data. By the end of week two, you should receive a scope document describing what will be built, a set of user stories covering each feature, and an updated project plan confirming the timeline and next steps. Your role is to be available, think carefully, and answer questions honestly — including uncomfortable ones about what is genuinely required vs what would be nice to have.

• Kick-off call: introductions, communication protocols, project goals confirmed
• Discovery workshops: requirements gathered, business rules documented, integrations mapped
• Scope document produced: written description of what will be built
• User stories written: each feature described from the user's perspective
• Project timeline confirmed: week-by-week plan from discovery to go-live

Weeks 3–4: UX Design and Prototype Review

Once the scope is agreed, the design phase begins. Your development team's designer translates the requirements into screen-level designs — wireframes first, then higher-fidelity mockups for the key screens. Wireframes are low-detail layouts that show the structure and flow of each screen without visual polish. They are fast to produce and fast to revise, which makes them the right tool for testing layout decisions before anyone writes code. Once wireframes are approved, higher-fidelity mockups are produced for the most important screens — the dashboard, the core workflow, the main data views. These show colour, typography, component styles, and overall visual tone. The key principle here: feedback on design is cheap. Feedback on code is expensive. Every visual problem you catch at the wireframe stage is five to ten times cheaper to fix than it would be after development.

Do not approve designs you are uncertain about just to keep the project moving. A week of revision at the design stage prevents a month of rework at the development stage. Raise every concern, however small.

Weeks 5–12: Sprint-Based Development and Demos

The development phase is where the software is built. In an agile project, this happens in sprints — typically two-week cycles, each focused on a defined set of features. At the start of each sprint, the team confirms which user stories will be built. At the end of each sprint, they deliver a working demo of everything completed in that cycle. Sprint demos are the most important touchpoints in the build phase. They let you see real, working software at regular intervals rather than waiting for a big reveal at the end. They give you the opportunity to confirm that each feature works as intended, raise questions, and catch misunderstandings while they are still cheap to fix. Your role is to attend demos, test the features delivered, and provide clear, specific feedback within an agreed window — typically 48 hours. Delayed feedback delays the project. Vague feedback creates rework. Specific feedback gets actioned immediately.

• Sprint planning: team confirms which features will be built in the coming two weeks
• Sprint demo: working software shown at end of each sprint for review and approval
• Feedback window: your feedback should be specific and delivered within 48 hours
• Change requests: scope changes mid-build require a formal assessment of time and cost impact
• Progress visibility: you should always know what is built, what is next, and what is at risk

Testing Week: What QA Covers

Once development is complete, the project moves into dedicated quality assurance testing. A professional development team will run both functional testing (does each feature do what the requirements say it should?) and non-functional testing (is the system fast enough, secure, and stable under expected load?). You will also conduct user acceptance testing — your own structured walkthrough of the system against your requirements. UAT is not casual browsing. It is a methodical process of testing every feature you specified, in the workflows you described, with realistic data. The development team provides a test plan to guide you. Issues raised during UAT are categorised by severity — critical issues are fixed before go-live, minor issues are scheduled for the first post-launch patch.

Deployment and Go-Live

Go-live is the migration of the system from its staging environment (a private copy used for testing) to its production environment (the live version accessible to real users). A professional deployment process includes a final pre-launch checklist covering security configuration, domain and SSL setup, data migration (if applicable), and backup and recovery procedures.

Do not agree to go live before UAT is complete. The pressure to hit a launch date can lead to deploying a system with known issues — and known issues in production always cost more to manage than known issues in a controlled test environment.

Post-Launch: What Support Looks Like

After go-live, a good development partner remains involved through a defined support and maintenance arrangement. This typically covers bug fixes for issues discovered post-launch, minor enhancements identified during the first weeks of use, performance monitoring, security patching for underlying dependencies, and hosting management. Support arrangements vary: some teams offer a retained monthly support package; others work on a time-and-materials basis. What matters is that the arrangement is agreed before go-live, not after. Post-launch is also when Phase 2 planning begins. With real users using the system and generating feedback, you now have concrete evidence to inform what to build next. The features that seemed essential before launch sometimes turn out to be irrelevant. The features users request repeatedly in the first month become the obvious Phase 2 priorities.

• Bug fixes for issues discovered in production after go-live
• Performance monitoring and alerts for errors or downtime
• Security patches for frameworks and dependencies
• Minor enhancements based on initial user feedback
• Phase 2 planning based on real usage data and user feedback

How to Be a Great Client During the Build

The most successful software projects are collaborations. A great development partner brings technical expertise. A great client brings business knowledge, clear decision-making, and responsive communication. The single most impactful thing you can do as a client is respond quickly. Every time the development team needs a decision or a piece of information from you, the clock stops. Delays in approvals and feedback add directly to project duration. The second most impactful thing is to give specific feedback. 'I don't like this' is not useful. 'The list should be sorted by date by default, not alphabetically' is actioned immediately. The third is to avoid mid-project scope changes. Every addition to scope mid-build disrupts the team's plan and adds cost. Log new ideas for Phase 2.

• Respond to questions and approval requests within 24 hours
• Give specific, actionable feedback — not vague impressions
• Avoid scope changes mid-sprint — log them for Phase 2
• Attend every sprint demo — they are the project's quality control mechanism
• Trust the team's technical judgement — focus on outcomes, not implementation details