Skip to main content
A person working remotely at a desk
#Studio

Remote Work Changed Our Studio — Here Is What We Learned

After three years of distributed work, we have opinions. This is what worked, what failed, and how remote reshaped the way Kotito builds digital products.

When the world went remote in 2020, we treated it like a temporary disruption. Three years later, Kotito is a fully distributed studio and we have no plans to change that. But the path here was not as smooth as the LinkedIn posts would have you believe.

The tools that actually matter

We tried every collaboration tool on the market. Here is what survived:

Linear for project management. It is fast, opinionated, and does not let you turn project tracking into a second job. We tried Notion, Asana, and Jira. Linear won because it respects the developer workflow.

Figma for design. Obvious choice, but the real value is that everyone — developers, designers, clients — can comment in the same place. No more screenshot ping-pong over email.

GitHub for code and documentation. Pull requests are our code review process. Discussions are our technical decision log. We stopped using Confluence and never looked back.

Loom for async communication. A three-minute video replaces a thirty-minute meeting. We record walkthroughs for code reviews, design feedback, and client updates. The recipient watches on their schedule at 1.5x speed.

What failed

Daily standups over video call. They became status reports that nobody listened to. We replaced them with a written daily check-in: three bullets in Slack by 10am. What you did yesterday, what you are doing today, anything blocked. Takes two minutes to write, thirty seconds to read.

Open-ended Slack channels. Without structure, Slack becomes a firehose of noise. We moved to a strict channel-per-project model with a 24-hour response expectation for non-urgent messages. Urgent issues go to a dedicated channel with notifications on.

The hybrid trap

For a while we tried hybrid — some people in an office, some remote. It was the worst of both worlds. In-office people had side conversations that remote people missed. Decisions happened in hallways. Remote team members became second-class citizens without anyone intending it.

We committed to remote-first or office-first, not both. For us, remote-first won because it expanded our hiring pool to the entire continent.

The boundary problem

Remote work blurs the line between working and not working. In an office, you leave at the end of the day. At home, the laptop is always right there.

We enforce boundaries through culture, not software. No messages expected after 6pm. No weekend work unless something is genuinely on fire. Calendar blocks for deep work are respected — if someone has focus time blocked, you do not schedule over it.

Written communication is a skill

In a remote studio, writing is the primary interface between people. Bad writing causes misunderstandings, delays, and frustration.

We hire for communication skills as seriously as we hire for technical skills. Every job posting asks for a writing sample. Every code review evaluates the clarity of the PR description as much as the code itself.

Being remote made us better communicators. That alone was worth the transition.