01
Build
Understand the business problem, design the solution, then write the product or stand up the infrastructure myself. No handoff in the middle.
01 — What I do
One engineer who owns the whole system, not a slice of it.
Most engineers own a slice — the front end, or the API, or the infrastructure. I take the whole problem: design it, build it, deploy it, run it, and fix it when it breaks. There is nobody to hand it to.
What you hear when nobody owns it
- 01Frontend“The API is slow, not us”
- 02Backend“It works on my machine”
- 03Data“That query has always been like that”
- 04Commerce“The platform will not let us”
- 05Integrations“That is the vendor’s SDK”
- 06DevOps“Nobody touches the deploy”
- 07Infrastructure“That is the host’s problem”
Seven layers, one owner
Based
India, working remote
Since
2017
Stack
Shopify · Node · AWS · React
02 — How
02
Run
Deploy it and operate it. Debugging goes from DNS through the network, the server, the container and the application into the database.
03
Optimise
Measure what it actually costs — in load time, in server bills, in hours lost to manual work — fix that, and measure again.
Someone else’s word for it
03 — Proof
He found the actual cause in two days, after we had spent a month guessing at it. The fix was smaller than anything we had proposed.
The handover was the part that surprised me. Everything documented, nothing locked to him, and the deploy still runs without anyone touching it.
Worked with
- [LOGO]
- [LOGO]
- [LOGO]
- [LOGO]
- [LOGO]
Selected work
04 — Four, in full
RemoveQ
Image optimisation and delivery: transform on request, serve from the edge, cut the bytes without visibly cutting quality.
ImgProxy and libvips behind a CDN, with signed URLs, real-time transformations and several upstream image sources. The point of it is bandwidth — most sites ship images several times larger than the layout ever needs, and that cost lands on the visitor rather than the developer.
Live, still rough around the edges — no public link yet.
Shopify pricing and fulfilment
Discount logic complicated enough that the platform's own limits become the engineering problem.
Quantity breaks, Mix & Match, Power Buy, end-of-line sales, variable case sizes, pre-orders and inventory conditions — through Shopify Functions, metafields and cart attributes, across several stores and Markets. Functions have a hard complexity ceiling; hitting it meant restructuring the logic and cutting GraphQL and metafield reads, not asking for a bigger budget.
Production performance work
One of four things I do, not the whole job — finding the cause that costs money, not the one that is easiest to fix.
The whole path gets measured before anything changes: browser, CDN, server, application, database, third-party scripts, infrastructure. Then the specific fix — JavaScript execution, request count, cache headers, image delivery, API shape, render path — and a second measurement to prove it moved.
Infrastructure and automation
Servers owned the whole way down, and the repetitive work automated out of existence.
EC2, S3, CloudFront and Route 53, with Docker, Nginx and Redis on Linux, deployed by GitHub Actions. Troubleshooting runs from DNS through the network, the server, the container and the application into the database. Anything done twice by hand becomes a pipeline.
How the work goes
05 — Seven steps, then again
01
Understand the requirement
What does this cost you today, and what is fixing it worth?
02
Find the real cause
Measure the whole path. It is rarely where people assume it is.
03
Pick the simplest fix
Practical engineering over complexity. Boring is a feature.
04
Build it
Product code or infrastructure, whichever the problem needs.
05
Measure the result
Same instrument, same conditions, before and after.
06
Improve it if it pays
Stop when the next hour buys less than it costs.
07
Automate the repeat
Work done twice by hand becomes a pipeline or a scheduled job.
And back to 01
It is a loop, not a checklist. Most of the value is in going round again.
What I build it with
06 — Supporting evidence
Shopify
- Functions
- Liquid
- Admin API
- Storefront API
- Markets
- Metafields
- Cart attributes
- Custom apps
- Discounts
- Pre-orders
Also commerce
- WMS / SmartPack
- WordPress
- WooCommerce
Application
- Node.js
- TypeScript
- React
- Next.js
- Astro
- PHP
- Laravel
- REST
- GraphQL
Data
- MySQL
- MariaDB
- PostgreSQL
- MongoDB
- Redis
- Prisma
Infrastructure
- AWS
- EC2
- S3
- CloudFront
- Route 53
- Docker
- Nginx
- Linux
- Bash
Delivery
- GitHub Actions
- CI/CD
- ImgProxy
- libvips
- BunnyCDN
- Supabase
Questions you should ask
07 — Including the awkward ones
01
Can one person really cover all of it?
For a system of the size that hires one engineer, yes — that is the whole point. For something that genuinely needs a team of six, no, and I will tell you that on the call rather than three months in.
02
What happens if you disappear?
You keep everything: the repository, the infrastructure accounts, the runbook, the deploy pipeline. Nothing runs on a service only I can log into, and nothing is written in a way only I can read. Being replaceable is part of the job.
03
How do you charge?
Three ways, depending on the work. A day rate for open-ended work, from $450. A fixed price when the scope genuinely is fixed. A monthly retainer if you want someone on call for the whole system rather than one project.
04
Can you work with the team we already have?
Usually the most useful arrangement. I take the layers nobody currently owns, and hand back anything your team would rather keep. The point is that no layer is left unowned, not that I own all of them.
05
What if the problem is not what we think it is?
That is the normal outcome, and finding out is most of the value. I measure before changing anything, and if the real cause is somewhere you were not looking, you get told that — including when the honest answer is that it is not worth fixing.
06
How soon can you start?
Usually a week or two out. I take one new project at a time, so if the timing does not line up I will say so on the call rather than stringing it along.
08 — Start here
Tell me what is not built, not working, or nobody owns.
A short call is usually enough to tell whether I am the right person for it. If I am not, I will say so and point you at what I would do instead.
- 01You describe what is not built, not working, or nobody owns.
- 02I tell you where I think the problem actually is, and what I would check first.
- 03If I am the right person for it, we talk scope. If I am not, I say so.
Book a call
No pitch, and no obligation on either side.
- me@naveenrao.com
- Timezone
- IST · UTC+5:30
- Reply within
- One working day