DEV Community: Akhil Baraik

What Building a Multi-Outlet Pizza Ordering App Taught Me About Location, Time Zones and Never Blocking the User

Akhil Baraik — Mon, 12 Oct 2026 04:38:07 +0000

Food ordering apps look simple from the outside. You open the app, pick a pizza, pay, and wait for the doorbell. When my team at Crework Tech started work on the SUSI Pizza platform, I thought the hard parts would be payments and push notifications. They turned out to be the easy parts. The real work was in deciding which store serves a customer, what time it is for that store, and how to say "no" to a customer without making them close the app.

This post is a walk through the engineering decisions that mattered most. If you are building anything with multiple physical locations, delivery zones or opening hours, I hope some of it saves you a few late nights.

The setup

SUSI Pizza is a multi-outlet pizza and cake chain. Each outlet has its own delivery radius, its own opening hours and its own menu. Before the app, ordering was mostly manual and phone based. Our scope covered three pieces:

A customer mobile app built in React Native, with Redux for state.
A React admin panel for the product catalogue, per-store menus and pricing, banners, orders, store settings and staff roles.
A Node.js and Express REST API on Firebase Firestore, with Firebase Auth (Google Sign-In plus mobile OTP), role-based access for super admins and store admins, and push notifications.

A separate team built the store app and the delivery-partner app. Both talk to the same backend, so our API had to be the single source of truth for every outlet. Payments run through Razorpay for UPI, cards and wallets, with Cash on Delivery as a fallback. Indian customers still like having that choice.

Problem 1: Which store serves this customer?

Given a customer's GPS position, the backend has to find the nearest store that is both in range and open right now. That sounds like one query. In practice it is three different answers that the app must treat differently:

A store covers you and it is open. Show the menu, allow checkout.
A store covers you but it is closed right now. Tell the customer exactly that, and when possible, when it opens.
No store covers your location at all. Say so honestly.

The early version collapsed the last two into one generic error. From the customer's side, "we don't deliver here" and "come back at 11" are very different messages. Splitting them made the app feel much more honest, and it also gave the client clearer data about where demand was coming from.

We also found a subtle bug in the fallback path. When the customer's location could not be resolved cleanly, one branch of code quietly used a store's own coordinates in place of the customer's. Distance from a store to itself is zero, so an out-of-range store could be labelled as deliverable. Nothing crashed. The numbers just looked plausible. The fix was simple once we saw it: never substitute a store location for a customer location, and treat "location unknown" as its own state rather than borrowing a value from somewhere else.

My takeaway: when a function can return "no", make it say why. An enum of reasons is far easier to debug and to design UI around than a boolean.

Problem 2: What time is it, really?

Every store has opening hours in Indian Standard Time. Servers and cloud functions often do not run in IST. If you write new Date().getHours() on a server set to UTC, your "open at 11 AM" check is off by five and a half hours, and the half hour makes it even easier to miss in testing.

This bug class came back more than once in different corners of the code, so we stopped fixing it case by case. Store hours logic now always converts to the IST time zone explicitly before comparing, rather than trusting the machine's local time. If you are in India and deploy to any global cloud region, I would make this a rule from day one. Also test the edges: just before opening, just after closing, and stores that close after midnight.

Problem 3: Products are not one size fits all

Pizzas have sizes. Cakes have weights. Drinks have serving counts. Some items have spice levels. Hardcoding a "size" field would have broken the moment the client added a new category.

We built an admin-configurable variant type system. An admin defines a variant type such as Size, Weight, Serving, Volume or Spice Level, and each product can have options under it. Every option carries its own price, discount price, stock and SKU. The customer app reads this generically, so product cards and the cart render correctly without new app releases for every new kind of product.

The lesson here is the usual one, but it is worth repeating: if the client will keep adding things, make the shape configurable, not just the values.

Problem 4: Copying menus across stores

With multiple outlets each carrying dozens of products, assigning and pricing items store by store was slow, repetitive work for the admin team. We added a "copy from another store" option right inside the assign flow, and a bulk tool that clones an entire menu with full pricing to another store. In one case that meant cloning 90 products in a single action instead of entering them one by one.

Admin tooling rarely makes it into launch announcements, but it decides whether the client actually keeps their data up to date. If updating the menu is painful, the menu goes stale, and then the customer app is wrong no matter how good the code is.

Problem 5: Never block browsing

This became a product principle across the whole app. A closed store, an out-of-range address or an unresolved location should never fully lock the customer out. They can always browse the menu and add items to the cart. Only checkout is gated on real delivery eligibility.

It sounds obvious, but it touched a lot of code: the store selection flow, cart validation, and the order calculation on the server. The server always re-validates price and eligibility at checkout, so the client app can be relaxed about browsing without ever trusting itself on money.

Promotions as rules, not campaigns

The client wanted offers like Buy X Get Y, combos, minimum order value discounts and free delivery above a threshold. Instead of writing code for each campaign, we built a rule-based promotion engine that evaluates whatever rules the admin configures. It also shows "locked" offers, so a customer can see what they need to add to unlock a deal. That one small UI choice turns a promotion from a hidden discount into a nudge.

The small things that add up

A few other items that took real time:

Rate limiting on auth endpoints, because OTP endpoints attract abuse.
React Native touch responder and scroll performance fixes, so long menus stay smooth on budget Android phones.
Live order tracking through Received, Preparing, Out for Delivery and Delivered, which stays visible as the customer moves around the app.
One-tap reorder from order history, since most food orders are repeats.

And one habit I now push on every project: for every location or pricing bug fix, we verified the result against live production data before closing it, instead of shipping on faith because the unit test passed.

What I would tell another team

If you are building a multi-location ordering product, here is my short list:

Model "why not" explicitly. Out of range and closed are different states.
Never trust server local time. Convert to the store's time zone every time.
Make product variants configurable from the admin side.
Invest in bulk admin tools early.
Let users browse freely, and gate only the action that truly needs it.
Validate prices on the server, always.

You can read the full SUSI Pizza case study on our site, including the platform breakdown and the customer journey. If you are a business in Jharkhand thinking about an app of your own, we also have a page on our mobile app development work in Ranchi.

I would love to hear how other teams handle store hours and delivery zones. Drop your approach in the comments.

Akhil Baraik is the founder of Crework Tech, an IT and digital marketing agency based in Ranchi, Jharkhand. Connect with him on LinkedIn.

How Small Businesses in India Can Choose the Right Software Development Company

Akhil Baraik — Mon, 12 Oct 2026 04:07:35 +0000

I run a small IT and digital marketing agency in Ranchi, and I have sat on both sides of the table: pitching for software projects and hiring outside developers. In my experience, most failed projects do not fail because the code was bad. They fail because the business and the developer never agreed on what was being built, who owned it, or what would happen after launch.

If you run a small business in India and plan to get custom software built, this is what I wish every client read first. It applies whether you hire locally, in a metro, or abroad.

Start by Defining Your Requirements

Before you speak to any vendor, write down what you need. A few pages in plain language are enough. Answer these questions:

What problem are you solving, and for whom?
Who will use the software? Staff, customers, field technicians, managers?
What are the five or six things the software must do on day one?
What can wait for a second phase?
Does it need to connect with anything you already use, such as Tally, a payment gateway, WhatsApp or an existing website?
What is your rough budget and your ideal launch date?

Separating "must have" from "nice to have" keeps the first version smaller and cheaper, and gives you a fair way to compare quotes. If two quotes differ widely, check whether both companies understood the same scope.

Fixed Price vs Time and Material

You will usually be offered one of two pricing models.

Fixed price means you agree on a defined scope and a set cost. It works well when your requirements are clear and unlikely to change. The risk is that every change after signing becomes a "change request" with extra cost, and some vendors pad the quote to protect themselves.

Time and material means you pay for the hours or days actually worked, usually at an agreed rate. It suits projects where you expect to learn and adjust as you go. The risk is that costs can grow if nobody is watching the scope.

For many small businesses, a mix works best. Fix the price for a clearly defined first version, then move to time and material for improvements later. Whichever model you choose, ask for payment to be linked to milestones you can actually see and test, not just to dates on a calendar.

Check Portfolios and Case Studies Properly

Almost every company has a portfolio page. The trick is to look past the screenshots. When you review past work, ask:

Was this project similar to mine in size and type?
What exactly did this company build? The whole system, or just the design?
Can I see a live version or a demo?
Can I speak to a past client?

A good case study explains the problem, the approach and the technology used. As one example from my own work, we wrote up a custom after-sales service management system we built for Seekoji Electric, which used Next.js, Node.js, Express and MongoDB, with JWT authentication and role-based access so different staff saw only what they needed. I mention it only to show the kind of detail you should expect. If a company cannot tell you what they used and why, be careful.

Ask Questions About the Tech Stack

You do not need to be a programmer to ask sensible questions. The goal is software that will not be hard to maintain or move later. Ask:

Which languages and frameworks will you use, and why are they right for this project?
Are these technologies widely used, so that another developer could take over if needed?
Where will the software be hosted, and who pays for the hosting?
How will you handle security, logins and user permissions?
Will the software work well on mobile phones?

Be wary of anyone who insists on an obscure or in-house framework without a clear reason. Popular, well-documented tools make it much easier to find help in the future.

Make Sure You Own the Code and IP

This is the point small businesses most often overlook. If you are paying for custom software, your contract should clearly state that the source code, designs, database structure and related intellectual property belong to you once you have paid.

Also ask for practical access, not just legal ownership:

The code should live in a repository, such as GitHub or GitLab, that you control or can be added to.
Hosting, domain and cloud accounts should ideally be registered in your business name.
You should receive all passwords, admin credentials and documentation at handover.

I have seen businesses locked out of their own software because a freelancer registered everything personally and then became unreachable.

NDAs and Contracts

If you are sharing business ideas, customer data or internal processes, it is reasonable to ask for a non-disclosure agreement before detailed discussions. Most professional companies will sign one without fuss.

The main contract should cover at least:

The scope of work, ideally with your requirements document attached
Milestones, deliverables and payment terms
Ownership of code and IP
How change requests are priced and approved
Warranty or bug-fixing period after launch
Confidentiality and handling of your data
What happens if either side wants to end the project

If you are unsure about any clause, a lawyer's review costs far less than a dispute.

Communication and Timezone

Good communication matters as much as good coding. Before signing, find out:

Who will be your single point of contact?
How often will you get updates, and in what form?
Which tools will be used, such as WhatsApp, email, Google Meet or a project board?
Can you see progress regularly, for example a working demo every week or two?

Timezone matters too. A team in India shares your working hours, which makes quick calls easy. If you hire offshore, agree on overlapping meeting hours. You should also be able to discuss your needs in a language you are comfortable with.

Plan for Post-Launch Support

Software is never really finished at launch. Users will find bugs, phones and browsers will update, and you will want small changes. Ask each company:

How long is the free bug-fixing period after launch?
What does a support or maintenance plan include, and what does it cost?
How fast will they respond to a critical problem?
Who handles server updates, backups and security patches?

Get these answers in writing.

Red Flags to Watch For

Take these warning signs seriously:

A quote given before they have understood your requirements
A price far lower than every other quote, with no clear explanation
Reluctance to put ownership of code in writing
No real portfolio, or work they cannot explain in detail
Pressure to pay most of the amount upfront
Vague answers about who will actually work on your project
No mention of testing, documentation or support
Promises that sound too good, such as a complex app in a week

One red flag is not always a deal breaker, but two or three together usually are.

Local vs Metro vs Offshore Agencies

Local agencies in your own city or state can meet you in person, understand regional customers and often work at reasonable rates. Smaller cities now have capable teams, but check their experience carefully, because quality varies.

Metro agencies in places like Bengaluru, Mumbai, Delhi NCR or Pune may have larger teams and more specialists. They can also be more expensive, and a small project may not get their senior people's attention.

Offshore or foreign agencies can bring different experience, but timezone gaps, higher costs and less familiarity with Indian business practices, such as GST invoicing or local payment methods, can make things harder for a small Indian business.

Judge the team, not the location. A focused small team that understands your business can serve you better than a big name that treats your project as a minor account.

A Short Checklist

Before you sign, make sure you can tick these boxes:

I have a written list of requirements, split into must have and later.
I have compared at least two or three quotes for the same scope.
I understand whether the price is fixed or time and material.
I have seen real, relevant past work and ideally spoken to a past client.
I know which technologies will be used and why.
The contract says I own the code and IP after payment.
Code, hosting and domain accounts will be in my control.
An NDA is signed if I am sharing sensitive information.
Payments are tied to milestones I can test.
I know who my contact is and how often I will get updates.
A bug-fixing period and support plan are agreed in writing.

Choosing a software development company is less about finding a perfect vendor and more about asking the right questions early.

Akhil Baraik is the founder of Crework Tech, an IT and digital marketing agency based in Ranchi, Jharkhand.

Building an After-Sales Service System for an Electrical Manufacturer with Next.js, Express and MongoDB

Akhil Baraik — Fri, 09 Oct 2026 06:12:06 +0000

A lot of our work at Crework Tech is marketing-facing: websites, SEO and campaigns. So when Seekoji Electric, an electrical manufacturing and service company here in Ranchi, asked us for a system to run their after-sales service, it was a different kind of project. Nobody would see it on Google. Its whole job was to keep products, customers, technicians and paperwork from drifting out of sync.

This post walks through how we thought about it and a few patterns that I think are useful for anyone building a similar ERP-style app. The code below is simplified and generic. It shows the shape of the approach, not a copy of the production codebase.

What the system needed to do

The scope came down to ten modules:

Dashboard and analytics
Customer management
Service request management
Repair workflow
Product testing workflow (assign products for testing and update results)
Technician assignment
User and role management (RBAC)
Reports and analytics
Status tracking
Search and filters

Every product that comes in for service moves through six statuses: pending, under testing, received, under repair, repaired and delivered.

The stack was Next.js and Tailwind CSS on the front end, Node.js and Express.js for REST APIs, MongoDB for storage, and JWT authentication with role-based access control.

If you look at that module list, almost all of it hangs off one thing: the status of a repair. The dashboard counts by status. Reports group by status. Technicians filter by status. Customers ask "what's the status?" So that is where I'll start.

1. Treat status as a state machine, not a dropdown

The easiest way to build a status field is a <select> that lets anyone pick any value. The easiest way to break a service workflow is the same thing. A product jumps from "pending" to "delivered", and now your history says something that never happened.

The fix is to define the allowed transitions in one place on the server and refuse everything else.

// lib/repairStatus.js
const STATUS = Object.freeze({
  PENDING: 'pending',
  UNDER_TESTING: 'under_testing',
  RECEIVED: 'received',
  UNDER_REPAIR: 'under_repair',
  REPAIRED: 'repaired',
  DELIVERED: 'delivered',
});

// Example transition map. The real edges are a business decision,
// so agree on them with the people who run the service desk.
const TRANSITIONS = {
  [STATUS.PENDING]: [STATUS.UNDER_TESTING],
  [STATUS.UNDER_TESTING]: [STATUS.RECEIVED],
  [STATUS.RECEIVED]: [STATUS.UNDER_REPAIR],
  [STATUS.UNDER_REPAIR]: [STATUS.REPAIRED],
  [STATUS.REPAIRED]: [STATUS.DELIVERED],
  [STATUS.DELIVERED]: [],
};

function canTransition(from, to) {
  return (TRANSITIONS[from] || []).includes(to);
}

module.exports = { STATUS, TRANSITIONS, canTransition };

Two things I like about keeping this as plain data:

The front end can import the same map (or fetch it from an endpoint) and only show the buttons that are valid for the current status. The UI stops offering mistakes.
When the business changes its process, you change one object and the tests that cover it.

Checking canTransition in a route is not enough on its own, though. If two people update the same record at nearly the same moment, a read-then-write can let both through. Put the expected current status in the update filter so MongoDB does the check atomically:

// services/repairService.js
const Repair = require('../models/Repair');
const { canTransition } = require('../lib/repairStatus');

async function changeStatus(repairId, from, to, userId, note) {
  if (!canTransition(from, to)) {
    const err = new Error(`Cannot move from ${from} to ${to}`);
    err.status = 422;
    throw err;
  }

  const updated = await Repair.findOneAndUpdate(
    { _id: repairId, status: from },          // only if still in "from"
    {
      $set: { status: to },
      $push: { history: { from, to, by: userId, note, at: new Date() } },
    },
    { new: true }
  );

  if (!updated) {
    const err = new Error('Status changed by someone else. Reload and try again.');
    err.status = 409;
    throw err;
  }
  return updated;
}

module.exports = { changeStatus };

The history push in the same update is what gives you a complete service history for free. Every status change records who made it and when, and it can never get out of step with the status itself.

2. JWT authentication plus RBAC middleware in Express

A service system has very different users. Someone at the front desk creates service requests. A technician updates test results and repairs. An admin manages users and roles. Role-based access control keeps each of them to what their job needs.

I prefer two small middlewares: one that verifies the token, and one that checks permissions. Mapping roles to permissions (instead of checking role names inside routes) keeps things flexible when a new role shows up later.

// middleware/auth.js
const jwt = require('jsonwebtoken');

function authenticate(req, res, next) {
  const header = req.headers.authorization || '';
  const token = header.startsWith('Bearer ') ? header.slice(7) : null;
  if (!token) return res.status(401).json({ error: 'Missing token' });

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.user = { id: payload.sub, role: payload.role };
    next();
  } catch {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
}

// Example roles and permissions. Adjust to the client's real org chart.
const PERMISSIONS = {
  admin: ['users:manage', 'repairs:read', 'repairs:write', 'repairs:assign', 'repairs:status', 'reports:read'],
  manager: ['repairs:read', 'repairs:write', 'repairs:assign', 'repairs:status', 'reports:read'],
  technician: ['repairs:read', 'repairs:test', 'repairs:status'],
};

function authorize(...required) {
  return (req, res, next) => {
    const granted = PERMISSIONS[req.user?.role] || [];
    const ok = required.every((p) => granted.includes(p));
    if (!ok) return res.status(403).json({ error: 'Forbidden' });
    next();
  };
}

module.exports = { authenticate, authorize };

Signing the token at login is the usual jwt.sign({ sub: user.id, role: user.role }, process.env.JWT_SECRET, { expiresIn: '8h' }). Then routes read almost like documentation:

// routes/repairs.js
const router = require('express').Router();
const { authenticate, authorize } = require('../middleware/auth');
const ctrl = require('../controllers/repairs');

router.use(authenticate);

router.get('/', authorize('repairs:read'), ctrl.list);
router.post('/', authorize('repairs:write'), ctrl.create);
router.patch('/:id/assign', authorize('repairs:assign'), ctrl.assignTechnician);
router.patch('/:id/test-result', authorize('repairs:test'), ctrl.recordTestResult);
router.patch('/:id/status', authorize('repairs:status'), ctrl.changeStatus);

module.exports = router;

One note: route-level permissions are the first gate, not the only one. Inside changeStatus it is worth also checking that, for example, a technician can only move repairs assigned to them. Row-level rules like that live in the service layer.

3. A MongoDB schema sketch for repairs

Here is the rough shape of a repair document. Customers and users live in their own collections and are referenced by id. Test results and history are embedded, because they belong to one repair and are always read with it.

// models/Repair.js
const { Schema, model, Types } = require('mongoose');
const { STATUS } = require('../lib/repairStatus');

const TestResultSchema = new Schema({
  result: { type: String, enum: ['pass', 'fail'], required: true },
  notes: String,
  testedBy: { type: Types.ObjectId, ref: 'User' },
  testedAt: { type: Date, default: Date.now },
}, { _id: false });

const HistorySchema = new Schema({
  from: String,
  to: String,
  by: { type: Types.ObjectId, ref: 'User' },
  note: String,
  at: { type: Date, default: Date.now },
}, { _id: false });

const RepairSchema = new Schema({
  ticketNo: { type: String, unique: true, required: true },
  customer: { type: Types.ObjectId, ref: 'Customer', required: true },
  product: {
    name: String,
    model: String,
    serialNo: String,
  },
  complaint: String,
  status: {
    type: String,
    enum: Object.values(STATUS),
    default: STATUS.PENDING,
    index: true,
  },
  assignedTechnician: { type: Types.ObjectId, ref: 'User', index: true },
  testResults: [TestResultSchema],
  history: [HistorySchema],
}, { timestamps: true });

// Supports the common "my open jobs" and dashboard queries
RepairSchema.index({ assignedTechnician: 1, status: 1, updatedAt: -1 });
// Supports the search box
RepairSchema.index({ ticketNo: 'text', 'product.serialNo': 'text', 'product.model': 'text' });

module.exports = model('Repair', RepairSchema);

Design your indexes from the screens, not the other way round. Search and filters, the technician's work queue and the dashboard each turn into a query, and each query should hit an index.

4. Dashboard numbers from one aggregation

Once status is reliable, the dashboard is mostly a $group:

const counts = await Repair.aggregate([
  { $group: { _id: '$status', count: { $sum: 1 } } },
]);

The Next.js dashboard calls a REST endpoint that returns this, and Tailwind takes care of turning it into readable cards. Reports are the same idea with a date range and more grouping keys.

The outcome, in plain terms

The benefits we set out for this project are all about the day-to-day work: faster repair processing, centralized service records, better technician productivity, a complete service history, real-time status tracking, less manual paperwork, better operational visibility and an improved experience for their customers. We've written up the project in more detail in our Seekoji Electric ERP case study.

What I'd pass on

If you are building something similar for a manufacturer or service business:

Model the workflow before the screens. Sit with the people who handle the products and write the status transitions down. That object becomes the spine of the app.
Enforce transitions on the server, atomically. The UI can guide people, but the database filter is what keeps data honest.
Write history in the same update as the status. You will need it the first time a customer disputes what happened to their product.
Use permissions, not role checks, in routes. New roles stop being a refactor.
Index for the screens people actually use. Search, filters and work queues should never scan the whole collection.

None of this is new or clever. It is just the stuff that is easy to skip when a project starts as "a simple form to track repairs", and painful to add later.

Akhil Baraik is the founder of Crework Tech, a digital marketing and IT agency based in Ranchi, Jharkhand. You can find him on LinkedIn.