Our client, David’s Bridal, started rolling out its new ecommerce platform in early 2022. It was a long-awaited launch for the David’s team: nearly four years since they had initially kicked off an ecomm replatform with a different agency, and about two years since Bilberrry took over to get the stalled integration up and running. You can read about what we did to build David’s a successful ecomm solution, but there is more to the story than technical execution. Any project rescue will require extra layers of trust building and risk mitigation from the start.
We had just wrapped up a strong year working with David’s Bridal on a suite of customer-facing digital tools when the team asked if we could pitch in on their stalled ecomm work. We knew as soon as we’d finished our initial code audit that there wasn’t much their other agency partner had built that could be salvaged — but David’s was understandably gun-shy about starting again from scratch.
It’s one thing to tell a client that your approach to a complex problem will work. It’s another thing for that client to believe you, especially if a different agency had said the exact same thing, then spent 18 months working on a solution that ultimately failed. Here’s what we did to build enough trust to do it our way.
Sprint toward small, realistic milestones
Our first priority was to show the David’s team early proof points that we were making the right decisions — not months of heads-down work with a final product revealed at the end.
We set our first milestone at 12 weeks, with the goal of proving two things that the previous agency couldn’t:
- We could integrate any new platforms we build with David’s legacy data
- All the pieces of our tech stack could work together at scale
Sprinting toward proofs of concept isn’t a particularly novel approach to software development. Lots of teams use it as part of an agile approach to fail fast on the way to a viable solution. But it was definitely new for David’s, who with the previous agency had been designing and developing each individual microservice in silos, and without using real data. Unfortunately, when it was time to put all the pieces together, nothing worked.
Once we hit our first 12-week milestone, we set another, then another, continuously building off the previous work. These rev cycles were especially important because our proofs of concept were also doing double duty as our discovery and requirements-gathering.
On a development project as big and complex as David’s Bridal’s ecomm, we couldn’t know what we didn’t know until we started working with the actual services, platforms, and data. Building the core framework end-to-end — and getting stakeholder feedback on the proofs of concept along the way — helped reveal necessary information that would have been delayed if we’d spent a lot of time, say, perfecting the front-end designs of each service.
Align early and often on business requirements
Documentation for this project was key. Business requirements will always update and evolve over the course of the engagement, so we wanted to stay on top of how everything was supposed to function and avoid big surprises, even while we were building fast.
Surprises typically come up during the user testing phase — when our client flags that we designed something based on an inaccurate assumption, or they have totally new requirements we’d never heard about. Rigorous user stories and robust documentation mitigates this. It goes like this:
- Start gathering business requirements
- Use those to build a proof of concept
- Finalize requirements with stakeholders be demo-ing the proof of concept, and reviewing documentation
- Refine, build, repeat
There are business-specific rules and complex edge cases for everything from shipping fees, to returns and cancellation policies, to managing taxes. Something as simple as “discounts and promotions” in the shopping cart required specifications around how they were applied, what happens with taxes, and so on.
This level of documentation not only helped shape how we built each component and service of the solution, but also is the only way we know if we built it right. How else do you know what to test when you’re ready to start testing?
Shoulder some of the risk
We believe that Bilberrry is a true partner to our clients. It was crucial to this project’s success that the David’s team believed it too — we needed them to grant us the decision-making power of their CTO and in-house product team. So we put some money where our mouth was: we offered to let David’s hold on to 20% of the total invoice as a “success fee” until after we launched.