Most agencies sell you a vision in the meeting. A polished deck, impressive references, all the right words about agile and user-centric design.
Then you sign. And silence.
Weeks pass. You send a follow-up email. You get a vague update. Eventually, you see a demo that doesn't match what you discussed. By then, you've already paid 40% and you're wondering what happened.
We hear this story from almost every client who comes to us after a failed engagement. The problem is rarely technical. It's process. The agency didn't have one — or didn't follow the one they promised.
This post is the answer we give every prospect who asks: "What actually happens after we sign?"
Phase 1: Kickoff and scope lock
Before we write a single line of code, we lock the scope. Not with a vague proposal — with a document that both sides sign off on.
The kickoff isn't a casual chat. It's a structured working session where we turn a client's brief into something buildable. That means user stories with acceptance criteria, a prioritized feature list, and — just as important — an explicit "not in scope" section. If you haven't written a brief yet, we've published a guide on how to write one that actually helps.
That last part matters more than people think. Scope creep doesn't start with big requests. It starts with assumptions. "I assumed the dashboard would also have exports." "I thought the mobile version was included." If it's not written down and agreed on, it doesn't exist.
We say no to things early so we don't have to say "that'll cost extra" later. Clients appreciate this more than they expect to.
The deliverable from this phase: a scoped requirements document with priorities, timelines, and boundaries. The client approves it before we move forward.
Phase 2: Design and validation
We design before we build. That sounds obvious, but you'd be surprised how many projects jump straight from a brief to code.
Our process: wireframes first, then UI design. The client sees and approves the flow — every screen, every interaction — before we touch a code editor. This isn't about making things pretty. It's about catching misunderstandings early, when they cost hours to fix instead of weeks.
"Approval" here means something specific. It means the client has reviewed every screen, confirmed the flow matches their expectations, and signed off. Not a thumbs-up emoji on Slack. A documented confirmation that says "yes, build this."
This phase kills the biggest risk in software projects: building the right thing wrong, or the wrong thing right.
Phase 3: Build in sprints, demo every two weeks
We work in two-week cycles. At the end of each cycle, the client gets a live demo of what was built — running software, not slides.
This is non-negotiable for us. We never disappear for a month and come back with a surprise. Every two weeks, the client sees progress, gives feedback, and confirms we're on track.
What happens when the client wants to change something mid-sprint? It happens on every project, and it's fine — as long as it's managed. We evaluate the change: does it fit within the current sprint? Does it replace something else? Does it push the timeline? We give the client the trade-off, they decide, and we document it. No drama, no hidden costs. How we handle the financial side of this depends on the pricing model — we've written a separate post explaining how each model handles scope changes differently.
The rhythm matters. Two-week cycles create accountability on both sides. We deliver consistently, and the client stays engaged. Projects that go dark — where the client disappears for a month and then reappears with new priorities — are the ones that fail. The sprint structure prevents that.
Phase 4: Testing, handoff, and go-live
Before anything goes to production, it goes through QA. We test on staging — a mirror of the production environment — where the client can also test and flag issues.
Deployment isn't a stressful event for us. We use automated deployment pipelines. Staging to production is a controlled process, not a prayer.
What the client receives at handoff isn't just access to a live application. It's a package: the complete source code in a Git repository, technical documentation covering architecture, setup, and key decisions, admin credentials and environment configuration, and a training session so the client's team can actually use and manage what we built.
"Done" means the client can operate the software without us. If they need us for future development, great. But they're never locked in. The code is theirs, the documentation is clear, and any competent developer can pick it up. What comes next — hosting, security updates, ongoing development — is a separate conversation we have before launch, not after. We've written about what post-launch maintenance actually involves and what it costs.
What we don't do
These aren't complaints about the industry. They're commitments we make to every client:
We don't start without a signed scope. We don't skip the design phase. We don't disappear between demos. We don't hand over undocumented code. We don't hold code hostage. We don't say "that was included" when it wasn't written down.
Every one of these comes from a pattern we've seen in failed projects that clients brought to us for rescue. We built our process specifically to avoid them.
What this means for you
If you've been through a failed software engagement before, most of what I've described will sound like common sense. That's the point. Good delivery isn't magic — it's discipline applied consistently.
If this is your first custom software project, use this post as a checklist. Ask your agency: what does your delivery process look like? If the answer is vague, that tells you something. We've compiled the full list of questions to ask before signing.
We've written before about why we build everything on Laravel — our stack choice is part of how we deliver reliably. We've also covered how long projects actually take and when building custom is the right call in the first place. But the stack is just a tool. The process is what makes or breaks a project.
Have a project in mind — or one that needs rescuing? Let's talk →