At RIVER, every project starts with a designer and an engineer in the same room. Not sequentially. Not "design first, then build." Together, from day one. This isn't accidental. It's the practice that's had the single biggest impact on the quality of what we deliver. And it runs counter to how most agencies and enterprise teams are structured.
The Handoff Problem
Rainui: The industry default is handoff. A designer produces mockups, annotates them, uploads them to InVision or Zeplin, and hands them to a developer. The developer interprets those mockups, makes compromises the designer didn't anticipate, and builds something that's 70% of the original vision.
The designer reviews it, flags the gaps, the developer explains why those gaps exist (technical constraints, performance implications, timeline pressure), and a negotiation begins. Half the project time gets consumed by this back-and-forth between two disciplines that should have been aligned from the start.
I've worked in agencies where I wouldn't see the engineering team until the design phase was "complete." By then, I'd invested weeks in a direction that might not be technically feasible, or that missed an elegant engineering solution that would have changed the design entirely.
John: From the engineering side, receiving a design package feels like receiving a set of instructions written by someone who doesn't know your language. The mockups look beautiful. They also assume instantaneous data loading, unlimited screen real estate, and users who navigate in the exact sequence the designer imagined.
The constraints that shape engineering decisions, database query performance, API response times, state management complexity, are invisible in a static design. By the time I see the design, these constraints become compromises. The design gets watered down, and nobody's happy.
The RIVER Model
Rainui: At RIVER, I sit next to John (or whoever the lead engineer is) from the first client meeting. When I'm sketching interface concepts, I can turn and ask "is this data available in the API?" When John's considering a technical architecture, he can ask "what does this mean for the user's workflow?"
This sounds simple. It changes everything.
When I design next to an engineer, I design better things. Not because they constrain me, but because they show me possibilities I wouldn't have seen alone.
Rainui Teihotua
Chief Creative Officer
John: The technical decisions I make are different when Rainui's in the room. I think about data structures in terms of how they'll be displayed, not just how they'll be stored. I consider API response shapes in terms of what the interface needs, not just what's convenient for the backend. The architecture serves the user experience because the user experience is part of the conversation from the beginning.
How It Works in Practice
Discovery together. Both disciplines attend stakeholder interviews and user research sessions. The designer hears the user's pain points directly. The engineer hears the technical constraints from the client's IT team. Neither discipline gets the information second-hand.
Sketch together. Before any formal design work begins, we sketch. Whiteboards, paper, rough wireframes. The designer explores layout and interaction. The engineer identifies data requirements and technical patterns. The sketch evolves through conversation, not handoff.
Build in parallel. While the designer refines the interface in Figma, the engineer builds the underlying architecture. They're synchronised because they've been in the same conversations. When the design is ready for implementation, the architecture is ready to support it.
Review together. When the build is in progress, the designer reviews the implementation daily. Not in a formal review meeting. By looking over the engineer's shoulder (or screen) and catching gaps while they're a ten-minute fix, not a two-day rework.
What It Produces
Rainui: The interfaces we deliver are better because they're designed within real constraints. Not theoretical constraints imagined from a specification document. Real ones that the engineer identified and the designer designed around.
A recent project involved a dashboard that needed to display real-time data from six different sources. In a handoff model, I'd have designed an ideal layout and then watched it get compromised as the engineer discovered that two of those data sources had 3-second latency. In our model, John told me about the latency in the sketching phase. I designed a progressive loading pattern where the fast data appeared immediately and the slower data loaded into designated spaces. The result was better than either of us would have produced alone.
John: The code I write is better because I understand the intent behind the design. When I know why a particular interaction works the way it does, I can make implementation decisions that preserve that intent even when I need to adapt for technical reasons.
Handoff produces technically correct implementations of partially understood designs. Collaboration produces solutions that neither discipline could have built alone.
John Li
Chief Technology Officer
The Cost Objection
Clients sometimes ask whether having two senior people in every meeting is an efficient use of budget. It's a fair question.
Rainui: The answer is that it's dramatically more efficient than the alternative. Handoff creates rework. Misaligned design and engineering create compromises. The back-and-forth negotiation between disciplines after the fact consumes far more time than the upfront investment in having both perspectives in the room.
John: On the engineering side, building the right thing the first time is always cheaper than building the wrong thing and fixing it. The pairing model means the "right thing" is defined collaboratively, so the build has fewer surprises, fewer rewrites, and fewer of those moments where the designer says "that's not what I meant."
We've been working this way for years now. Neither of us can imagine going back.