Most people hire a web development company the same way they buy furniture. Get a few quotes, pick the one that feels right, pay the deposit, and hope for the best.
Six weeks later, they're either delighted or emailing me asking if we can rescue a project that went sideways.
After 50+ projects across India, Dubai, and Singapore, I can tell you exactly what a good process looks like — and exactly where the bad ones break down. This is the step-by-step guide I wish existed before every client who came to us after a difficult first experience.
Step 1: The Discovery Call (30–60 Minutes)
Before any quotes. Before any scope documents. Before any pricing.
A discovery call is where a good agency figures out whether they can actually help you — and whether you're a good fit for each other. In our discovery calls, we ask these questions without exception:
- What problem are you actually trying to solve? (Not "build a website" — what business outcome?)
- Who is your customer and how do they currently find you?
- What does success look like in 90 days and in 12 months?
- What's broken about what you have now?
- What's your internal team situation after launch — who will manage the site?
- What's your realistic timeline? Is there a hard deadline and why?
We're not asking these to fill out a form. We're diagnosing. The answers change what we recommend, what we quote, and sometimes whether we recommend ourselves at all.
A discovery call shorter than 30 minutes usually means the agency already decided what to sell you before the call started. That's a flag.
Step 2: Scoping (What's In, What's Out)
After the discovery call, a good agency produces a scope document — not a quote, a scope document.
The scope defines:
- What we're building — an explicit feature list, not category descriptions
- What we're not building — equally important; scope creep happens in the gaps
- Technical choices and why — which platform, which architecture, which approach and the reasoning
- What we need from you — content, imagery, access to existing systems, decisions required
- What defines "done" for each deliverable
At Innovatrix Infotech, we operate on fixed-price, sprint-based engagements. Fixed price means no surprise invoices. Sprint-based means you see working software every two weeks, not a finished product three months from now when it's too late to course-correct.
The scoping conversation is also where unrealistic expectations surface. If a client needs 15 custom integrations, a mobile app, and a CMS for a ₹50,000 budget in four weeks — the honest conversation happens at scoping, not at delivery.
Step 3: The Proposal
A proper proposal covers:
- Project timeline — realistic milestones, sprint dates, and launch window
- Fixed price, broken down — not just a total, but what each phase and sprint delivers
- Revision policy — how many rounds of changes are included and what happens if requirements change
- Launch plan — staging environment, testing protocol, go-live process
- Post-launch support options — what happens after delivery, what the SLA looks like
Watch for proposals that are vague about deliverables. "Website redesign — ₹1,20,000" with no further breakdown means the agency can't be held to anything specific. That vagueness protects them, not you.
Step 4: Design Approval and Environment Setup
Before a single line of production code is written, design should be approved.
For most web projects: wireframes first (structure and user flow), then visual design. You should be reviewing designs in a proper design tool — Figma is our standard — not screenshots in a PDF or mockup images in a slide deck.
Simultaneously, we set up:
- Staging environment — the development version of your site, password-protected and not indexed by Google
- Version control — all code in a Git repository from day one
- Project management — tasks, progress tracking, and a shared communication channel
You should be able to see progress at any time. If an agency won't give you staging environment access during development, that's a significant flag.
Step 5: Sprint-Based Development
We work in 2-week sprints. Each sprint starts with a planning call — what we'll build this sprint, what decisions we need from you. Each sprint ends with a demo: a working, interactive preview of what was built.
This matters because:
- Problems are caught early, not at the end when they're expensive to fix
- Feedback is actionable while the code is fresh
- The project can be re-scoped mid-way if requirements legitimately change
A development process where you see nothing until "launch" is designed to give the agency maximum flexibility and you minimum oversight. Avoid it.
During sprints, we build features, integrate third-party services, and configure the CMS. For Shopify projects, this is when custom Liquid sections are built, apps are configured, and checkout flows are tested. For web applications, this is when backend APIs, frontend interfaces, and database schemas take shape.
Step 6: User Acceptance Testing (UAT)
Before launch, you test everything.
UAT is your formal period to click through every page, test every form, try every checkout path, check every email trigger. We provide a test checklist — you check against it and log anything that doesn't match the agreed specification.
This is not a "looks good" review. It's functional testing against scope. If something was in scope and isn't working, it gets fixed before launch. If something wasn't in scope and you want it added, that's a change order with a defined cost and timeline impact.
Good UAT typically takes 3–7 business days depending on project complexity. Rushing it is how launch-day surprises happen.
Step 7: Staged Launch
We never just flip a switch. A proper launch sequence:
- Final backup of any existing site or data
- DNS pre-configuration — TTL reduction 48 hours before go-live to minimise propagation time
- Staging → Production deployment in a maintenance window (typically late night)
- Post-deployment verification — every page, every integration, every redirect tested in production
- Monitoring enabled — uptime alerts, error tracking, and performance monitoring active from launch
For Shopify stores, this includes redirecting legacy URLs where SEO value exists, configuring payment gateways in live mode, and submitting the sitemap to Google Search Console.
A launch without a documented rollback plan is a launch without a safety net.
Step 8: Handover and Documentation
At project close, you receive:
- Access to everything — hosting, code repository, CMS, domain registrar, analytics accounts
- Documentation — how to update content, how to add products, who to contact if something breaks
- Training — for you or your team on day-to-day site management
We produce a structured handover document for every project. If you're handed a login and a "good luck" — that's not a handover. Push for the documentation before final payment is released.
Step 9: Post-Launch Support
Websites require ongoing attention. Plugins update and break things. Shopify releases platform changes. Security patches ship. Content needs updating.
Define what post-launch support looks like before you sign anything. Our managed services offering provides SLA-backed support — meaning we respond to critical issues within a defined window, not "when we get around to it."
The question to ask any agency: if the site breaks at 2pm on a Tuesday, what happens? Who do you call? What's the response time commitment? If the agency can't answer that clearly at proposal stage, budget for finding a separate support partner after launch.
Red Flags That Should End the Conversation
These are disqualifying signals regardless of how strong the portfolio looks:
Hourly billing on a fixed-scope project. Hourly billing creates a misalignment of incentives. The agency profits from the project taking longer. Fixed-price billing aligns incentives — we want to deliver efficiently.
No discovery call, straight to quote. They're selling you something before understanding your problem. The quote will be wrong.
No staging environment. Building directly in your production account or on the live site is how live stores go down mid-business-day.
Refusing to provide a fixed price. "It depends" is a valid answer in scoping. It's not a valid answer in the proposal. If they can't tell you what it costs, they can't tell you what they're building.
No verifiable references or case studies. Anyone can have a portfolio page. References mean real clients you can actually call and ask about their experience.
Solo freelancer on a multi-month project. Freelancers get sick. Freelancers take on other clients. Freelancers disappear mid-project. A 3-month engagement with a single point of failure is a risk management problem with no good solution once the work starts.
What to Prepare Before Your First Call
You don't need a polished brief. You need:
- A clear description of what you're building and why
- Your realistic budget range (not your opening bid — your actual number)
- Your hard deadline if one exists, and the business reason behind it
- Your existing website analytics if you have a live site
- 3–5 sites you think look good or work well as reference points
The best first calls are honest conversations. Not perfectly structured briefs — honest conversations.
For a deeper look at what our web development process delivers, see our web development service page. If you're specifically evaluating Shopify development, our Shopify service page covers our approach, case studies, and the specific outcomes we build for.