Work with me
One person, from an empty repo to both app stores.
Most people you can hire do one layer. I have spent four years doing all of them, because at a services company nobody was going to do the other ones for me. App, API, database, infrastructure, the release, and the phone call when it breaks at eleven at night.
- Mobile
37
Flutter apps shipped
- Backend
4 yrs
Node across a portfolio
- Stores
3
Play, App Store, macOS
- Clouds
2
AWS and Azure in production
What I take on
Any one of these on its own, or all of them as one product. The last one is the reason the others are worth reading.
- 01
Mobile apps
37 Flutter appsFlutter, one codebase, both stores.
Built and shipped across a large portfolio of apps on a consistent toolchain. GetX for state, Dio for the API layer, Firebase for auth, push and crash reporting. I also handle the part most people underestimate: the store accounts, the signing certificates, and the review submission.
Stack
- Flutter
- Dart
- GetX
- Dio
- Firebase
- Play Console
- App Store Connect
- 02
Web apps and sites
This site, built and documentedNext.js and React, fast by default.
Customer-facing sites, admin dashboards and internal tools. Server rendering where it earns its keep, static where it does not. I care about what the page weighs and what it costs to load, because that is usually the difference between a site people use and one they close.
Stack
- Next.js
- React
- TypeScript
- Tailwind
- CloudFront
- 03
Backend and APIs
Node backends across a four year portfolioNode.js, and the boring parts done properly.
REST APIs, realtime over Socket.io, background jobs off the request path, and schema design that holds up when the table is not small any more. Auth, rate limiting and role based access applied from the start rather than added after an incident.
Stack
- Node.js
- Express
- NestJS
- PostgreSQL
- MySQL
- Redis
- Socket.io
- Elasticsearch
- 04
Infrastructure and delivery
EKS at millions of requests a dayThe part that decides whether any of it stays up.
AWS and Azure, Docker, Kubernetes where it is genuinely needed and a single box where it is not. CI/CD so a release is a commit rather than an evening. Monitoring tuned so an alert means somebody has to act, and backups you have actually restored.
Stack
- AWS
- Azure
- Docker
- Kubernetes
- Terraform
- Jenkins
- ArgoCD
- Nginx
- 05
A whole product, from zero
Anonymous India, 4 codebases, 1 personIdea to live, without assembling a team.
App, API, database, admin console, infrastructure and both store releases, by one person. I have done exactly this for my own product, so this is not a theory about what a small team could manage. It is what I already run.
Stack
- Product
- Architecture
- Delivery
- Release
- Operations
Three ways to work
Tell me which one sounds like your situation and I will tell you honestly whether it is the right one.
Build it
Fixed scope, fixed date
A defined piece of work with a written scope and a delivery date. Good for an app, an API, a rebuild, or a migration with a clear finish line.
Right ifYou know what you need built
Run it
Monthly retainer
Infrastructure, deploys, monitoring, backups and being the person who answers when it breaks. Priced per environment, per month, so you know the number.
Right ifIt is live and nobody owns it
Look at it
Fixed fee, one week
A written assessment of what you are running: what will break, what it is costing you, and what to fix in what order. You keep the document whether or not you hire me after.
Right ifSomething feels wrong and nobody can say what
Why one person
What an agency cannot give you.
The person who writes it is the person who gets paged
No handoff between a build team and an ops team, because there is no handoff. That gap is where most of the expensive problems live.
No account manager in between
You talk to me. Not to someone who then explains your problem to me, badly, two days later.
I will talk you out of things
Most products asking for Kubernetes do not need Kubernetes. I would rather build the smaller correct thing and keep the relationship than take the bigger invoice.
You get a runbook, not a dependency
Every engagement ends with documentation your own team can act on. I have been the person a company could not replace. It is not a compliment and I will not do it to you.
Your name never leaves my mouth
Look at my work page. Four years of client platforms and not one of them is named. Yours would be treated the same.
What I will not do
Saying this before you ask saves us both a week.
- Brand identity or visual design from scratch. I will build faithfully to a design, but I am not the person to invent one.
- Staff augmentation where I am a body on somebody else's board with no say in the decisions.
- A fixed price on a scope nobody has written down yet. That ends badly for both of us. Pay me for a week to define it instead.
- Anything I cannot test. If there is no way to verify it works, I will say so before we start, not after.
How a project actually runs
- 01
A call, and an honest answer
Tell me what is broken or what you want built. I will tell you what I think is actually needed, which is often less than you asked for. If it is not something I should do, I will say that too.
- 02
Scope in writing, before money
What is included, what is not, what it costs and when it lands. If we cannot write it down clearly, we are not ready to start.
- 03
You see it running every week
Not a demo at the end. Something deployed you can open, from the first week, so nobody is surprised in month three.
- 04
Handover, not hostage
Access, documentation and a runbook, whether or not you keep me on afterwards. You should be able to hire someone else and have them understand it in a day.
Tell me what you are trying to build.
Or what is already built and giving you trouble. A first call costs nothing and I will tell you plainly whether I am the right person, including when the answer is no.
Looking to hire someone full time instead? That page is here.