How I work

Principles.
Then the build.

I am Vishu Pratap. Clients hire me to ship a product they can run, not to rent a stack they cannot leave. Here is how that actually works: what I optimize for, how an engagement runs, and what I will not do.

PrincipleIn practice
01

Own the system

I would rather build you a kiosk, admin, website, and rider app you control than leave you on a vendor subscription. SVSFood left Uengage for that reason and generated ₹40L+ in month one on devices they own. Same idea for Jara and Lufasi: no per-booking OTA tax if we can avoid it.

02

Cross-platform on purpose

React Native is how I ship iOS, Android, tablets, and rider apps from one TypeScript codebase. Shared types with Next.js cut rewrite work. A mobile MVP is usually 4 to 8 weeks, not two native teams. I go native when the product is the platform. I do not go native to look more serious.

03

One engineer, one stack

Most of my clients do not have a twenty-person mobile department. The person who designs the Postgres schema should be able to ship the phone UI. That is how 38+ products and 10+ apps left this desk without a handoff tax.

04

Two months is the ceiling

A focused MVP is 4 to 6 weeks. A larger platform is 8 weeks. If it needs more than that, we cut scope or we write a second engagement. Open-ended retainers that quietly become a year are how products rot.

05

Postgres for money and inventory

Orders, rooms, riders, coupons, and portfolios are relational. Foreign keys and transactions keep a kiosk sale and an admin stock change consistent. I will not put that in a document store and re-implement joins in application code.

06

Infrastructure a solo operator can run

APIs go in Docker images on Cloud Run. Data lives on Supabase or Cloud SQL. Files live on Cloud Storage. I do not stand up Kubernetes for a single service. If I am the one on-call at dinner rush, the system has to be boring.

07

Build for the market, not the template

JobBissau talks to candidates on WhatsApp because that is the inbox in Guinea-Bissau. Ezlearn shipped in Hindi at a price Indian learners would pay. TitanTech needed a CRM that models mandates, not generic leads. I copy the constraint, not a SaaS landing page.

08

Ship, document, hand over

You should be able to run what I built after I leave. Ezlearn went out with docs and a stable production handoff. Secrets live in Secret Manager, not in a Slack thread. The repo should explain itself.

Mobile strategy

I choose React Native on purpose - for speed and cost, not as a substitute for native.

Cross-platform is a strategic choice. One TypeScript codebase ships iOS, Android, tablet kiosks, and rider apps. Shared types with Next.js backends cut rewrite work. A focused mobile MVP is usually 4–8 weeks instead of two parallel native projects. The lack of separate Swift and Kotlin repos on this site is intentional - it is how a solo product engineer launches 10+ mobile apps without a two-platform department.

SharpOrders (shipper + driver, live on the iOS App Store) and SVSFood (self-ordering kiosk + Android rider) both shipped from React Native with Expo. GPS, camera, offline queues, and maps use native device APIs. I would choose Swift or Kotlin for games, custom BLE, or OS-level products - not for logistics, food-tech, or SaaS companions.

Full argument: Why I choose React Native.

Engagement

What working together looks like

01

Scope

We write what ships, what does not, and the milestone dates. No mystery backlog. If it is not on the page, it is a later engagement.

02

Build

You get working software on a cadence, not a big reveal at week eight. Async updates. Questions answered in writing so decisions survive the chat.

03

Ship

Production: domain, payments, the real database, the real store listing. Staging-only demos are not delivery.

04

Handoff

Access, docs, and a system one operator can keep alive. Then I am available for a follow-on if you want one, not because the first build never finished.

Defaults

What I reach for first

Web
Next.js and TypeScript. Vercel when the surface is a site or dashboard.
Mobile
React Native and Expo. Why.
API
Fastify or Node, Docker, Google Cloud Run.
Data
PostgreSQL with Prisma. Supabase or Cloud SQL.
Systems
Rust when the problem is a protocol or a hot path. See VSTP.

Limits

What I will not do

  • Stand up Kubernetes for one API.
  • Build two native apps by default so the portfolio looks “more senior.”
  • Put the production database in the same container as the API.
  • Start a build without a written scope and an 8-week ceiling.
  • Leave secrets in git or treat staging as the finish line.

Proof is in the case studies and the writing. If this matches how you want to build, get in touch.

Questions clients actually ask

What is it like to work with Vishu Pratap?

You get one owner for the product: scope, architecture, build, deploy, and handoff. Updates are async and milestone-based. A focused build is 4 to 8 weeks. Nothing runs longer than 2 months without a new, written scope.

Does Vishu Pratap write native iOS and Android apps?

He ships iOS and Android from React Native on purpose, for speed and cost. SharpOrders and SVSFood went to production that way. He chooses Swift or Kotlin when the product is the platform: games, custom BLE, OS-level work. Missing native-only repos are a strategy, not a gap.

How does Vishu Pratap pick a stack?

Next.js for web, React Native for mobile, TypeScript everywhere, PostgreSQL for anything with money or inventory, Docker on Google Cloud Run for APIs, Supabase or Cloud SQL for the database. The stack is boring so one person can operate it after launch.

Will Vishu join an existing codebase?

Yes. He regularly steps into existing Next.js, React Native, Node, ASP.NET, or Rust code to fix, extend, or take architecture. New work is still scoped to 8 weeks or less.

Links

© LINKS °

Let's build together. Waiting to connect.

©2025Vishu Pratap · Software Developer