KaptiMethod
From sketch to code: the tools we actually use, and why
We’re often asked “what do you work with?” The honest answer: whatever the client’s team can maintain after we leave. But from one engagement to the next, certain tools keep coming back, because they shorten the distance between the mockup and the shipped product. Here they are, step by step.
A tool doesn’t make a good product. But a poor chain of tools damages many: a mockup redrawn in code, a component that exists three times under three names, an AI demo nobody can reproduce. Our choices all follow the same idea: design, code and AI should speak the same language, from the first interview to the production release.
Understand: research before screens
The first tools of an engagement are the simplest: an interview guide, a recorder, a shared board. We interview users and business teams, observe in the field when possible, and organise what we learn into a synthesis everyone can review.
AI saves us time here, with a clear limit: it helps transcribe and cluster, it doesn’t decide what matters. Every quote that ends up in the synthesis has been reviewed by the person who conducted the interview.
Design: Figma, and decisions in writing
We design in Figma, because that’s where most product teams work and it lets us comment on a screen with the client instead of swapping screenshots. Three habits matter more than the tool itself:
- Components from the very first screen. Even for a two-week mockup, every button and every field is a component. That’s what lets us move to code later without redrawing everything.
- Design tokens. Colours, typography, spacing and radii are named once (“secondary text”, “surface”, “accent”) and reused everywhere. This site’s dark mode, for example, is just a second set of values for the same names.
- The states people forget. Loading, error, empty list, an uncertain AI response: every key screen is designed in those states, not just the ideal case.
Test: a prototype that actually works
For an AI feature, a static mockup lies: it shows a perfect answer every time. So we test with a working version, connected to a real model and realistic data, that five to seven users get hands-on with. The demos in our internal projects are built this way: code running in the browser, with demo data.
Build: React, documented components, and Webflow when it makes sense
On the product side, we mostly build in React (and React Native for mobile), sometimes Angular when that’s the client’s existing codebase. On the server side, we adapt to the context: Java in established information systems, Node and PostgreSQL for newer products, such as Swing, the extension born from our hackathon.
Design and code are connected through Storybook : every component is documented there with its variants, states and accessibility rules. Designers and developers look at the same catalog, and the client’s team knows where to look once we’ve left.
For a marketing site the marketing team has to run on its own, we prefer Webflow : that’s what we delivered to Moofize, whose team edits its pages without a developer.
Integrate AI: the right model for the problem
We don’t pick a model out of habit. Depending on the need:
- A language model to summarize, classify or draft.
- A search across your documents (RAG) when the answer must come from your sources and cite them: product sheets, contracts, internal documentation.
- A vision model to check a photo or read a scanned document.
The final choice depends on three constraints we set during scoping: where the data is allowed to go (hosting, confidentiality), how much each call costs at scale, and what happens when the model gets it wrong. The third question is as much about design as it is about engineering.
How we stay current. Models, tools and regulations change every quarter. We test them continuously on our internal projects, and write up what we learn on this blog, like our reading of Article 50 of the AI Act.
Verify: accessibility tested by hand
Automated tools catch some accessibility issues, not all of them. We complement them with keyboard testing, screen reader testing (VoiceOver, TalkBack, NVDA) and 200% zoom, then an RGAA checklist when the client needs to publish an accessibility statement.
Hand over: what remains after the engagement
The real test of a stack is the day the client’s team takes over. So we leave a tidy Figma file, tokens shared between design and code, an up-to-date Storybook and short documentation explaining the choices. If the team doesn’t need to call us back to add a screen, the engagement was a success.
Frequently asked questions
Do you impose your own tools?
No. We start from what your team can maintain. If you’re on Angular or another platform, we work within it.
Which AI model do you use?
The one that fits the use case and your confidentiality, cost and hosting constraints. We justify it in writing during scoping.
Is the design system delivered in code?
Yes, when the engagement includes it: React components documented in Storybook, using the same tokens as the Figma library.