PixelForce takes a web app from first call to launch in ten steps, grouped into four commercial stages: a free discovery call, Phase 1 Scoping & Design, Phase 2 Development, QA and Release, and Phase 3 Post Launch Support. The steps below are the whole sequence, including the two most people skip and the one nobody can skip - we do not issue a development quote before the blueprint exists.
What changed since this article was first published
The 2015 version of this article described the first four steps as an obligation-free phase of three or four hours, and the design phase as a lead-in to a development contract. The sequence it described was broadly right. The economics were wrong.
A free scoping phase has to be cheap enough to give away, so it stays shallow, and a shallow specification produces an estimate that moves as soon as the build starts. Making scoping and design a paid, standalone phase is what allows it to be complete enough that the fixed price at the end holds. The steps below are the same journey with that correction applied.
Initial: the discovery call (free)
Step 1: Discovery and the 1-3-1 recommendation
A mutual non-disclosure agreement, a conversation about the business, the problem, the users and the vision, and a 1-3-1 recommendation: one problem, three options with their trade-offs, one recommendation across budget, timeline and scope. Budget alignment happens here, not after a proposal. We do not scope something a client cannot afford to build, and saying so early is cheaper for everyone than discovering it late.
Phase 1: Scoping & Design
Step 2: Preliminaries
You complete the Blueprint Preliminaries covering business objectives, target users, success metrics, design preferences and success sliders. The sliders decide the trade-offs. Speed, cost and scope cannot all be maximised, so nominating which one gives way is what lets the rest of the phase make decisions instead of deferring them.
Step 3: Two strategic workshops
Two focused sessions covering business requirements, product requirements, design direction and the product scope for version 1.0. Priorities are locked and trade-offs agreed in the room, with the people who can actually agree them present.
Step 4: The Business Requirements Document
Business goals, target users, the problems being solved, and the outcomes the platform must achieve. The BRD becomes the lens applied to every later feature decision, which is what stops scope arguments being settled by seniority.
Step 5: UX/UI design
An enterprise-grade design system - colour, typography, accessibility, iconography, components - plus high-fidelity designs for every consumer-facing screen and the key administration screens, with the full user journey mapped end to end. Every screen, not a representative sample: the screens nobody designed are the screens an engineer improvises during the build, and that is where a fixed price stops being fixed.
This is the step whose value is hardest to see upfront and most obvious afterwards. For Traininpink we built the number one female-focused Pilates and fitness app in Italy, serving over 182,000 women; since 2021 the platform has helped acquire over 40,000 paying subscribers. For OpBill, the AI-powered OCR claiming flow (Snap, Scroll, Done) made medical billing 90 percent faster with 98 percent user satisfaction, built in 4 months. Neither outcome came from a visual refresh. Both came from settling the product decisions on paper before anyone wrote code.
Step 6: The Product Requirements Document
The technical blueprint - feature logic, integrations, technology choices, and everything that cannot be captured visually. Error states, third-party behaviour and the permissions model are decided here rather than discovered in week nine.
Step 7: The fixed-cost Statement of Work
A fixed-cost, fixed-scope development contract with the full schedule, milestones and deliverables, for sign-off. This is the deliverable the previous six steps exist to make possible. You can stop here: Phase 1 is a standalone commitment and every artefact it produces is yours.
Phase 2: Development, QA and Release
Step 8: Build against the SoW, in milestones
Milestones are project-specific, but the shape holds: foundation setup covering database schema, authentication framework and core API scaffolding; a prototype demo proving a key technical pipeline; backend completion with cloud infrastructure and CI/CD pipelines; then the application build and integration. Cadence is fixed - a squad meeting every two weeks and planning every four - so progress is visible without anyone having to chase it.
Step 9: Internal QA, then client UAT
Internal testing verifies the build against the PRD acceptance criteria, followed by your User Acceptance Testing on a real environment. Quality assurance runs as its own discipline rather than as something engineers do to their own work; PixelForce reaches 95 percent test coverage, subject to agreed scope and engagement. Defects are resolved before sign-off, and sign-off starts the warranty.
Step 10: Release, then Phase 3 support
Production configuration, monitoring activation and go-live, then a decision about what happens next. Warranty, Monitoring and Support is a flat monthly fee covering critical-defect warranty, 24/7 infrastructure monitoring, business-hours incident response and a monthly platform health report. The Product Retainer adds a roadmap workshop, continuous sprints and quarterly business reviews, priced per four-week cycle against a committed story-point capacity, in tiers named Steady, Growth, Scale, Velocity and Momentum. Both are quoted for your platform before launch.
What decides the cost
Phase 1 Scoping & Design is a standalone commitment on purpose, so you can stop after it, and it is sized to the product rather than to a rate card. Phase 2 Development, QA and Release is quoted against the fixed-cost Statement of Work that Phase 1 produces, and what moves that number is what is genuinely being built: how many user types the platform serves, how much work the backend does, how many third-party systems it integrates with, and whether it carries regulated or financial logic. Where a budget stretches further than the scope requires, we usually advise keeping the first release tightly scoped and putting the remainder into iteration after launch, because the strongest products we have worked on earned their later scope from real usage rather than assuming it upfront.
What the process produces
EzLicence processes $100M+ in annual bookings and 250,000+ lesson hours booked each year, on the platform we built and still operate. Designerex grew 650 percent since the pandemic after our onshore rescue and replatform, becoming the number one designer dress-sharing platform with $40M+ in retail value listed.
The counter-example is just as instructive. iAppraise suffered chronic slowdowns and 500 errors at peak demand despite robust server specifications. We fixed the process and file-descriptor bottlenecks, moved the platform to an AWS Auto-Scaling Group with CI/CD pipelines and Secrets Manager, and it now rides traffic spikes with zero degradation, pays only for the capacity it uses, and the team builds features instead of firefighting infrastructure. Nothing in that project was a design problem. It was a set of decisions that were never made explicitly, which is the argument for steps 2 through 7 stated in the negative.
Where to go next
The full engagement is set out on our website design and development page. The design half of this sequence is covered in more depth in our web design process.