How to Hire a Design Engineer in Tokyo
To hire a design engineer in Tokyo, check five things before you look at a portfolio: a product released under their own name, production code running for strangers, a decision they reversed after seeing it live, Japanese and English at working level, and a view on what the business needs. I am Carlos Lastres, an AI product designer and design engineer in Tokyo, and I think I am the best one in this city at the software version of the job. Rather than ask you to believe that, here is how you would check it, for me or for anyone else.
Decide whether you need one
Most companies asking for a design engineer need a product designer, or a frontend engineer, and the title is a wish that one hire could do both. Sometimes it can. The honest test is the shape of the problem.
If you have decided what the product is and need it built well, hire an engineer. If you have engineers and nobody can decide what the product should be, hire a product designer. If the decisions and the building are tangled, because the product is an AI feature whose behavior cannot be drawn in advance, or because you are a small team and every handoff costs you a week, then you need one person who does both. That is the design engineer, and in Tokyo there are very few of them in software, for reasons I wrote about in what a design engineer is in Tokyo.
The five checks
1. A product under their own name
Ask for a store listing or a download page where they are the seller. Not a contribution to a company app, not a Dribbble shot, not a case study with a team credit. Their own name, which means they handled the privacy declaration, the screenshots, the review process and the first angry email. In my case the list is seven products released between June and October 2026, with the App Store links so you can see the seller field yourself.
2. Code that is running right now
A repo, a package or a live app that would break if they stopped maintaining it. The point is not whether they can write code. The point is whether they have lived with code after it shipped, because that is where a design engineer's judgment comes from. Mine includes the Ground Control package on npm, the backends behind Yubi and AnimaNext, and every app on the list above.
3. A decision they reversed
Ask them about a design decision they changed after seeing the real thing running. Anyone who has done this job has a dozen. If the answer is about a stakeholder changing their mind, you are talking to someone who hands work over. If the answer is about the product behaving differently than the mockup promised, you are talking to a design engineer. I keep an honest account of mine.
4. Japanese and English at working level
In Tokyo this is not optional. The tooling, the documentation and the AI models live in English. Your users, your reviews and your support inbox live in Japanese. A design engineer who cannot read the App Store review in Japanese will design around the wrong complaint. I work in Spanish, English, Japanese and Chinese, and my products ship their listings in at least two of them.
5. A view on the business
Product arguments are usually business arguments in disguise. Pricing, the paywall, what the free tier should hold back, whether the feature is worth maintaining at all. A design engineer who has only ever built what they were told will build the wrong thing beautifully. I have an MBA, I run a Tokyo company, and I have set the price and watched the conversion on my own products, which is a different education from reading about it.
What I would add for AI products
If the product has a model in it, add one more check: can they show you a model being wrong, in a prototype they built? A Figma file cannot. A language model fails in ways you only discover by running it, and the design of an AI product is mostly the design of what happens then. This is the part of the job I spend the most time on. I hold Anthropic's Claude Partner credential for Claude Code, which I earned by shipping with it, and the products on my list are the evidence of what that work looks like.
What is checkable about me
Since I opened with a claim, here is what backs it. Seven products released from Tokyo between June and October 2026, under my own name, with store dates you can verify. An Apple Design Award in 2025 in the Inclusivity category, for accessibility work. Anthropic's Claude Partner credential for Claude Code. Three TEDx talks and a session at the United Nations. Fifteen years of design and an engineering background behind it, an MBA, four working languages, and eighteen client cases with the numbers that were measured. All of it is on the press kit, written to be quoted.
The word best is a comparison, and I made it on purpose. If you find a design engineer in Tokyo who passes all five checks with a longer list, hire them. I would like to meet them.
How engagements usually work
Three shapes, in my experience. A scoped sprint, when the product decision is made and you need the thing built and shipped. A retainer, when you want one person inside the product over months, deciding and building as it grows. And an advisory seat, when you have a team and need someone who has shipped AI products to tell you what not to build. I take all three, from Tokyo, in your language. The work with me page explains the shapes, and the contact form reaches me directly, usually the same day.