How We Deliver Projects
Every project moves through the same stages, each with a written output and a point where you accept it before the next stage starts. This page shows what we do, what we need from you and how acceptance works.
The stages
Small projects compress some stages into a single meeting; larger ones run design and build in iterations. The order does not change.
Discovery
We learn the business problem, the users, the current tools and the constraints. For larger projects this is a paid, fixed-length phase with workshops; for smaller ones it is one or two calls and a questionnaire. Output: a discovery summary with goals, requirements, risks and open questions.
Proposal
A written proposal with scope, exclusions, deliverables, timeline, team, assumptions, payment milestones and acceptance criteria for each stage. Nothing is built until it is signed. Output: the proposal and, where needed, a contract and data processing agreement.
Design
Information architecture, user flows, wireframes and visual design, or a technical design for integrations and automation. Designs are reviewed in rounds, with the number of rounds stated in the proposal. Output: approved designs or a technical specification.
Build
Development in short cycles on a staging environment you can see. We share progress at an agreed rhythm and raise blockers as soon as they appear. Output: working software on staging, feature by feature.
Quality assurance
Functional testing against the acceptance criteria, cross-browser and mobile checks, form and integration tests, performance and basic accessibility checks, and a review of analytics events. You then run user acceptance testing on staging. Output: a test record and a list of resolved issues.
Launch
A launch checklist covering DNS, SSL, redirects, tracking, backups, monitoring and rollback. We launch at an agreed time outside your peak hours and check the live system afterwards. Output: the live system and a launch report.
Handover
Access to every account, documentation, admin training and recorded walkthroughs. Output: a signed handover checklist.
Support
A warranty period for defects in what we delivered, followed by an optional maintenance or support agreement. Output: a support plan with response times and scope.
Who does what, and when each stage is accepted
| Stage | We deliver | You provide | Acceptance point |
|---|---|---|---|
| Discovery | Workshops, research, discovery summary | Access to decision-makers, current tools and data, examples of real enquiries or jobs | You confirm the summary reflects the problem and priorities |
| Proposal | Scope, exclusions, timeline, price, acceptance criteria | Budget range, deadlines, internal approvers | Signed proposal or contract |
| Design | Flows, wireframes, visual or technical design | Content, brand assets, feedback within the agreed review window, one consolidated set of comments per round | Written approval of designs |
| Build | Working features on staging, progress updates | Timely answers to questions, third-party account access, final content | Features reviewed on staging at agreed checkpoints |
| QA | Test record, fixes to defects against the acceptance criteria | User acceptance testing by the people who will use the system | Written sign-off that acceptance criteria are met |
| Launch | Launch checklist, go-live, post-launch checks | Domain and DNS access, a decision-maker available on launch day | Confirmation the live system matches staging |
| Handover | Documentation, credentials transfer, training | Named owners for each system on your side | Signed handover checklist |
| Support | Defect fixes in warranty, optional ongoing support | Issue reports with steps to reproduce | Per the support agreement |
Review windows, the number of design rounds and what happens if feedback is not received within the window are agreed in your proposal, so both sides know the timetable before work starts.
When the scope changes
Scope changes are normal. They are handled in writing: you describe the change, we reply with its effect on time and cost and what it displaces, and nothing is built until you approve it. Small changes can be swapped for something of similar size that has not been built yet. Changes are logged so the final invoice never contains a surprise.
What handover includes
- Admin access to the domain, hosting, CMS, code repository, analytics and every third-party service, in your company's name where the provider allows it.
- Source code and deployment configuration, with setup instructions a new developer can follow.
- Documentation of integrations, automations and their failure alerts: what triggers what, and who is notified when something breaks.
- Training for your editors or operators, and recorded walkthroughs for new staff.
- A list of known limitations and recommended next steps.
Ownership and licensing of the delivered work, including how any pre-existing or third-party components are licensed to you, are agreed in your proposal or contract.
After launch
Every project includes a warranty period during which we fix defects in what we delivered at no extra charge. Its length and what it covers are agreed in your proposal. After that, website maintenance or a support agreement covers updates, monitoring, security patches and small changes, with the scope and response times set in that agreement.
Start with discovery
- Book a discovery callTest fit and agree whether a discovery phase is needed.
- Request a project proposalSend your brief and receive a scoped proposal.
- About AlfalabWho we are and how we work.
Ready to build your growth system?
Send a short brief or message us on WhatsApp. We reply with questions, a suggested scope and the sensible next step.