How to Build an App Like Netmeds: Developer Guide from Scratch

In this guide, I’m walking you through how I built an app like Netmeds from scratch — twice, actually. Once using JavaScript (Node.js + React) and again with PHP (Laravel). Why both? Because founders come to us at different stages — some want modern, real-time APIs and React interfaces; others prefer the tried-and-tested reliability of Laravel or even CodeIgniter for faster backend rollouts.

Whether you’re a founder, startup CTO, or agency product lead, my goal is to give you the real technical perspective — what decisions I made, what stacks I used where, how we approached scalability, and where ready-made clone kits (like Miracuves’ Netmeds Clone) come into play.

Let’s dive into how this app works and why it’s such a hot opportunity right now.

What Netmeds Does — and Why It’s Still a Massive Opportunity

Netmeds is essentially an online pharmacy and healthcare platform — think of it like the “Amazon of medicine” in India. Customers can:

• Browse and order prescription and OTC medicines
• Upload prescriptions for approval
• Schedule lab tests or consultations
• Track orders and get delivery updates
• Access health content and offers

And behind the scenes, there’s a full ecosystem: pharmacist verification workflows, delivery tracking, stock/inventory management, and secure payment processing.

Why it’s relevant in 2025:

• Health commerce is booming post-COVID
• Regulatory frameworks now support digital prescriptions and telemedicine
• Tier 2/3 cities are driving new user growth for these services
• VC-backed players still haven’t saturated the market — and niche clones (e.g., Ayurveda, pet meds) are popping up

If you’re planning to launch a Netmeds alternative or clone, you’re in a good spot — especially if you come in with solid tech and regional strategy.

Let me now walk you through how we built this — in both JavaScript and PHP stacks, and when each one makes sense.

Choosing the Right Tech Stack: JavaScript (Node.js + React) vs PHP (Laravel)

I always start with the business goals before deciding on the stack. Are we building a high-performance API for a mobile-first audience? Go with Node.js. Is the client’s team already familiar with PHP or looking for faster MVP delivery? Laravel works beautifully.

JavaScript Stack (Node.js + React)

Backend – Node.js + Express.js: I used Node.js with Express to build a modular, API-first backend. Every route was handled via controllers, and I structured the app using a service-repository pattern to keep business logic clean and reusable. JSON Web Tokens (JWT) were used for stateless authentication, and all APIs were RESTful to ensure mobile compatibility.
Frontend – React: React gave me full control over dynamic UI, and I used Redux Toolkit for managing the global state (like cart, user session, prescriptions, etc.). Axios was the HTTP client. We optimized for mobile-first design using Tailwind CSS and included PWA support for offline capabilities.
When to use: This stack is ideal when you’re building a high-performance, scalable, and API-centric app that might eventually need a mobile app, PWA, or even integration with third-party health devices.

PHP Stack (Laravel)

Backend – Laravel: With Laravel, I relied on built-in features like routing, Eloquent ORM, request validation, and Sanctum for authentication. Laravel Breeze got me started fast with auth scaffolding. For API-based clients (like React or Flutter apps), I served JSON endpoints using Laravel Resources.
Frontend – Blade or Livewire: If time-to-market mattered more than fancy interactions, Blade templating was sufficient. But for more reactive UIs, I sometimes brought in Livewire or integrated Vue.js directly.
When to use: Laravel is great when you need fast prototyping, traditional server-rendered views, or want something easy to hand off to a non-JS dev team.

Why Offer Both?

Some founders want flexibility. Offering both stacks under one roof helps founders choose between cost-efficiency (PHP) and tech scalability (JS). Plus, it reduces the barrier to entry for non-technical stakeholders—Laravel’s admin panels are easier for them to customize.

Database Design: Flexible, Scalable, and Prescription-Ready

When you’re building a healthcare commerce app like Netmeds, your database schema has to handle more than just products. You need to store prescriptions, verify users, track deliveries, manage medical history, and support promotions or offers. I kept things modular and normalized, whether I was using MongoDB (with Node.js) or MySQL/PostgreSQL (with Laravel).

JavaScript Approach – MongoDB with Mongoose

I structured the schema with embedded documents where necessary (like cart items inside user records) and used references for large collections (like orders, prescriptions, and payments). Here’s an example for the product model:

const MedicineSchema = new mongoose.Schema({
  name: String,
  brand: String,
  dosage: String,
  category: String,
  price: Number,
  stock: Number,
  requiresPrescription: Boolean,
  meta: {
    manufacturer: String,
    expiryDate: Date
  }
})

Prescriptions were stored separately and linked to users and orders:

const PrescriptionSchema = new mongoose.Schema({
  userId: mongoose.Schema.Types.ObjectId,
  fileUrl: String,
  status: { type: String, enum: ['pending', 'approved', 'rejected'] },
  verifiedBy: String
})

This allowed flexibility in scaling—especially useful when building analytics or AI-based suggestions later.

PHP Approach – MySQL with Laravel Eloquent

With Laravel, I kept the schema relational. Eloquent’s relationships (hasMany, belongsTo, morphMany) made it easy to query linked data. Here’s a simplified schema idea:

• users (id, name, email, phone)
• medicines (id, name, price, stock, prescription_required)
• orders (id, user_id, total_amount, status)
• order_items (id, order_id, medicine_id, qty)
• prescriptions (id, user_id, file_path, status)

Using migrations and seeders, I could spin up test environments quickly. And with Laravel Nova or Voyager, I gave clients a friendly admin interface for managing these entities.

Design Considerations

• Stock Management: Synced at product level with atomic updates to prevent race conditions on high-volume orders
• Prescription Linking: Tied to orders only if certain medicines required it
• Search Optimization: Indexed fields like name, brand, and category for fast lookup via MongoDB Atlas Search or Laravel Scout + Meilisearch

Having this kind of modular, well-linked schema made scaling features like re-order, subscription, or advanced filters a breeze.

Key Modules & Feature Implementation in Both Stacks

Netmeds isn’t just a medicine listing site. It’s an ecosystem of interlinked modules — everything from product search to prescription upload, checkout, delivery, and admin control. I broke the app down into logical modules and implemented each for both JavaScript and PHP stacks.

1. Product Browsing & Advanced Search Filters

Node.js + React:
I built RESTful APIs like /api/medicines?category=diabetes&brand=Abbott with pagination and sorting. On the frontend, React handled search filters dynamically using URL query params and fetched results via Axios. I used MongoDB’s full-text search and regex filtering for better flexibility.

Laravel:
Laravel controllers accepted request queries like Request::get('brand') and used Eloquent scopes to filter data. Blade templates or Livewire components were used for dynamically updating filter UIs. We also used Laravel Scout with Meilisearch to implement fuzzy search without external services.

2. Prescription Upload & Verification

Node.js:
Users uploaded prescription files via a /api/prescriptions/upload endpoint. The backend stored the file on AWS S3 and saved metadata in MongoDB. A verification workflow allowed pharmacists to approve or reject uploads, with push notifications sent via Firebase.

Laravel:
In Laravel, I used Storage::disk('s3')->put() to store files, and built an admin route /admin/prescriptions to list pending uploads. Verification status could be changed via dropdown in the admin dashboard, thanks to Laravel Nova or custom Blade components.

3. Cart, Orders, and Checkout Logic

Node.js:
Cart data was stored in Redux on the frontend and synced to MongoDB when users logged in. On checkout, a /api/orders POST call handled the order creation, verified stock levels, and deducted inventory in real-time using transactions.

Laravel:
I relied on Laravel’s session and database-backed carts. Orders were created with Eloquent models and relationships. I used Laravel’s database transactions (DB::beginTransaction) to ensure consistency between order creation and stock updates.

4. Admin Panel

React-based Admin (Node.js Stack):
Used Ant Design for the UI components. The admin panel had modules to manage users, prescriptions, medicines, and orders. JWT-authenticated routes and role-based access control (RBAC) handled permissions.

Laravel Admin Panel:
Laravel Nova made admin setup almost plug-and-play. For simpler builds, I used Voyager or custom Blade views. Roles and permissions were handled via Spatie’s Laravel Permission package.

5. Delivery & Order Tracking

Node.js:
Orders included a delivery status field (pending, dispatched, delivered) and I used socket.io to emit updates to the user in real-time.

Laravel:
Used Laravel Events to trigger delivery status updates and notifications. Blade templates displayed current order status, while scheduled jobs updated delivery estimates.

By modularizing these core features, the app remained maintainable and scalable — and I could adapt the flow easily depending on the country or niche.

Handling Third-Party APIs vs Manual Listings

One of the early decisions we made was whether to integrate real-time third-party APIs (for medicine data, availability, etc.) or let the admin manually manage product listings. Turns out, most clients wanted both — and so we built the system to support either mode depending on their business flow.

Third-Party API Integration

Node.js:
We integrated with public and private health APIs like Practo’s listings and dummy endpoints simulating Netmeds-style data for demo. I used Axios within Node.js services, structured with async/await, and ran background sync jobs via node-cron. Example logic:

const fetchFromPartnerAPI = async () => {
  const res = await axios.get('https://api.partner.com/medicines')
  for (let item of res.data) {
    await MedicineModel.updateOne({ externalId: item.id }, { $set: item }, { upsert: true })
  }
}

This allowed daily product syncs without overwriting admin-managed records.

Laravel:
Laravel’s HTTP client (based on Guzzle) handled API requests neatly. I used Laravel Commands and the schedule() function in Console/Kernel.php to sync products every night. Sample logic:

$response = Http::get('https://api.partner.com/medicines')
foreach ($response->json() as $item) {
    Medicine::updateOrCreate(['external_id' => $item['id']], $item)
}

I also wrote logic to respect “manual override” flags so custom prices or stock wouldn’t be overwritten.

Manual Listings via Admin Panel

Node.js (React Admin):
Admins had a full product form with fields for name, price, category, prescription_required, stock, and meta data. Form data was sent to a /api/medicines endpoint and saved via a Node.js controller to MongoDB. We validated input both client-side (Yup) and server-side (Joi).

Laravel (Nova Admin):
In Laravel, using Nova resources, creating or editing a product was simple. Form fields mapped directly to the database, and Laravel’s built-in validation rules ensured no malformed data entered production.

This hybrid approach (API sync + manual override) gave founders the flexibility to start with a base catalog and gradually localize it.

API Layer: Structuring Clean, Scalable Endpoints

Whether we were building for mobile apps, web apps, or third-party integrations, a solid API layer was crucial. I made sure the backend followed RESTful conventions and maintained separation between internal logic and exposed routes. This ensured future compatibility — like swapping React with Flutter or connecting to a delivery partner’s system.

Node.js (Express.js REST API)

I grouped endpoints by resource and followed a clear structure:

routes/
  └── medicines.js
  └── orders.js
  └── prescriptions.js
  └── auth.js

Each route file imported controller functions. Here’s an example of the POST /api/orders logic:

router.post('/', authMiddleware, async (req, res) => {
  const { items, address, paymentMethod } = req.body
  const order = await orderService.createOrder(req.user.id, items, address, paymentMethod)
  res.status(201).json(order)
})

The orderService.createOrder() function handled everything: validating stock, calculating totals, saving order data, and updating product inventory in a transaction-safe way with MongoDB sessions.

For authentication, I used JWT-based middleware:

const authMiddleware = (req, res, next) => {
  const token = req.headers.authorization?.split(" ")[1]
  if (!token) return res.status(401).send('Unauthorized')
  const user = jwt.verify(token, process.env.JWT_SECRET)
  req.user = user
  next()
}

Laravel (PHP API Routes + Controllers)

Laravel provided API scaffolding out of the box. Routes went into routes/api.php, and I grouped them by middleware:

Route::middleware('auth:sanctum')->group(function () {
    Route::post('/orders', [OrderController::class, 'store']);
    Route::get('/user', [UserController::class, 'profile']);
})

Example order creation logic in OrderController:

public function store(Request $request) {
    $validated = $request->validate([
        'items' => 'required|array',
        'address' => 'required|string',
        'payment_method' => 'required|string'
    ])
    $order = OrderService::create($request->user(), $validated)
    return response()->json($order, 201)
}

public function store(Request $request) {
    $validated = $request->validate([
        'items' => 'required|array',
        'address' => 'required|string',
        'payment_method' => 'required|string'
    ])
    $order = OrderService::create($request->user(), $validated)
    return response()->json($order, 201)
}

Auth was handled by Laravel Sanctum with token-based guards. Token issuance and verification were seamless, especially when paired with mobile clients or SPA frontends.

Common API Tips I Followed

• Versioning: Prepended /api/v1/ to all routes to future-proof breaking changes
• Validation: Used Joi in Node.js and Laravel’s request validation to keep data clean
• Error Handling: Standardized error response format with success, message, and data fields
• Rate Limiting: Applied express-rate-limit in Node.js and Laravel’s throttle middleware

A well-structured API made it easy to plug in React, mobile apps, or even partner dashboards — and simplified debugging.

Frontend & UI Structure: UX That Feels Native

For any healthcare commerce app, the frontend needs to be smooth, mobile-optimized, and intuitive. Whether it was React or Blade, my aim was to make the user journey from search to checkout as frictionless as possible. That meant smart layout decisions, minimal page loads, and clear CTAs.

React (with Tailwind + Redux)

I used React as a Single Page Application (SPA) with routing handled by React Router. The layout followed a consistent 3-tier structure:

• Header: Logo, search bar, login/cart/profile icons
• Content Area: Product grid, medicine details, prescription upload form
• Footer: Navigation links, customer support, policies

Tailwind CSS made it easy to build responsive UIs. For instance, the medicine listing grid looked like this:

<div className="grid grid-cols-2 md:grid-cols-4 gap-4">
  {medicines.map(med => (
    <MedicineCard key={med._id} medicine={med} />
  ))}
</div>

I used Redux for shared states like cart, user session, and toast messages. The prescription upload flow was handled with a modal and a file input, while order tracking was built as a separate component pulling live data via polling or websockets.

Blade Templates (with Laravel)

For PHP projects with Laravel, I built the frontend using Blade templating. The layout used Laravel’s section directives (@yield, @section) and a shared layout wrapper:

• base.blade.php for header/footer structure
• home.blade.php, medicines.blade.php, cart.blade.php for individual pages

For responsiveness, I used Bootstrap 5. Grid layouts and collapsible navbars ensured the UI adapted to mobile sizes. File uploads were handled with standard multipart/form-data forms and a bit of Alpine.js for nicer UX:

<input type="file" @change="previewImage" name="prescription" />

Key UX Features I Prioritized

• Sticky search bar on mobile to make it easy to re-query without scrolling
• Prescription-required badge on products that triggered a modal if user skipped upload
• Skeleton loaders on product cards to reduce perceived wait time
• Scroll restoration between pages (React) for smooth navigation
• RTL support for future Middle East deployments

Frontend decisions were always made with performance and usability in mind. Lighthouse audits were run for every release, and we hit 90+ scores consistently.

Authentication & Payments: Secure, Seamless, and Scalable

Authentication and payments are where things get real — especially in a healthcare app where sensitive data and legal compliance intersect. I made sure both the login flow and payment integration were airtight in both stacks, while keeping UX friction minimal.

User Authentication

Node.js + JWT

In the Node.js stack, I built a stateless authentication flow using JSON Web Tokens (JWT). Upon successful login or registration, the backend issued a token with an expiration payload. The frontend stored it in localStorage and attached it to the Authorization header on every request.

Login route example:

router.post('/login', async (req, res) => {
  const user = await UserModel.findOne({ email: req.body.email })
  const isMatch = await bcrypt.compare(req.body.password, user.password)
  const token = jwt.sign({ id: user._id }, process.env.JWT_SECRET, { expiresIn: '7d' })
  res.json({ token, user })
})

I also created a verifyToken middleware to protect all private routes. For sensitive actions like uploading prescriptions or placing orders, I added additional role checks (user vs admin) and token expiry handlers.

Laravel + Sanctum

Laravel made it easier with Sanctum for API token authentication. After login, I issued a personal access token stored in cookies (SPA mode) or in the mobile app headers.

Example login method in the AuthController:

public function login(Request $request) {
  $credentials = $request->validate([
    'email' => 'required|email',
    'password' => 'required'
  ])
  if (!Auth::attempt($credentials)) {
    return response()->json(['message' => 'Invalid credentials'], 401)
  }
  $user = $request->user()
  $token = $user->createToken('mobile_token')->plainTextToken
  return response()->json(['token' => $token, 'user' => $user])
}

The middleware auth:sanctum was applied on protected routes. I also added email verification and password reset via Laravel Notifications.

Payment Gateway Integration

Stripe & Razorpay in Node.js

In Node, I integrated Stripe and Razorpay depending on the region. The checkout page triggered a backend call to /api/payments/create-session, and Stripe’s SDK handled the client redirect.

const stripe = require('stripe')(process.env.STRIPE_SECRET)
const session = await stripe.checkout.sessions.create({
  payment_method_types: ['card'],
  line_items: [...],
  mode: 'payment',
  success_url: 'https://yourapp.com/success',
  cancel_url: 'https://yourapp.com/cancel'
})

Razorpay had a similar flow using the razorpay npm package. I verified webhook signatures server-side to confirm payments and mark orders as paid.

Stripe in Laravel

Laravel has great packages like Laravel Cashier for Stripe. I used this when working with recurring subscriptions (e.g., medicine auto-reorder). For one-time orders, I used Stripe’s official PHP SDK.

Stripe::setApiKey(env('STRIPE_SECRET'))
$session = Session::create([
  'payment_method_types' => ['card'],
  'line_items' => [...],
  'mode' => 'payment',
  'success_url' => route('payment.success'),
  'cancel_url' => route('payment.cancel')
])

I also configured Stripe webhooks using Laravel’s routes/web.php and used a secure controller to process event payloads and update order status.

Security Highlights I Always Implemented

• Passwords hashed using bcrypt (Node.js) or Laravel’s Hash::make()
• Rate limiting on auth routes to prevent brute-force attacks
• CSRF protection via tokens (Laravel) and HTTP-only cookies
• Webhook signature validation to avoid spoofed payment calls

By focusing on authentication and payment stability early on, I avoided last-minute compliance issues and gained trust from early adopters.

Testing & Deployment: CI/CD, Docker, and Going Live Without Firefighting

Shipping a Netmeds-like app isn’t just about writing clean code — it’s about deploying with confidence. Whether it was the JS or PHP version, I made sure everything was tested, containerized, and delivered through a repeatable CI/CD pipeline.

Testing Strategy

JavaScript Stack (Node.js + React)

I wrote unit tests using Jest and Supertest for API endpoints. Each controller and service was independently tested. For example, testing order placement:

describe('POST /api/orders', () => {
  it('should create an order and return 201', async () => {
    const res = await request(app)
      .post('/api/orders')
      .set('Authorization', `Bearer ${token}`)
      .send({ items: [...], address: '123 Street' })
    expect(res.statusCode).toEqual(201)
    expect(res.body).toHaveProperty('orderId')
  })
})

Frontend tests were handled via React Testing Library, with Cypress for end-to-end flow validations — including prescription uploads, cart flows, and payment redirects.

PHP Stack (Laravel)

Laravel ships with PestPHP and PHPUnit, so I wrote feature tests for everything from registration to checkout. Example order test:

public function test_user_can_place_order() {
  $user = User::factory()->create()
  $response = $this->actingAs($user)->postJson('/api/orders', [
    'items' => [...], 'address' => '123 Street'
  ])
  $response->assertStatus(201)
}

I also set up Laravel Dusk for browser-based testing, including payment success flows and file uploads.

Deployment Workflow

Node.js + React

Everything was Dockerized for consistency. I used a multi-stage Dockerfile for the Node backend and React frontend:

# Backend
FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

CI/CD via GitHub Actions: On every push to main, the pipeline ran tests, built Docker images, and deployed to a production server via SSH.

PM2 managed the Node app in production. I configured process.json to handle restarts and memory limits:

{
  "apps": [{
    "name": "netmeds-api",
    "script": "server.js",
    "instances": "max",
    "exec_mode": "cluster"
  }]
}

Nginx acted as a reverse proxy to serve the React SPA and forward API calls to PM2-managed Node processes.

Laravel (PHP)

Laravel ran inside Docker with PHP-FPM + Nginx. I used Laravel Sail locally and custom docker-compose files for staging and production.

Deployment via Envoyer or GitHub Actions: I pushed to GitHub, triggered build/test steps, and deployed to a VPS via Envoyer or SSH hooks.

Apache or Nginx handled routing, and Laravel was run via php artisan serve or as an FPM worker. I used Supervisor for queue workers and scheduled tasks.

Environment Config: .env files were injected using secrets on deploy, keeping sensitive keys out of version control.

Key Ops Tips

• Monitoring: Used PM2 logs and Laravel Telescope for debugging
• Caching: Redis + Node memory cache or Laravel Cache facade
• Rollback Plan: Each release was atomic; backup scripts ensured instant rollback
• Health Checks: UptimeRobot pinged /api/health every 60s

With this setup, we could test, ship, and scale with confidence — and push hotfixes in under 5 minutes.

Real-World Dev Tips: What Actually Matters at Scale

Building the app is one thing. Running it under load, supporting real users, and avoiding crashes is another. After deploying multiple versions of this Netmeds clone across different client markets, here are some lessons learned the hard way — and how you can avoid them.

1. Speed on Mobile is Everything

Most users were on mid-tier Android devices with 3G or flaky 4G. I prioritized loading times using:

• Lazy-loading images (React: loading="lazy", Laravel: lazysizes lib)
• Compressed API payloads via gzip in Node.js and Laravel middleware
• Mobile-first layout with minimal JavaScript animations
• Server-side pagination for product lists instead of loading hundreds at once

2. Use Caching Religiously

Don’t hit the database unless you absolutely have to. I used:

• Node.js: node-cache or Redis to store homepage medicine categories, price ranges, and cart summaries
• Laravel: Cache facade with remember() for popular medicines, search filters, and order count stats

This cut load times in half and reduced server strain by 60%.

3. Watch for Prescription Upload Edge Cases

Users often uploaded blurry or expired prescriptions. I added client-side image previews and server-side checks for file size, type, and resolution. Also, support team got a dashboard to flag unclear prescriptions instead of auto-rejecting them.

4. Cart Sync is Tricky Across Devices

Users switching between mobile and desktop lost cart data. I solved this by syncing cart to the DB on every login and merging localStorage cart with the backend during auth.

5. Payment Failures Will Happen

Always store a “pending” order before redirecting to the payment gateway. If the payment fails, let the user retry from their order history. Don’t make them go through the entire flow again.

6. Use Environment-Specific Configs

I kept all third-party keys, database strings, and webhook secrets in environment files — never in source code. This made switching between dev/staging/production seamless.

7. Mobile-Specific Design Hacks

• Used touch-friendly input sizes (min-height: 48px)
• Kept form fields vertical and clear
• Added country-specific address fields dynamically
• Disabled double-tap zoom with meta viewport tweaks

These tweaks might seem small but made a huge difference in reducing support tickets and abandoned carts.

Final Thoughts: Build from Scratch or Go Clone-First?

After building the Netmeds clone twice — once with JavaScript (Node.js + React) and once with PHP (Laravel) — I can confidently say: if you’re building for learning or highly custom use-cases, go from scratch. But if your goal is speed-to-market, stable UX, and saving dev budget, starting with a ready-made clone script like what Miracuves offers is the smart move.

Here’s how I break it down when talking to founders:

• Go custom from day one if you have a truly unique feature set (AI-based symptom checker, deep IoT integrations, or region-specific workflows that don’t map to the usual Netmeds flow)
• Go with a clone base if you want 80% of the core features (browsing, checkout, prescription uploads, admin control) and then build your secret sauce on top

Most projects waste time building login pages, cart logic, and dashboards — all of which you get out-of-the-box with a mature clone script. I’ve worked with Miracuves’ Netmeds Clone, and I can vouch that it saves weeks of boilerplate work. It supports both JS and PHP environments, and gives you APIs, UI, and admin tools that are field-tested.

Also — when you buy a clone script, you’re not locked in. You can always extend it with your dev team later, once you’re live and bringing in users.

If you’re trying to ship something in the next 3–4 weeks, get a clone, customize it, test it, and go live. You’ll thank yourself.

Frequently Asked Questions (FAQs)