Design studios have always bought most of their tools. Sketch, then Figma, and whatever the latest plugin was. These products are built around the work a studio ships: making and reviewing interfaces, trying out interactions, keeping design systems coherent, and handing the work across to the people who will build it.

A studio's internal systems are more particular.

They carry project context from one conversation to the next, keep research from disappearing into folders, and preserve the reasoning behind standards from being reduced to “that’s how it’s always been done.” Much of this lives in a studio's habits, its documents and the heads of people who have been around long enough to remember how it all fits together.

At Canvs, we have always built around the edges of that problem. Years ago, when resizing something in Sketch could turn 16 pixels into 16.5, we spent a weekend writing a plugin that rounded everything back to whole numbers. Internal tooling has often looked like this: one sharply specific fix, made by the person who understood the irritation well enough to solve it.

Over the past few months, as working with agents has become a part of the studio’s everyday practice, internal tooling has become a more deliberate layer inside the studio.

We are building these tools from within the work so that much of the context comes along with them. They meet a Canvs project with its history and working rhythms already in view, which saves us the labor of explaining it all over again.

The work gets faster, of course, and we spend less time making the same decisions twice. Over time, the studio also retains more context across projects and turns what it learns into shared capability. Work that would once have required a product team of its own can now become a part of running a 30-person studio.

We wrote about the practice behind this in Going Agentic as a Studio. Here are the tools that have come out of it, and what they have begun to change about the way we work.

1. Omni: Building an in-house toolkit for the way we design

The first screens of a project carry decisions that will last much longer than they do. Color, type, elevation and tokens have to work together and meet accessibility standards from the start.

Arjun built Omni at Canvs for this part of the work. It began as an accessibility tool that could generate color palettes and type scales, add elevation, then tokenize the result directly in Figma.

The accessibility work goes further than a single contrast score. Color pairings can be examined across different color-vision conditions and WCAG standards in one place, with enough information for a designer to revise the system before it spreads across every component.

Omni has since grown into a suite of micro-tools, organized into larger buckets around different parts of studio practice. Design systems are one such bucket. Arjun is also building a mockup maker with real 3D devices and a shared resource library.

More buckets are being explored for generating and reviewing design work. The broader direction is to gather tools we repeatedly reach for across projects, with the studio’s own standards already built into them.

2. Prototyping in code

Figma click-throughs have long been the default way to present how a product should work. They can show a linked sequence of screens, while anything functional usually requires a development team and enough time for a separate build.

Code sometimes enters earlier, when we’re trying out box structures and working through an idea, but the design itself still happens in Figma. Once the screens are ready, we use a process we’ve spent time refining to reproduce them 1:1 in code.

Working in code changes what can be reviewed and how the work is presented:

• Edge cases appear as the team moves through the product, including states that separate screens can leave unexamined.

• Micro-interactions can be adjusted in context and saved as patterns for future projects.

• Clients can backtrack or choose another route during a presentation without somebody having to restart the flow. (In fact, several clients have asked how we achieved that level of finish in a prototype.)

After the review, a well-set-up prototype can become a starting point for development. Our developers or the client’s team can inspect and audit the AI-generated code, then carry a working version of the interface and its intended behavior into the build.

3. Running the studio without drowning in notifications

Running a distributed studio means information reaches us from a dozen directions at once. Figma comments, Slack threads, client email and project updates all arrive as notifications; Premankan built a system that sorts out which of them deserves attention.

• Every morning, a briefing lands in Premankan’s inbox with what occurred while he was offline. It is filtered and grouped by project, and carries enough context to show him what needs attention.

• A second 60-sec read that tells him whether the studio is moving as it should, arrives at the end of the day with what was resolved, what remains open and where the work is getting stuck.

This context-aware curation is what’s valuable. A comment on a shipped file drops out, while one on an active screen with a live client thread gets surfaced first.

Designers live in Figma, so the pipeline treats it as a first-class source.

• It pulls comments across every active project file, groups them by file and project, and tracks whether a thread is resolved, stale, or heating up.

• A client comment sitting unanswered for 24 hours gets flagged. A thread with multiple replies and no decision gets surfaced.

Premankan still opens Figma constantly, because that is the job. He just knows what he is looking for when he gets there.

Slack contributes summaries from active project channels (multiple participant threads, shared files), while email is narrowed to client-domain senders on threads tied to work in progress. A generic newsletter gets dropped while a conversation tied to a live sprint makes the morning briefing.

We still have standups, because talking to each other is most of the point. The difference is that they can begin with the problem, since the status is already in Premankan’s inbox by the time everyone sits down.

In his words, this is where agentic workflows are useful: “cutting the administrative tax that used to eat the hours we could’ve spent on judgment calls.”

4. Building a living research library

A studio that only executes goes stale quickly. We need to know what is moving in our field, what our clients’ competitors are shipping and where design and technology are heading, so we built a research pipeline that keeps looking whether someone remembers to start it or not.

Research jobs run independently, on a repeating cadence. Some scan broadly, across fintech UX or the week’s big publication design writing; others are narrower, following a particular competitor’s release and the response to it online. Everything they find drops into a shared pool.

Collection alone is worthless. The real work happens in synthesis.

Each new finding is placed against what we already hold. Supporting evidence strengthens an existing thread, contradictions are flagged, and patterns across sources become subjects worth following.

Older material stays in play as the library grows. A report from six months ago can become useful again when this week’s competitive intelligence confirms what it predicted.

The material ends up in a tagged, sourced and interlinked knowledge base. When we are preparing for a pitch or briefing a designer on a new domain, we can query that history directly.

Ask “what are the onboarding trends in Indian fintech,” for instance, and the wiki draws from 18 months of research, giving greater weight to recent and reliable sources with citations attached.

The pipeline also learns what we actually care about. Subjects we query or carry into a brief receive more attention, while sources that repeatedly waste our time fall down the order.

Most studios research reactively, scrambling when a client asks a question or a competitor ships. Our pipeline collects and structures material in advance, leaving us enough time to interpret and decide. It gives a small studio the research depth to compete on strategy as much as execution.

5. HTML publish pipeline for a research library - needs headline (can combine with above?)

[Awaiting Depro]

6. Auth - needs headline

[Awaiting Rovin]

7. Finance tool - needs headline

[Awaiting Rovin]

8. Individual experiments within the studio

Alongside the systems being built for the studio, people at Canvs are developing smaller experiments around problems they encounter in their own work. The person making one already knows the awkward details, which gives the experiment a precise brief and somewhere real to be tested.

The results take different forms. Some become tools; others become tested approaches that a later project can pick up. Once shared, they give the rest of the studio a stronger place to begin when the same problem appears again.

While working on localisation for a fintech product, Akhil shared what the project had uncovered about Anek, its primary typeface. Designed by Ek Type, Anek is an open-source family with separate font files for 10 scripts, including Latin, Devanagari, Tamil, Telugu and Kannada.

That breadth makes it well suited to a product serving people across Indian languages. It also brings real differences into the interface. Each script has its own proportions, so a button or card centred in English can appear top-aligned in Devanagari. Translated strings also need different amounts of room.

Across the existing components, the work focused on two areas:

• The languages were grouped by the space their translations needed. Tamil, Telugu and Kannada placed the most pressure on cards, buttons and inputs.

• Line height and alignment were tested across scripts. When a Devanagari danda disappeared, it also exposed Figma’s habit of silently substituting a system font while continuing to label the layer “Anek.”

The existing screens could then support Indic text without being redesigned. A 1.4 line height gave the scripts enough room, while the most demanding languages became a useful test for new components.

For the studio, this brings localisation into the design-system conversation much earlier. Typeface, tokens and component behaviour can be considered together, while they are still easy to change. The next team working across Indian languages can begin with what this project taught us.

Hamsika has been working on two tools that support designers as their decisions travel through the rest of the work. One helps develop a screen into a fuller system; the other brings the studio’s handover conventions into Figma.

It is a growing suite of AI skills that works with whichever AI tool a designer already uses. The designer still decides what a component should be and when a variation deserves to stand on its own. The skill picks up from there.

It can suggest where to begin, break a screen into components, assemble a reference set in Figma, derive missing states and build related versions of an existing screen. Each step is proposed for approval, then built and checked. When the skill is unsure, it says so.

It draws on patterns from shipped design systems and can also retain the choices and reasoning particular to a project.

This deals with a smaller but familiar part of delivery. Canvs files follow a particular naming and numbering structure, which becomes laborious when a file contains 50 or 60 screens.

The Figma plugin numbers frames from their position on the canvas. Screens can be reordered without losing their step names, while repeated screens can be renamed together or carried across breakpoints.

Together, the two experiments make the decisions and conventions behind the work easier to carry from one screen, file and project to the next.

Small file jobs send us to browser tools all the time: merging a PDF, resizing an image, trimming a video or checking a block of JSON. Many of those tools begin by uploading the file, which makes them a poor fit for client material.

Himanshu wanted the same convenience with the processing kept on the machine. He built LocalKit, a browser-based collection of more than 50 utilities that requires no account or app installation.

It handles the things you usually open a one-off website for, from reorganizing PDFs and removing image metadata to converting video and formatting JSON. Every operation runs locally through WebAssembly, FFmpeg, PDF.js or the browser’s own APIs.

Once the site has loaded, the tools can work offline. A designer can compress a client PDF or remove metadata from an image without creating another copy somewhere outside the studio.