I want to walk through how a typical custom project actually unfolds at our shop, end to end — not a polished highlight reel, but the real sequence of decisions, problems, and tradeoffs, because most “case study” content online is so sanitized it’s not actually useful to someone trying to understand what to expect from their own project.
It starts with questions, not answers
Discovery is mostly us asking questions the client hasn’t fully thought through yet — not just “what do you want the site to do,” but who’s actually going to update it after launch, what happens to your current SEO rankings if URLs change, what your busiest season looks like, and what “success” looks like in a measurable way three months after launch.
Honest scoping, even when it’s not what the client hoped to hear
I’ve had a client request what they described as “a simple booking feature” that, once we mapped the actual business rules — different technician availability, service-area restrictions, buffer time between appointments, automatic rescheduling — was genuinely a multi-week custom build, not a plugin install. Being upfront about that at the scoping stage saves everyone from a much worse conversation three weeks into a project that was underquoted.
Design and build happen in parallel, once scope is locked
Wireframes and content structure first, then visual design, then development starts on approved sections rather than waiting for the entire design to be signed off. This only works if scope was genuinely locked beforehand — if design keeps changing mid-build, the parallel approach backfires because development has to keep reworking to match.
Testing is the phase that gets rushed most often
Real testing means checking actual functionality across browsers and devices, not just “does it look right on my laptop” — form submissions actually delivering, payment flows completing correctly with test transactions, integrations passing data both directions correctly. I’ve caught real bugs in this phase that would have meant lost orders or broken lead capture if they’d shipped.
Launch itself should be anticlimactic
DNS changes timed for low-traffic hours, redirects verified working before the old site goes fully offline, analytics and tracking confirmed firing correctly within the first hour. A launch that requires heroics at 11pm usually means something in the planning was rushed.
What separates a good project from a mediocre one
We check back in at two weeks and thirty days post-launch to review actual usage data against what the client expected. That’s caught real problems: a client’s new quote-request form was technically working but converting at a much lower rate than the old one, which we traced to an extra required field that seemed reasonable in a meeting but was clearly costing completions in the actual data. We removed it, and conversions recovered within the next reporting period.
The bottom line
If you’re evaluating any agency for a project like this, the questions worth asking are less about their portfolio and more about their process: how do they handle scope changes discovered mid-project, what does their testing process actually check beyond visual review, and what happens in the weeks after launch — is there a follow-up built into the engagement, or does the relationship effectively end the moment the site goes live?