×
![Modal Image]()
From a four-week OfficeTogether MVP to a backend migration inside a much larger engineering organization.
“I need a functioning product demo in four weeks. Can you do it?”
Amy Yin asked Ian Panchèvre that question in September 2020.
There was no finished product yet. OfficeTogether was still an idea, supported by early wireframes and a clear problem: companies were trying to figure out how people would return to offices that no longer worked the way they had before.
Amy had a meeting with the CTO of a large enterprise at the end of the month, which turned the idea into a very specific delivery deadline. Over the next four weeks, the team worked from the early wireframes and product direction to build the first functioning version of OfficeTogether.
By the time of the meeting, the MVP was ready to demonstrate.
What began as a four-week build grew into roughly two years of product development with OfficeTogether. After the acquisition, the engagement continued inside Envoy, where the team had to adapt to a larger engineering organization, a different technology stack, and a backend migration that came with a very different set of constraints.
The context had changed significantly, but the expectation had not: understand the environment quickly, work within the client’s existing processes, and contribute where the team needed it most.
OfficeTogether was built around a workplace problem that had suddenly become urgent. As companies moved toward hybrid work, someone had to answer practical questions that used to be implicit: Who is coming in? How many people can the office support? Where will they sit? How do teams coordinate days together? How do employees reserve shared resources and plan events?
The first version of OfficeTogether needed to make those problems manageable, and it needed to exist quickly.
Amplified assembled an engineering team and worked directly with Amy to turn the early product direction into a functioning MVP. After the initial four-week sprint, the engagement continued.
Over the next two years, OfficeTogether evolved into a production web application. As the company hired its own engineers, Amplified stayed inside the product team, continuing feature work while helping onboard people into the codebase and the product.
In August 2022, Envoy announced its acquisition of OfficeTogether. Envoy said the OfficeTogether team would join the company and help accelerate development of its workplace platform.
For an external engineering team, an acquisition is an obvious place for an engagement to end. This one did not. Envoy asked the Amplified team to continue working after the acquisition. But continuity of the team did not mean continuity of the environment.
OfficeTogether had primarily been built in React and Node.js. Envoy introduced a substantially different stack and a larger engineering organization, including Kotlin, Python and Ember, with the team later working around technologies and infrastructure such as Kafka and Kubernetes.
We were no longer extending a product and codebase we had helped shape from the beginning. We had to learn somebody else’s architecture, deployment practices, engineering conventions and decision-making process quickly enough to contribute without creating a second way of working beside it.
One of the first major assignments inside Envoy was straightforward to describe: rewrite and replace the backend behind Rooms without making the migration the customer’s problem.
Rooms supported the workplace experience around shared meeting spaces. The existing product was already in use, and its backend sat inside an environment of interconnected services maintained by multiple engineering teams.
That meant success was not simply “the new backend works.” Existing behavior needed to remain predictable while the underlying system changed. The migration needed enough logging and analytics to expose unexpected problems. Dependencies between services had to be understood rather than discovered through customers.
And the transition could not require people to reinstall or update their application just because the infrastructure behind it had changed.
That number is useful because it describes an outcome without requiring us to call the work “perfect,” “exceptional,” or “above and beyond.” The result can speak for itself.
The engagement also extended into the Rooms tablet experience. The original work included capabilities around creating meetings, booking rooms ahead of time, surfacing attendees and room amenities, and improving how the physical meeting-room experience connected to Envoy’s broader workplace product.
Backend migration and tablet UX look like different engineering problems. In practice, they shared an important constraint: both were changes inside an existing product that people were already relying on. The job was not to redesign the world around the new implementation. It was to understand the world that already existed.
The transition from OfficeTogether to Envoy changed more than the technologies.
At OfficeTogether, Amplified had been involved from the first MVP. Inside Envoy, the team entered a mature engineering environment with more stakeholders, multiple services and established production practices. That required a different kind of autonomy.
The adaptability point is particularly useful because it is specific. After the acquisition, the team moved from React and Node.js into Kotlin, Kafka, Ember and Kubernetes. It also adopted production practices including daily deployments, happy-path testing, feature flags and system-design RFCs.
This was not about knowing every system before the work started. We did not. It was about being able to learn the environment quickly enough that the client did not have to create a separate process around the external team.
Working inside Envoy also changed the scale of the problems the team had to reason about.
A change to one service could affect other services. More stakeholders were involved in system decisions. Release discipline mattered because more people and products depended on the same infrastructure.
That is worth keeping because it makes the learning reciprocal. The story is not that Amplified arrived with every answer. OfficeTogether taught us how quickly a product can move when the team is small and the deadline is immediate. Envoy taught us what changes when that same engineering work enters a larger system.
The 2022 engagement should stay a 2022 story. Today, Envoy describes resource booking as one connected way to reserve desks, rooms, and parking, with booking data feeding broader workplace operations and analytics. That current positioning gives readers the product context without implying that Amplified built or owns Envoy’s present-day platform.
The first problem in this story was speed: four weeks, early wireframes, and a product that needed to become demonstrable.
The later problem was almost the opposite: a mature platform, existing customers, multiple services, established engineering standards, and infrastructure that could change underneath the experience only if the experience itself stayed dependable.
Those two environments required different engineering behavior. But they relied on the same underlying model: join the team that exists, learn how it works, take ownership of a defined problem, and avoid making the client reorganize around you.
That is why the transition from OfficeTogether to Envoy matters more to us than the individual technologies involved. React became Kotlin. Node.js gave way to other services. A startup became part of a much larger organization. The engineering relationship still had to work.
OfficeTogether began with a four-week deadline and a question: Can you build something real quickly enough?
By the time the engagement continued inside Envoy, the question was different: Can you change something substantial without disrupting what is already working?
Those are two very different tests of a product engineering team.
The through-line was not a technology stack. It was the ability to enter the environment in front of us, understand what mattered, adapt to its constraints, and leave the part of the system we touched stronger and easier for the client’s own team to carry forward.
That is still how we think about embedded engineering work.
