Hire me
One developer, and you talk to him.
No account manager in between. The person writing the code is the person on the call, and if the answer to your question is that I am the wrong person for it, you get that answer on the call rather than three invoices later.
Available for new workTaking projects and retainers from this month
How engagements are shaped
Fixed-price project
A scoped piece of work, quoted after discovery and billed against milestones. Best when you know what you want built.
New apps, MVPs, upgrades, a bounded feature.
Monthly retainer
An agreed number of days each month, billed in advance. Best when the work is continuous and the priorities move.
Maintenance, store releases, a product still finding shape.
Consulting and audit
A fixed number of days ending in a written document. Best when you need an answer rather than a developer.
Code audits, upgrade feasibility, second opinions.
Inside your team
A day rate, your process, your standups, your repository. Best when you have a team and need one more senior pair of hands.
Feature work, native modules, performance sprints.
I do not publish a rate card, because a number without a scope is a number I would have to revise. What I will do is quote before starting, in writing, and not move it unless you change what you asked for.
What you might be hiring for
Hire a React Native developer
Five years, six apps live on both stores, a published Turbo Module, and every codebase TypeScript from the first commit.
Read moreHire a mobile app developer
One person who takes an idea to an app on both stores, including the native layer and the release.
Read moreHire an Expo developer
Managed or bare, EAS Build and EAS Update configured in your organisation, config plugins written where an SDK has none.
Read moreHire a full stack developer
Mobile, web and API held by one person, so the contract between them stops being a negotiation.
Read moreHire a React Native consultant
A fixed-price audit of a codebase, an architecture review, or a second opinion you can hand to someone else.
Read more
The practical answers
- Based in
- Ahmedabad, Gujarat, India
- Working hours
- IST, with a daily overlap with Europe and an early window with the US east coast
- Who owns the work
- You do. Your repository, your developer accounts, your signing keys
- Languages
- English, Hindi, Gujarati
How it runs
Four steps, and you can see the work at every one.
- 01
Discovery
A paid, short, bounded piece of work: I read what exists, ask the questions that change the estimate, and write down what the first version actually is. It ends in a document and a fixed price, and you own both whether or not we continue.
- 02
Plan
Scope split into milestones you can recognise from the outside, with the risky items first rather than last. If something is going to be a problem, I would rather find it in week two than week nine.
- 03
Build
A build in your hands every week or two, not a reveal at the end. Work happens in your repository, in reviewable commits, with types and CI from the first one rather than added once it hurts.
- 04
Launch and after
Store submission, phased rollout and the review replies. Then either handover with documentation and a pipeline you can run, or a monthly retainer. The handover is designed for either outcome.
Looking to learn this rather than buy it?
A multi-skill learning platform I built and teach on: structured tracks rather than a playlist, project critique rather than a quiz, and practitioners teaching the work they actually do. The React Native track is mine.
vmacademy.dev