The person behind the shipped work.
I build web, mobile, and AI products that ship. Previously full time at DI Solutions in Surat (August 2023 to August 2026). Now freelancing and open to full-time roles, building for clients across the US, Taiwan, and India.
Mayur Nakum
AI Software Engineer
Surat, Gujarat, India
Introduction
I build web and mobile products, mostly in React, Next.js and React Native. I spent three years full time at DI Solutions in Surat (August 2023 to August 2026), and I am now freelancing while looking for full-time roles and freelance work. Ten of the things I have worked on are in production right now, across five platforms and clients in three countries.
I got here the long way: interfaces first, then the problems underneath them. A screen that had to stay responsive on cheap Android hardware taught me more about rendering than any tutorial did. A calendar that had to agree with Google, Apple and Microsoft at the same time taught me that most hard frontend problems are actually data problems wearing a UI costume.
What I am doing now is the part I find most interesting: making products usable by AI systems, not just bolting a chat box onto them. On ByDesign that meant designing Model Context Protocol tools with schemas tight enough that a model picks the right one without guessing. Turns out that is as much a product design problem as an engineering one.
Engineering philosophy
The habits that decide architecture before a line of code exists.
I scope by what breaks first
Before writing anything I look for the constraint that will decide the architecture: a payment flow that cannot double-charge, a widget that cannot call an API, a sync that cannot duplicate. Build around that, and the rest of the decisions get easier. Guess at it, and you rewrite.
Ship the thin version, then deepen it
I would rather have a narrow feature in production this sprint than a complete one in review next month. Real usage tells you which half of the plan was wrong, and it tells you cheaply.
One source of truth, always
Most bugs I have chased were the same fact written down twice and allowed to drift. I put shared data in one place and read from it everywhere, even when duplicating it would be faster today.
How I got here
Not a ladder of job titles. The problems that changed how I work.
Interfaces first
I got here the long way: interfaces first, then the problems underneath them. A screen that had to stay responsive on cheap Android hardware taught me more about rendering than any tutorial did.
Data in costume
A calendar that had to agree with Google, Apple and Microsoft at the same time taught me that most hard frontend problems are actually data problems wearing a UI costume.
Products that AI can use
What I am doing now is the part I find most interesting: making products usable by AI systems, not just bolting a chat box onto them. On ByDesign that meant designing Model Context Protocol tools with schemas tight enough that a model picks the right one without guessing. Turns out that is as much a product design problem as an engineering one.
Experience
AI Software Engineer
Freelance · Surat, Gujarat · Remote
Freelancing after three years at DI Solutions. Open to full-time roles and freelance product work across web, mobile, and AI.
AI Software Engineer
DI Solutions · Surat, Gujarat
Built and shipped web and mobile apps with React, Next.js and React Native, working with designers, backend developers and clients from brief through release.
Production Apps
Built and maintained apps that real businesses run day to day.
Cross-Platform Development
Shipped Android and iOS apps with React Native and Expo.
Modern Frontend
Built interfaces with React, Next.js, TypeScript and Tailwind CSS.
AI Integration
Wired AI features, APIs and automation into products already in use.
Technical strengths
What I ship for teams. Open the archive to see it live.
- AI Engineering
LLM features, agent tooling and MCP workflows wired into products that already ship.
- Frontend Engineering
Fast, accessible interfaces with React and Next.js that stay maintainable as the product grows.
- Mobile Development
Android and iOS apps from one React Native codebase, with native work where the platform requires it.
- Backend & Cloud
Auth, APIs and cloud pieces that keep the frontend honest in production.
How I approach building products
Constraints, honesty, and where native work actually belongs.
I ask clients about their worst day, not their best
Demos are easy. What matters is the restaurant at 7pm on a Friday, or the event check-in on bad hotel wifi. I ask about those early because they set the performance budget, and they are the requirements nobody writes down.
Native where the platform demands it, shared everywhere else
Cross-platform is a means, not a principle. Widgets, notifications and calendar permissions are genuinely native work. I draw that line on purpose instead of fighting an abstraction that was never going to hold.
I say what I do not know
If I have not measured something, I do not claim it. That applies to estimates, to performance numbers, and to what I personally built versus what a teammate did.
Beyond code
I live and work in Surat, Gujarat. Outside of building things, I am the person who reads the changelog of an app I use daily and has opinions about it. I work with clients across the US, Taiwan and India, so my week has an odd shape and a lot of timezone maths. That habit has quietly made me better at building software that respects other people's clocks.
Based in Surat, Gujarat, India. Remote across timezones.
Current focus
MCP server design and agent tool architecture, especially how tool granularity affects model accuracy
Server components and streaming SSR, and where they actually beat a client-rendered app
Measuring instead of guessing: Core Web Vitals, real-device profiling, and treating LCP as a budget, not a vanity score
As of August 2026
See what this looks like in production.
The archive is the evidence. If you want to talk about a product, a role, or a hard constraint, start there or get in touch.