Full-stack web and mobile development

Next.js and React on the web, Expo and React Native on mobile, TypeScript throughout, Postgres behind typed APIs. Stripe for payments, and whichever auth the product actually needs rather than whichever is fashionable.

Deployment on Vercel or Railway with the pipeline set up as part of the build, because a product that cannot be deployed by someone other than its author is not finished.

It means the parts nobody demos: the migration path, the error states, what happens when the payment provider times out halfway, and the admin surface somebody has to use on a Tuesday.

Four products are live and running on this basis — a beauty marketplace in Nepal, a home-care marketplace in Ontario, a matchmaking platform in Kathmandu, and a single-chair barbershop in Sudbury. They are on this site under Work, with what each one actually involved and what it cost to get wrong.

Most of this work is not greenfield. Taking over a codebase starts with reading it and writing down what it does, which is usually the first time anyone has.

Where a rewrite is genuinely the right answer we will say so, and where it is not — which is more often — we will say that instead.

Two of the four live products are Expo apps, which is why this reads as a React Native development studio in Kathmandu rather than a web shop that also does mobile. The difference shows up in the parts that are specific to shipping on a phone: the App Store review round trip, over-the-air updates, permission states, camera and location, and what the app does on a three-year-old Android on a bad connection.

Hiring an Expo and React Native developer usually starts as a build and turns into a release process, because the first submission is where a team finds out what it did not have — a signing setup only one person can run, no staged rollout, no way to ship a fix without another review cycle. We set that up as part of the build rather than discovering it at submission.

A founder looking to hire a full-stack developer for a startup MVP is buying an answer to a question, not a product. The job is to get the smallest honest version of the thing in front of real users fast enough that the answer still matters.

So: no multi-tenant architecture before the second tenant, no microservices, no admin panel that could have been a database client, no design system for four screens. What does go in from day one is auth, payments if money is involved, error reporting, and a deploy anybody on the team can run — because those are the four things that are miserable to retrofit and boring to add early.

The honest caveat: an MVP built this way is meant to be partly thrown away. If the plan is to scale the first version rather than learn from it, that is a different, slower and more expensive engagement, and it is better to say so before it starts.