Types before tests
Most of the bugs a test suite would catch never get written if the types make the wrong state impossible to represent. TypeScript in strict mode is the cheapest quality tool available.
Software that survives contact with production.
I build web and mobile products end to end — React and Next.js on the front, Node.js and a properly designed database behind it, Flutter when it needs to be an app. Typed, tested against real use, and shipped.
- Idea
- Architecture
- Development
- Deployment
- Maintenance
I build the parts of a product that nobody sees — and the parts everyone judges.
I am a full-stack developer working across React, Next.js, TypeScript and Node.js, with Flutter for mobile and SQL and NoSQL databases underneath. I take a product from an interface sketch through the API and schema that make it work.
I got into software because I liked the feeling of turning a rough problem into something real that other people could use. That mindset stayed with me: I care about making products that are useful, dependable, and clear to maintain.
Most of my work sits in the JavaScript and TypeScript ecosystem: React and Next.js for interfaces, Node.js for the services behind them, and Tailwind or Bootstrap for the styling layer depending on what the project already uses. When something needs to be a real mobile app rather than a responsive site, I build it in Flutter.
I am equally interested in the layer underneath. Most product bugs turn out to be schema bugs wearing a costume, so I spend real time on the data model — in PostgreSQL and MySQL where the relationships matter, in MongoDB where the shape genuinely varies.
I work with AI tooling every day — Cursor and similar assistants are part of how I write and review code now. It makes the boring parts faster; it does not replace knowing why the code is shaped the way it is.
How a problem gets solved
- Understand what the feature is for before agreeing what it is.
- Model the data first — most product bugs are schema bugs in disguise.
- Build the interface against real API responses, not mock data that always succeeds.
- Write the failure path before the happy path.
- Test on a mid-range phone, not just the laptop it was built on.
Development philosophy
The schema is the product
Interfaces get redesigned; data models get migrated. I spend the time up front on relationships and constraints, because that is the decision that is expensive to change later.
Ship, then sharpen
Software earns its keep in production. I build the smallest honest version, put it in front of real usage, and let evidence drive the next iteration instead of opinion.
The tools, and what each one is actually for.
A stack is a set of trade-offs, not a trophy cabinet. Hover or focus any item to see where it earns its place.
Interface
Systems
Mobile
Data
AI-assisted
Tooling
A filled dot marks the tools reached for first.
What I can be hired to do.
Eight engagements, one operating model: understand the outcome, design the system, ship it, then keep it healthy.
Full products in Next.js and React — the interface, the API routes behind it, and the database underneath. Server-rendered where it helps performance and search, client-driven where it helps interaction, decided per route rather than by dogma.
- Next.js
- React
- TypeScript
- PostgreSQL
Typical deliverables
- Typed component system and design tokens
- Authentication and role-based access
- Responsive down to 320px, tested on real devices
A few things worth explaining properly.
Scroll to fly through them. Each plate opens a full case study — the problem, the architecture, the decisions that were wrong first.
OneStoryPlanetAuthentic personal stories, beyond the feed.
ACFN ATM FranchiseA full-stack franchise website and lead platform for North America's only ATM franchise.
NextLearnA multi-tenant LMS for coaching institutes.
Full-Stack Dating Platform: Web, Mobile & AdminA full-stack dating platform for web, iOS/Android and admin, with swipe matching, real-time chat, map-based discovery and paid subscriptions.
NearNestPost what you need. Find who can do it. Buy, sell, hire and connect locally.
AI is part of the toolchain, not the pitch.
It has changed how I write, refactor and review code — and not at all who is accountable for the result. Here is where it genuinely earns its place.
AI-assisted development
Cursor and similar assistants handle the parts of the job that are typing rather than thinking — scaffolding a component, wiring a form, converting a design into markup. Every generated line is read before it lands, because the person who merges it owns it.
How it runs
- Describe
- Generate
- Read
- Adjust
- Commit
Typical components
- Cursor
- TypeScript
- Git
Every item here describes how the work gets done, not a claim to have trained the models. The judgement about what to build, and whether the output is correct, stays with a person.
How the work actually runs.
Eight stages, in order. The early ones are cheap and decide most of the cost; the late ones are where everyone else starts.
Step 01: Discover
Understand the business outcome, the users, the constraints, and which deadline is real versus aspirational.
Outputs
- Problem statement
- Success metrics
- Constraint map
Step 02: Plan
Scope the smallest version that proves the thesis, then sequence everything else behind it. Cut before building, not after.
Outputs
- Scoped milestones
- Risk register
- Estimate range
Step 03: Architect
Decide the data model, the service boundaries and the failure modes. Most of the lifetime cost of a system is committed here.
Outputs
- Data model
- System diagram
- Decision records
Step 04: Design
Turn flows into interfaces — states, empty cases, errors and responsive behaviour, not just the happy-path screen.
Outputs
- Component inventory
- Interaction spec
- Design tokens
Step 05: Develop
Build in reviewable increments against a working trunk. Every branch deploys to a preview URL you can click.
Outputs
- Preview deploys
- Typed APIs
- Weekly demo
Step 06: Test
Automate the paths that would embarrass us in production, and manually probe the ones that are hard to describe to a machine.
Outputs
- Test suite in CI
- Accessibility pass
- Load profile
Step 07: Deploy
Ship behind flags, migrate forward-compatibly, watch the dashboards, and keep the rollback one command away.
Outputs
- Release pipeline
- Runbook
- Monitoring and alerts
Step 08: Scale
Let real usage set the priorities. Profile the slow thing, cache the hot thing, delete the thing nobody used.
Outputs
- Performance report
- Cost review
- Next-quarter roadmap
Where the practice came from.
Roles, what each one was actually responsible for, and the stack it ran on.
Full-timeLucknow, India
Full Stack Developer
Nextolive Technology
Working across product features, frontend delivery and backend logic, building dependable systems that support actual users and product workflows.
Responsibilities
- Developing and maintaining web interfaces and application flows from design to deployment.
- Working with product and engineering teams to turn product requirements into clear, shippable features.
- Building backend services and data-driven functionality that supports the product end to end.
Achievements
- Helped deliver product work that moved from idea to working implementation across multiple layers of the stack.
- Improved the reliability and clarity of application logic by working closely on frontend, backend and data concerns instead of treating them as separate problems.
Stack
- Next.js
- React
- TypeScript
- Node.js
- PostgreSQL
The difference is in how it is built, not how it is sold.
No headcounts, no invented percentages. These are commitments about method — the kind you can hold someone to.
Product-focused engineering
I ask what a feature is for before asking how to build it. You get pushback when the spec and the goal disagree — which is more often than anyone expects.
Clean architecture
Clear module boundaries and a data model that makes illegal states unrepresentable.
Built to scale
Designed for the traffic you expect and instrumented for the traffic you do not.
Modern tooling, used properly
AI assistants make the mechanical work faster. Every line still gets read before it lands, so you inherit code someone can actually maintain.
Web and mobile from one person
A Next.js front end and a Flutter app against the same API, without coordinating two contractors.
Transparent communication
Plain-language updates on a fixed cadence, in writing. You hear about slippage while it is still cheap to fix, not at the deadline.
Long-term support
Handover means documentation, runbooks and a maintenance window — not a zip file and silence.
Performance as a feature
Budgets set up front and enforced in CI, so it stays fast on the devices your users actually own.
Have an idea? Let's build it.
Tell me what you are trying to make and what done looks like. If it is not something I should take on, I will say so and point you somewhere better.
What happens next
- I read it myself — no assistant, no autoresponder.
- A reply within a couple of working days, including a straight answer if it is not a good fit.
- If it is, a short call to pressure-test the scope before anything is quoted.
Useful to include
- The outcome you need, not the feature list
- Any hard deadline, and what makes it hard
- What exists already — code, designs, users
- Who else is involved in the decision