DEV Community: Akhil Baraik

Redesigning Your Website Without Losing Your Google Traffic

Akhil Baraik — Mon, 02 Nov 2026 09:49:20 +0000

A new website feels like a fresh start. The design is cleaner, the pages load faster and the copy finally says what the business does. Then, a few weeks after launch, enquiries slow down and nobody can explain why.

More often than not, the cause isn't the new design. It's what got lost on the way: old page addresses that now lead nowhere, titles that were rewritten without thought, and content that quietly disappeared. Google had spent years learning what the old site was about, and the redesign threw much of that away overnight.

The good news is that this is avoidable. Here's the checklist I go through with clients before, during and after a redesign.

1. Take a snapshot of the old site before anything changes

Before a single page is rebuilt, make a record of what you have today:

A full list of page URLs. Your sitemap, a crawler tool or Google Search Console can give you this.
Which pages bring in visitors and enquiries. Search Console's Performance report shows the pages and search terms that get clicks.
Each important page's title, meta description and main heading.
Pages that other websites link to, since those links carry weight you don't want to lose.

Save this somewhere the whole team can see. It becomes the reference for every decision that follows, and it's very hard to rebuild once the old site is gone.

2. Keep the URLs that already work, where you can

The simplest way to protect rankings is to not change addresses that don't need changing. If /services/web-design is already ranking, there's rarely a good reason to rename it to /what-we-do/design just because the new menu is laid out differently.

When a URL truly has to change, because pages are being merged, renamed or reorganised, that's fine. It just needs a redirect.

3. Map every old URL to a new home with 301 redirects

A 301 redirect tells browsers and search engines that a page has moved permanently and where it went. Without it, anyone who clicks an old link, from Google, a directory or a bookmark, lands on a "page not found" error.

Build a simple two-column sheet: old URL on the left, new URL on the right. A few rules help:

Point each old page to the closest matching new page, not to the homepage. Sending everything to the homepage confuses visitors and search engines alike.
If two old pages are being merged, redirect both to the merged page.
Only let a page return "not found" if it genuinely has no replacement and no value.
Avoid chains, where page A redirects to B, which redirects to C. Point A straight to C.

4. Don't drop content that was doing a job

Redesigns often come with a push to "simplify", which can mean cutting long service pages down to a few lines. Those longer pages may be exactly why you ranked. They answered the questions people were searching for.

Shorter can be better for reading, but check your snapshot first. If a page was bringing in traffic, keep the substance of what it covered, even if you reorganise or rewrite it. Thin pages with a headline and two sentences rarely rank for anything.

5. Carry over titles, headings and on-page basics

For each page that's performing, compare the old and new versions:

Is the title tag still clear and specific, and does it still mention the service and the place?
Does the page still have one clear main heading?
Are images given sensible file names and alt text?
Are internal links still pointing to the right pages, not to old addresses?

None of this is glamorous, but small slips here add up across a whole site.

6. Test on a staging site, and keep it hidden

Build and review the new site on a staging address first. Just make sure search engines can't index it, usually with a password or a "noindex" setting, or Google may find two copies of your site.

Then, and this is the step people forget, remove that block when the new site goes live. A live site still carrying a "noindex" tag or a blocking robots.txt file can vanish from search results surprisingly quickly.

7. Launch day: check the essentials

On the day you switch over:

Test a sample of old URLs from your sheet and confirm each one redirects to the right new page.
Make sure the live site isn't set to "noindex" and robots.txt isn't blocking it.
Submit the new sitemap in Google Search Console.
Check that forms, phone links and tracking still work, since a broken contact form costs you enquiries straight away.
Update the website link on your Google Business Profile and main listings if any addresses changed.

8. Watch closely for the first few weeks

Some movement in rankings after a redesign is normal while Google re-crawls the site. What you're looking for is anything that doesn't settle.

For the first month or so, check Search Console every week for new "not found" errors and pages that have dropped out of the index. Fix missing redirects as you find them. Compare clicks on your key pages against your snapshot. If an important page has slipped, look at what changed on it: content, title, internal links or speed.

The short version

A redesign should make your website better for visitors without throwing away the trust it has already built with search engines. Keep a record of the old site, keep URLs that work, redirect the ones that change, protect the content that ranks, and watch the numbers after launch.

At Crework Tech, we're an IT and digital marketing agency in Ranchi with 7+ years of building websites and software and a 90% client retention rate, and this checklist is part of every rebuild we take on. If you're planning a redesign and want a second pair of eyes on the move, our SEO services in Ranchi cover exactly this kind of migration check.

Your First Business App: What to Build First and What to Leave Out

Akhil Baraik — Thu, 29 Oct 2026 05:19:36 +0000

When a business owner tells me they want an app, the first list of features is usually long. Online ordering, loyalty points, chat, a referral scheme, push offers, a delivery tracker, an admin dashboard, maybe a wallet. Every item makes sense on its own. Put together, they turn a three-month project into a year-long one, and the app launches late, over budget and harder to use than it needs to be.

A better first version does one job well and leaves room to grow. Here's how I suggest deciding what goes in.

1. Write down the one job the app must do

Start with a single sentence: "A customer opens the app to ___." For a restaurant it might be "to order food for pickup or delivery." For a clinic, "to book an appointment." For a field-service company, "so our technicians can log each visit from the site."

If you can't finish that sentence in a few words, the app isn't ready to be built yet. Everything in the first version should support that one job. Anything that doesn't can wait.

2. Check whether you need an app at all

This sounds odd coming from a developer, but it saves people real money. A mobile-friendly website can handle a lot: menus, bookings, enquiry forms, even payments. People already have a browser, so there's nothing to download.

An app starts to earn its place when customers come back often, when you need phone features like the camera, GPS, offline use or push notifications, or when your own staff will use it every day. If none of those apply, a good website may be the smarter first step, and you can add an app later.

3. Sort every feature into three lists

Take your full wish list and split it:

Must have. Without it, the one job can't be done. For a food-ordering app, that's the menu, the cart, checkout, payment and an order confirmation.
Should have soon. Useful, but customers can live without it for a few months. Order history, saved addresses and reorder buttons often land here.
Nice to have. Loyalty points, referral codes, in-app chat, themes. Good ideas, but they belong in a later version once you know people use the app.

Be strict with the first list. A feature that "would be good to have from day one" is usually a should-have in disguise.

4. Don't forget the parts customers never see

Owners plan the customer screens and forget the back office. Someone has to add products, change prices, see new orders, mark them done and handle refunds. If there's no simple admin panel, your team ends up calling the developer for every small change.

Plan these early too:

Notifications to staff, so a new order or booking isn't missed.
Basic reports, even just daily orders and revenue, so you can see whether the app is working.
Who can do what, if more than one person will manage it.

5. Choose Android, iPhone or both with your customers in mind

Look at who your customers actually are. In much of India, most customers are on Android, so some businesses start there. If your customers are spread across both, a cross-platform framework such as Flutter or React Native lets one codebase run on Android and iPhone, which usually keeps the first version's cost and timeline lower than building two separate native apps.

Ask your developer which approach they recommend for your case and why. A good answer will mention your users and features, not just the tool they happen to prefer.

6. Plan for life after launch

An app isn't finished when it reaches the Play Store. Android and iOS release updates every year, payment gateways change their requirements, and real customers will find bugs that testing didn't. Budget for maintenance from the start and agree in writing who handles fixes and updates.

Also make sure you own what you're paying for. Your developer account on Google Play and the App Store, the source code and the server should be in your business's name, or handed over to you if you ask.

7. Launch small, then listen

Once the first version is live, watch what people actually do. Which screens do they use? Where do they drop off? What do they ask your staff about? That tells you which items from the "should have" and "nice to have" lists are worth building next, and which ones nobody misses.

A simple checklist before you talk to a developer

One sentence describing the app's main job
A clear reason it needs to be an app rather than a website
Your feature list split into must-have, should-have and nice-to-have
A note on what your staff need in the admin panel
Which platforms your customers use
A maintenance budget and an ownership agreement

Bring that to your first meeting and you'll get more accurate quotes, fewer surprises and an app that does its main job well from day one.

Akhil Baraik is the founder of Crework Tech, an IT and digital marketing agency in Ranchi, India, with 7+ years of experience building software, websites and apps. If you're planning a first app, you can see how we approach mobile app development in Ranchi.

A Social Media Plan a Small Local Business Can Actually Keep Up With

Akhil Baraik — Mon, 26 Oct 2026 06:35:56 +0000

Most small-business owners I talk to have the same social media story. They open an Instagram and Facebook page, post every day for two weeks, run out of ideas, and then the page sits untouched for months. Anyone who finds it later sees a last post from last Diwali and wonders whether the business is still open.

The problem is rarely effort. It's a plan that was too ambitious to begin with. Here's the simpler approach I suggest to local businesses, whether that's a clinic, a coaching centre, a restaurant or a shop.

1. Pick one or two platforms, not five

You don't need to be everywhere. Ask where your customers already spend time and where they'd actually look you up.

A restaurant, salon, boutique or gym usually does well on Instagram, with Facebook alongside for an older audience.
A B2B service, such as an accountant, consultant or software company, usually gets more from LinkedIn.
Almost every local business should treat its Google Business Profile as a social channel too. Posts, photos and replies to reviews there are seen by people who are already searching for you.

Two channels you keep alive beat five you abandon.

2. Set a rhythm you can hold for a year

Before deciding how often to post, decide how much time you can honestly give it each week. If the answer is two hours, plan for two or three posts a week, not one a day. Consistency matters more than volume, because a page that posts steadily looks active and trustworthy, while a burst followed by silence looks the opposite.

Block a fixed slot in your week, say Monday morning, to plan and schedule the next week's posts in one sitting. Meta Business Suite lets you schedule Facebook and Instagram posts for free, and LinkedIn lets you schedule posts natively, so you don't have to remember to post on the day.

3. Use a few repeatable content types

Running out of ideas is the main reason pages go quiet. The fix is to stop thinking of each post as a fresh idea and rotate a handful of formats instead:

Show the work. A finished order, a before-and-after, a new arrival, a project you just delivered.
Answer a question. Take a question customers ask you on calls or WhatsApp and answer it in a short post or video.
Behind the scenes. Your team, your kitchen, your workshop, how something gets made.
Proof from customers. A review (with permission), a thank-you message, a photo a customer tagged you in.
Useful local information. Opening hours over a festival, a new branch, parking tips, delivery areas.

With five formats, a week's plan becomes "which two or three of these do I have material for?" rather than "what on earth do I post?"

4. Make every post easy to act on

A post that gets likes but no enquiries isn't doing much for a local business. Make sure people can take the next step without hunting:

Keep your phone number, WhatsApp link, address and opening hours correct in every profile bio.
Use the same business name, phone number and address everywhere, including your website and Google Business Profile. Mismatched details confuse customers and search engines alike.
Add a clear line where it fits, like "Call to book", "Order on WhatsApp" or "Visit us in Lalpur", instead of leaving people to work it out.
Link to the most relevant page on your website, not just the home page.

5. Reply quickly, publicly and politely

Comments and messages are where social media actually turns into business. Check them daily, even when you aren't posting. Reply to questions in the comments so the next person sees the answer. Thank people for good reviews, and answer bad ones calmly with an offer to sort it out offline. How you handle a complaint in public often says more about you than any post you make.

6. Spend on ads only after the basics work

Boosting posts can help, but only once your page looks active, your profiles are complete and you know which posts people respond to. Start small, target the area you actually serve, and send people to a page or WhatsApp chat where they can enquire. If an ad isn't bringing enquiries, pause it and look at the offer and the landing page before spending more.

7. Check what's working once a month

You don't need a complicated dashboard. Once a month, look at the built-in insights on each platform and ask three questions: which posts got the most saves, shares, comments or messages, which brought actual enquiries, and which fell flat. Do more of the first two kinds and less of the last. Ask new customers how they found you, too, because that tells you more than reach numbers do.

Keep it boring and steady

A good social media presence for a local business isn't about going viral. It's about looking open, trustworthy and easy to contact every time someone checks. A small plan you follow every week will do far more for you than an ambitious one you drop after a fortnight.

If you'd like help setting up a plan like this, or running it for you, my team at Crework Tech offers social media marketing in Ranchi for local businesses. We're an IT and digital marketing agency, and we've been building websites, software and marketing for small businesses for over seven years.

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

How a Small Business Can Get Mentioned in AI Search Answers (Without Chasing Tricks)

Akhil Baraik — Thu, 22 Oct 2026 04:51:37 +0000

More of the people I talk to now start a search by typing a full question into ChatGPT, Perplexity, Gemini or Copilot instead of Google. "Which IT company in Ranchi builds mobile apps?" "Who does website maintenance near me?" The tool doesn't hand back ten blue links. It writes one answer, and your business is either in it or it isn't.

This is what people mean by AI search optimization, sometimes called GEO (generative engine optimization). It sounds new, but most of the work is the same groundwork good SEO always needed, done more carefully. Here's how I explain it to small-business owners.

1. Understand what these tools actually read

AI assistants build answers from two places: what they learned from large crawls of the web during training, and, for many of them, live web search at the moment you ask. Either way, they're reading public pages. If the facts about your business are thin, scattered or contradictory online, the tool has nothing solid to repeat.

So the first question isn't "how do I trick the AI?" It's "if a careful reader looked me up across the web, would they get a clear, consistent picture?"

2. Say plainly what you do, where, and for whom

AI answers lean on pages that state things clearly. Vague taglines like "we deliver excellence" give a model nothing to quote. A sentence like "We build custom web and mobile apps for small businesses in Ranchi, Jharkhand" does.

On your own site, check that:

Your home page and each service page say what the service is, who it's for and where you work, in normal sentences near the top.
Every service has its own page, rather than five services crammed into one paragraph.
Your about page states when you started, what you specialise in and how to contact you.

3. Answer real questions on your pages

People ask AI tools questions, so pages that answer questions directly are easy to draw from. Write down the questions customers actually ask you on calls and WhatsApp, such as how long a website takes, what a maintenance plan includes, or whether you work with businesses outside your city. Then answer them honestly on the relevant page, with a short FAQ section if it fits.

Keep each answer self-contained. A two- or three-sentence answer that makes sense on its own is much more likely to be picked up than a point buried in a long paragraph.

4. Add structured data

Schema markup is a small block of code that tells machines what a page is about: your business name, address, phone, services, and FAQs. Search engines have used it for years, and it helps AI-driven search read your pages without guessing. At minimum, most local businesses should have LocalBusiness (or Organization) markup and FAQPage markup where they have FAQs. Test it with Google's Rich Results Test after adding it.

5. Keep your details identical everywhere

Your name, address, phone number and description should match across your website, Google Business Profile, directories, social profiles and anywhere else you're listed. If one listing has an old number and another spells the business name differently, you're making it harder for any system, human or AI, to be sure they're all the same business.

This is boring work, but it's one of the most useful things a local business can do.

6. Get mentioned on other sites, not just your own

AI answers tend to reflect what the wider web says, not only what you say about yourself. Genuine mentions help: a listing in a relevant industry directory, a local news feature, a guest article on a site in your field, a customer review on a third-party platform, a helpful answer in a community forum. The goal is to be cited as a real, active business by sources other than your own website.

Avoid shortcuts like bulk link packages or spun content. They don't build trust with readers, and they can hurt your regular search rankings.

7. Don't let the technical basics slip

None of the above helps if crawlers can't read your site. Make sure pages load reasonably fast, aren't blocked by robots.txt by mistake, return proper status codes instead of errors, and have correct canonical tags and titles. Broken pages and duplicate content confuse both search engines and AI tools.

8. Check what the tools say about you

Every month or so, ask a few AI assistants the questions your customers would ask, like "best website developers in [your city]" or "who offers [your service] in [your area]", and note whether you appear and whether the details are right. If something is wrong, trace it back: usually an outdated listing or an unclear page is the source. Results vary from tool to tool and day to day, so look for patterns rather than reacting to one answer.

The honest summary

There's no switch that makes ChatGPT recommend you. What works is being clear about who you are, answering your customers' real questions, keeping your details consistent, and earning genuine mentions across the web. The nice side effect is that all of it improves your regular Google visibility too.

At Crework Tech, an IT and digital marketing agency in Ranchi, we've been building websites and software for over seven years, and lately a lot of our conversations with clients are about this shift. If you want to go deeper, we've put together a guide to AI search optimization and GEO that covers how tools like ChatGPT and Perplexity find websites.

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

What to Put in Place Before You Turn On Google Ads

Akhil Baraik — Mon, 19 Oct 2026 04:55:54 +0000

I run an IT and digital marketing agency in Ranchi. When a small business tells me Google Ads "did not work," the ads are rarely the first problem. The usual pattern is that the budget went live before the basics underneath it were ready: no clear offer, a weak landing page, no way to count a real lead, and no plan for what happens after someone clicks.

Google Ads can send people to you the same day you switch it on. That is useful. It also means every gap in your setup burns money faster than SEO ever would. Here is the checklist I walk through with clients before we spend a rupee on clicks.

1. Know what a "lead" means for your business

Write one sentence that defines a useful enquiry. Examples:

A WhatsApp message that includes the service they want and a phone number we can call back
A form submit with name, phone and preferred time
A booked consultation slot
A call that lasts more than 30 seconds and is about a service you actually sell

"Website traffic" and "likes" are not leads. If you cannot count the outcome you care about, you cannot tell whether the ads are helping. Agree on that definition with whoever answers the phone or WhatsApp before the campaign starts.

2. Pick one offer and one primary location

Ads work best when the promise is specific. "Best digital solutions in Jharkhand" is hard for a searcher to trust. "Commercial AC repair across Ranchi, same-day visit slots" is easier to click and easier to measure.

Choose:

The main service or product you want to sell this month
The geography that matters (Ranchi only, Ranchi plus nearby towns, or a radius around your shop)
The language people actually type into Google (often a mix of English and Hindi transliteration)

You can add more services later. A first campaign with one clear offer teaches you more than a sprawling account with ten ad groups and thin traffic in each.

3. Send clicks to a page that matches the ad

The landing page does not have to be fancy. It does have to match what the ad promised, load quickly on a phone, and make the next step obvious.

Before you turn ads on, check:

The headline on the page repeats the service and city from the ad
The main button or form is visible without scrolling on a phone
Phone and WhatsApp are clickable
There are no competing pop-ups that hide the form
The page does not ask for more fields than you need to call the person back

If your homepage talks about everything you do, build a simple dedicated page for the campaign instead. Sending "AC repair Ranchi" traffic to a generic homepage is one of the fastest ways to waste spend.

4. Install conversion tracking properly

Without tracking, you are guessing. At minimum:

Google Analytics 4 on the site
Google Ads conversion actions for the events that match your lead definition (form submit, click-to-call, WhatsApp click if you can measure it)
A way to mark which enquiries came from ads when someone calls or messages (a unique phone number, a form field, or a simple "How did you find us?" habit on WhatsApp)

Test a conversion yourself before launch. Submit a dummy form, confirm it appears in Ads and Analytics, then delete the test lead. Do not discover on day five that nothing was recording.

5. Make sure someone can answer within minutes

Paid search traffic is impatient. If your ad runs from 9am to 7pm and nobody replies on WhatsApp until the next morning, you paid for clicks that cooled off.

Decide who owns replies during ad hours, what a good first reply looks like, and how you hand a lead to sales or the technician. A short reply template is enough: thank them, confirm the service area, ask one clarifying question, and offer the next step.

6. Set a learning budget and a review date

You do not need a huge budget to learn. You do need enough clicks for Google to show patterns, and a fixed date when you will look at the numbers with a clear head.

Write down before launch:

Daily or monthly spend cap you can afford to treat as a test
The locations and search themes that are in scope
What you will pause if cost per useful lead stays too high after two weeks of clean data
What "good enough to continue" looks like in your own numbers, not a blog post's averages

Ignore vanity metrics for that review. Clicks and impressions matter only as the path to the lead definition you wrote in step one.

7. Separate brand searches from discovery searches

If people already search for your business name, protect that with a small brand campaign so competitors cannot sit on it cheaply. Keep non-brand campaigns (service + city keywords) in their own structure so you can see what new demand actually costs.

That split also stops you from celebrating "cheap leads" that were going to call you anyway.

How this fits together

Ads amplify whatever system you already have. A clear offer, a matching page, working tracking and a human who answers will make a modest budget useful. Missing any one of those will make a large budget look like proof that "ads don't work."

If you want a plain overview of how we structure Google Ads, Meta Ads and tracking for Ranchi businesses, we describe the approach on our digital marketing agency in Ranchi page. Use it as a reference for the setup questions a team should ask you, not as a substitute for finishing this checklist yourself.

Turn the ads on only after the checklist is done. The clicks will wait a day. Fixing a broken funnel after the money is gone is much harder.

Bio: Akhil Baraik is the founder of Crework Tech, an IT and digital marketing agency in Ranchi, India. The firm has 7+ years of experience and a 90% client retention rate, and builds websites, web apps, mobile apps and custom software alongside SEO and digital marketing.

What to Put in a Website Brief Before You Hire a Developer

Akhil Baraik — Thu, 15 Oct 2026 04:41:17 +0000

I run an IT and digital marketing agency in Ranchi. Most of the website projects that go wrong for small businesses do not go wrong in the code. They go wrong in the first week, when nobody wrote down what the site was supposed to do.

A website brief is that write-up. It does not need to be long or technical. One or two pages in plain language is enough. It is the document you share with every agency or freelancer so they quote on the same thing, and so you have something to check against when the first design comes back.

Here is what I ask clients to put in it before we start.

1. What the business does, in one paragraph

Say who you serve and what you sell or offer. Mention the city or area if that matters for your customers. Skip slogans. "We repair commercial ACs across Ranchi and nearby towns" is more useful than "Your trusted cooling partner."

2. Who the website is for

Name the main audience. Staff, walk-in customers, people comparing options on Google, partners, donors? If you have more than one audience, rank them. The homepage should speak to the primary one first.

Also note how people usually find you today: WhatsApp, Google Maps, referrals, Instagram. That tells us whether the site mainly needs to convert search traffic, support an existing conversation, or both.

3. The jobs the website must do on day one

List five to eight concrete jobs. Examples:

Show services and prices clearly enough that people stop asking the same questions on WhatsApp
Collect enquiries with name, phone and a short message
Display real photos of work or the premises
List opening hours and a map
Let customers book a slot or place an order
Publish blog posts or updates you will write yourself
Sell products online with payment and delivery options

Separate "must have for launch" from "nice later." A smaller first version ships sooner and costs less. You can always add a shop or a booking system in phase two.

4. Pages you already know you need

A typical small-business site needs a home page, an about page, a services or products section, a contact page, and often a FAQ. Add case studies, a blog, careers or a client login only if you will keep them updated.

If you already have rough copy or a competitor site you like the structure of, link it. Say what you like about it ("clear service cards", "simple contact form") rather than "make it look like this."

5. Brand and content you already have

List what exists:

Logo files (preferably SVG or high-resolution PNG)
Brand colours and fonts, if any
Photos you own the rights to
Existing text from brochures or social posts
Domain name and where it is registered
Any current website URL, even if it is outdated

If you have no logo or photos yet, say so. It is better to plan for that in the timeline than to discover it in week three.

6. Technical and business constraints

Write down anything that will affect the build:

Must work well on mobile (assume yes for almost every Indian business)
Languages: English only, or Hindi as well?
Who will update content after launch — you, your staff, or the agency?
Any tools it must connect to (WhatsApp, payment gateway, Google Analytics, CRM, Tally)
Hosting preference, if you have one
Rough budget range and ideal go-live date
Compliance needs (for example, a privacy policy, or healthcare/education rules)

You do not need to choose WordPress vs custom code yourself. A good team will recommend that after reading the brief. What they need from you is the constraints.

7. Success looks like…

Finish with how you will judge the site three months after launch. Examples: more qualified WhatsApp enquiries, fewer repeated phone questions, the ability to send a single link instead of a PDF, or a working online store. Clear goals keep the design and the copy honest.

How to use the brief

Send the same brief to every vendor you speak to. Compare quotes against it. When the first design or staging link arrives, check it against the "jobs on day one" list before you debate colours.

If you want a sense of how a structured website project usually runs from discovery through launch, we outline our approach on our website development in Ranchi page. Use that as a reference for the kinds of questions a team should ask you, not as a substitute for your own brief.

A clear brief will not make a weak vendor excellent. It will make a good vendor faster, and it will make a bad quote easier to spot. That alone is worth the hour it takes to write.

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.