One engineer, full-stack, no handoffs lost in translation.
I work on a simple idea: the person who designs the database should also understand the API on top of it, and the person building the frontend should know exactly what that API returns. No handoff gaps, no "that's not my part."
Seven years of shipping things that had to stay up.
Not an agency, not a rotating bench of contractors. One engineer who has spent seven years on systems where a bug means somebody loses money.
Most of my work has been on the unglamorous end of software: booking flows that take real payments, admin panels that operations teams live inside eight hours a day, and databases that were fast at launch and stopped being fast once real data arrived. That's shaped how I build. I care more about what happens on the day a system is under load than about how it demos.
Being full-stack matters here for a practical reason, not an ideological one. On a small team, most defects don't live inside one layer — they live in the gaps between them. A frontend that assumes the API returns something it doesn't. A query that's fine with a thousand rows and collapses at a million. When one person owns the schema, the API and the UI, those gaps mostly stop existing.
The trade-off is honest: a solo engineer is not the right choice for a twenty-person programme with parallel workstreams. It is a very good choice when you want one person accountable, direct access to whoever is actually writing the code, and no time lost explaining the same context to three different people.
Real systems, not a portfolio of mockups.
A multi-GDS travel platform
Live flight and hotel search across several GDS providers at once, with agent wallets, markup rules and refunds — the parts of travel software nobody demos because they are the hard parts.
An enterprise admin platform
A back-office system with Solr-backed search over a large catalogue, role-based access and the reporting an operations team needs to actually run a day.
Shopify apps and admin panels
Custom back-office tooling for stores that outgrew the default admin — the work that starts where themes and plugins stop.
The portfolio has the case studies in detail, including seven working demo dashboards you can click through on sample data rather than screenshots of them.
Most of my work is for clients I've never met in person.
I work remotely with businesses in the UAE, the US, the UK, Italy and the wider EU, and Australia. Here is what that actually looks like in practice, rather than a line about being "globally available".
Timezones, honestly
My normal working day is 10:00–19:00 India time. That gives a genuinely comfortable overlap with some places and a narrower one with others, and it is better to say so upfront:
- UAE & the GulfNear-total overlap — 08:30–17:30 your time
- UK4–5 hours daily — your morning is my afternoon
- Italy & central Europe5–6 hours daily — comfortable for standups
- US East CoastCalls in my evening: 19:30 IST covers your 09:00
- US West CoastWorkable but narrow — usually one scheduled call
For UAE clients this is effectively a shared working day. For the UK and Italy there is half a working day of live overlap, which is plenty for daily calls. For US clients I shift later rather than pretend the overlap is bigger than it is — your morning is my evening, and a fixed call slot works better than trying to be online at your hours all day.
Contracts, code and money
- Who owns the codeYou do — outright, on final payment
- Where it livesYour repo, your cloud account, from day one
- InvoicingUSD by default; AED, GBP or EUR on request
- EngagementFixed-scope per phase, or a monthly retainer
- Working languageEnglish, written and spoken
- ConfidentialityNDA signed before anything is shared
The thing most international clients actually worry about is not the code — it is being left with something they cannot maintain after the engagement ends. So the code lives in your repository from the first commit, deploys run in your own cloud account, and nothing depends on a service only I have the login to.
How projects are run
Every engagement starts with a scoping conversation, not a sales pitch. If a project isn't a good fit — wrong stack, unrealistic timeline, or outside what can be delivered well — that gets said upfront.
Work is done in visible stages: discovery, design, build, test, launch. You see progress at each stage, not just at the end.
Communication happens in plain language first, technical detail second — decisions get explained in terms of what they mean for the business, not just the code.
What I don't take on
Saying no to the wrong project is cheaper for both of us than discovering the mismatch in month two. I turn down work that needs a full team running in parallel, anything depending on a stack I don't genuinely know well, and "rescue this by Friday" jobs where the timeline guarantees the same problems come back.
If your project falls outside what I do well, I'll say so on the first call — see the services page for what's actually in scope.
At a glance
- Experience7+ years, full-stack
- Core stack.NET, React, SQL Server
- Also builds onShopify (apps, admin panels)
- Deploys toAzure, or your existing cloud
- Engagement typeFixed-scope or retainer
- Team structureSolo, front to back
- Works withUAE, US, UK, Italy & the EU, Australia
- Hours & billingTimezone overlap · billed in USD
- IndiaB-110, Ganesh Nagar 8 Vistar,
Niwaru Road, Jaipur, Rajasthan - UAEFlat 612, Lavista 6,
Dubai Silicon Oasis, Dubai - Phone (India)+91 6375403040
- Phone (UAE)+971 58 589 6299
Want to know if this is the right fit for your project?
A short scoping call, in your working hours, with the person who would actually build it. No pitch deck.