Blind spots tend to appear when you think you’ve covered everything: the documentation is complete, the diagrams are solid, and the logic is sound. This is especially true in custom development, where there are no templates to lean on or UI references to copy, and user behavior is still largely unknown. Even if the requirements seem airtight, real-world usage exposes what’s missing.
Here’s how we ended up rebuilding entire modules from scratch and turning a near-failure into the successful release of a useful tool.
:Puls. Custom Hybrid Event Management Software – from Guest Lists to Logistics
Niche Domain, Niche Challenges
For the past year, we’ve been working with a company that organizes corporate offsite events (MICE). Our goal was to create an internal platform to cover every stage of event preparation for their managers and logistics team, from adding participants to managing flights, accommodations, and transfers.
Anyone in the travel or event planning industry can relate: when one detail changes, everything else shifts with it. That’s why the product turned out to be so flexible and complex, with interconnected tables, logic-heavy modules, and constantly changing data. However, it wasn't quite what the client had envisioned at the beginning.
From the beginning, the architecture was unique. There were no off-the-shelf solutions to borrow from. To their credit, the client had deep domain knowledge and a clear idea of how the process should work. They did their own discovery, put together detailed documentation, and handed us a solid brief.
To be honest, I was even a little relieved. Compared to most projects we see at kickoff, this one was well thought through. However, theory doesn't always survive contact with reality.
Worry about development difficulties? We'll help you avoid them!
What Looked Good on Paper
Early on, I realized just how big and dynamic this toll would be. To help us maintain a consistent and easily modifiable UI as requirements evolved, the designer proposed a multi-level design system.
Spoiler alert: that system saved us more than once.
How We Spent 100 Hours on Design and Ended Up Saving a Year of Development
We reviewed all functionality, sprint by sprint, with several client representatives who oversaw the project and made key decisions. As we began visualizing their requirements, however, new insights emerged. The client realized that some things that made sense on paper didn’t translate well into the interface. They also revisited elements they had overlooked during the initial planning phase.
Then came the turning point when we showed the nearly finished platform to the broader team of stakeholders. It became clear that parts of the system just didn’t match how the actual work was done. Some flows were confusing. Some features weren’t useful. Others were missing entirely.
Why? Because the product had essentially been built in a closed loop. The client’s internal teams, the future users, weren’t involved in reviews or validation. They saw the platform for the first time far too late.
We had two options: stick to the original scope and "polish" what we had or take a step back and help the client rethink the product. We chose the second path.
Here's what we did instead:
- Ran focus groups with actual users from across departments;
- Collected honest, detailed feedback from the field;
- Held working sessions with the client to reassess priorities;
- Rebuilt core parts of the product based on real-life use cases.
Despite this, we stayed aligned. Thanks to our ready-to-go component library, developers were able to move fast. Yes, some features were moved to the backlog. We had to step back. But what about the final product? It worked. It did what it was supposed to do.
What We Learned (and What We’d Recommend)
This project tested our flexibility, communication, and prioritization skills. Here’s what we’d tell any product or project team developing custom tools in a complex field:
Step 1. Narrow the Decision Circle, But Give Everyone a Voice
Having one or two decision-makers from the client’s side is ideal. It keeps things focused. However, don't limit product thinking to just their perspective.
Tips:
- Run short surveys or interviews with users from different roles;
- Organize their input into a table showing what they need, why they need it, and how critical it is;
- Share the aggregated view with your client. This way, you can prioritize based on patterns, not personal opinions.
Step 2: Talk to Users Before You Start Building
Even if your client has already completed a research phase, double-check the scope. How many users were involved? Which roles were represented? Just a few blind spots can derail a release.
Tips:
- If the original feedback came from a small group, reach out to a broader group. Quick polls or 15-minute interviews can reveal hidden gaps;
- Don't just ask people what they want. Ask how they currently work, what slows them down, and what frustrates them.
Step 3: Lock in the Logic Before You Touch the UI
Design can’t fix broken logic. And rushing into UI design can lead to weeks of rework.
Tips:
- Use MVP trees, user flow diagrams, or click-through prototypes;
- Pressure test the logic with the client early before you hit “Dev Start.”
Step 4: Budget for Rebuilds
We rebuilt the entire transfer module in a week. It had already been approved. However, when users tried it in context, it didn't work well.
Tips:
- Allow time and budget for revising at least one key process;
- Set a rule that if a feature doesn't solve a real problem during the demo, it gets redone;
- Align with the client upfront on how you’ll decide what qualifies for revision.
Step 5: Share early with focus groups
Don't wait for the "final" demo. Even a half-built version can offer valuable insights.
Tips:
- Invite a handful of real users from different roles.
- Let them walk through real tasks and provide feedback.
A few sharp comments now can save you from making changes later.
Additionally: Get your team involved.
When building for a closed domain, you need a team that is deeply involved.
Tips:
- Hold internal demos so your team understands how the product is used;
- Walk through real scenarios together. Who fills out the form? Who edits? Who checks the status?
- Document user insights by role: What do they need? What frustrates them? What do they expect?
Just because the brief is clear doesn't mean the product will be. Even the most confident client is working off assumptions, and it's your job as a manager to spot the gaps before they become blockers. Your involvement smooths out the bumps, identifies what’s missing, and helps the team pivot when reality sets in.
Requirements aren't the truth; they're a hypothesis. The sooner you start testing them against real-life scenarios, the better your chances of building a product that works and doesn't just check boxes.
