DEV Community: Ankiit janggid

Why Every Growing Business Eventually Outgrows Excel

Ankiit janggid — Mon, 27 Jul 2026 09:05:34 +0000

If you've worked with small or medium-sized businesses, you've probably seen this scenario.

A company starts with:

One Excel spreadsheet
A few WhatsApp chats
Some sticky notes
A notebook on someone's desk

Everything works perfectly.

Then the business grows.

More customers.

More employees.

More orders.

More spreadsheets.

Suddenly, Excel isn't helping anymore—it's slowing the business down.

Over the years, I've noticed that many companies don't decide to build custom software because they want something fancy.

They build it because spreadsheets stop scaling.

Excel Isn't the Problem

Let's be clear.

Excel is an incredible tool.

I've used it for:

Budget planning
Reports
Data analysis
Quick calculations
Temporary business processes

The problem isn't Excel.

The problem is trying to run an entire business on top of it.

At some point, spreadsheets become your database, CRM, inventory system, finance tracker, reporting tool, and communication platform—all at once.

That's when things begin to break.

The Warning Signs

Here are a few patterns I've seen repeatedly.

📂 Multiple Versions Everywhere
customers.xlsx
customers_final.xlsx
customers_latest.xlsx
customers_latest_final.xlsx
customers_latest_final_v2.xlsx

Nobody knows which file is the correct one.

⌛ Hours of Manual Work

Employees spend hours every day:

Copying data
Updating reports
Searching customer records
Creating invoices
Sending reminders

Most of this work could be automated.

❌ Human Errors

One deleted row.

One incorrect formula.

One accidental overwrite.

A small mistake can affect hundreds of records.

🔒 No Real Access Control

Everyone has the spreadsheet.

Everyone can edit it.

Sometimes that's convenient.

Most of the time, it's risky.

📊 Reporting Takes Forever

Managers ask questions like:

How many new customers this month?
Which invoices are pending?
Which products sell best?

Instead of clicking a dashboard...

Someone spends half a day preparing a report.

What Changes With Custom Software?

Notice I said custom software, not necessarily an ERP that tries to solve every problem on day one.

Sometimes businesses only need a simple internal application.

For example:

Customer Management
Inventory
Billing
Appointment Booking
Employee Attendance
Loan Tracking
Internal CRM

Even one small system can eliminate hours of repetitive work every week.

The Biggest Misconception

Many business owners assume custom software is only for large enterprises.

That's no longer true.

Modern development frameworks, cloud infrastructure, and managed services have made custom applications much more accessible than they were ten years ago.

The bigger question usually isn't:

"Can we afford software?"

It's:

"How much is manual work costing us every month?"

Don't Replace Everything Overnight

One mistake I often see is trying to digitize every business process at once.

That rarely ends well.

A better approach is:

Identify the biggest bottleneck.
Build one module.
Let employees use it.
Collect feedback.
Improve it.
Expand gradually.

Small wins build confidence.

Build Software Around People

One lesson I've learned is that software projects fail when developers only think about features.

Great business software is about reducing friction.

It should make someone's day easier.

Not more complicated.

If employees need two weeks of training just to perform simple tasks, something probably went wrong.

Final Thoughts

Excel isn't your enemy.

It's one of the best productivity tools ever created.

But every tool has limits.

Once your business reaches a certain scale, spreadsheets become a temporary solution to a permanent problem.

That's usually the point where investing in custom software starts making sense.

Not because it's trendy.

Because your business has simply outgrown manual processes.

Have you ever replaced an Excel-based workflow with custom software?

Or have you inherited a project that was held together by dozens of spreadsheets?

I'd love to hear your stories.

webdev #programming #productivity #business

Website vs Mobile App: Which Should Your Business Build First in 2026?

Ankiit janggid — Fri, 17 Jul 2026 05:22:47 +0000

One of the most common questions I hear when someone is planning a new digital product is:

"Should we build a website or a mobile app?"

For many businesses, the first thought is:

"We need an app."

But do you really?

A mobile app can be powerful, but it isn't automatically the best starting point for every business.

Depending on your users, budget, business model, and product requirements, starting with a website or web application might actually be the smarter decision.

Here's how I think about it.

🌐 When Should You Build a Website First?

For most new businesses and startups, starting with a website or web application often makes sense.

Users Can Access It Instantly

A website doesn't require installation.

Someone can discover your business through:

Google
Social media
WhatsApp
Email
Online advertising
A shared link

One click, and they're there.

With an app, users need to find it in an app store, download it, install it, and then open it.

Every additional step creates friction.

Websites Are Better for Discoverability

If Google is an important customer acquisition channel for your business, having a website is essential.

Search engines can index your content and help potential customers discover your product or service.

For businesses relying on SEO, content marketing, or local search, a website is usually the better starting point.

Development Is Usually Faster and More Affordable

A responsive website can work across:

Desktop
Laptop
Tablet
Android
iPhone

You can serve users across multiple devices without necessarily building separate applications.

For a startup validating an idea or a business working with a limited initial budget, this can make a big difference.

Updates Are Easier

When you update a website, users can access the latest version immediately.

Mobile apps may involve:

Building a new release
Testing
App store submission
Review processes
Users updating the app

During the early stages of a product—when things change frequently—a web application can provide more flexibility.

📱 When Does a Mobile App Make More Sense?

There are situations where an app is absolutely the right choice.

Your Product Is Used Frequently

If customers interact with your product several times a week—or multiple times a day—an app can provide a much better experience.

Think about:

Banking
Food delivery
Fitness tracking
Messaging
Transportation
Productivity tools

Frequent usage makes installing an app worthwhile.

You Need Device-Specific Features

Mobile apps can provide deeper access to features like:

Camera
GPS
Bluetooth
Biometrics
Push notifications
Sensors
Background services

If these capabilities are central to your product, a mobile app may be the better option.

Push Notifications Are Important

Push notifications can be valuable for:

Order updates
Appointment reminders
Messages
Offers
Important alerts

But notifications need to provide genuine value.

Sending too many is also one of the fastest ways to get users to disable notifications—or uninstall your app.

Your Product Is Highly Personalized

Apps work particularly well when users log in frequently and interact with personalized information.

For example:

Customer dashboards
Employee apps
Student platforms
Membership apps
Financial products
Healthcare platforms

In these cases, an app can create a smoother and more focused experience.

⚖️ Website vs Mobile App: Quick Comparison
Factor Website Mobile App
Initial Cost Generally Lower Generally Higher
Development Time Faster Longer
Installation Not Required Required
SEO Strong Limited
Device Features Limited Strong
Push Notifications Limited Strong
Frequent Engagement Good Excellent
Updates Instant May Require Updates
Accessibility Any Browser Installed Devices
Maintenance Generally Simpler More Complex
🤔 What About Building Both?

Sometimes, both are necessary.

But that doesn't mean you need both on day one.

A practical approach could be:

Step 1: Build a website or web application.

Step 2: Launch it and start acquiring users.

Step 3: Observe how people actually use your product.

Step 4: Identify whether an app would significantly improve the experience.

Step 5: Build the app based on real user behavior.

This approach helps reduce risk and prevents you from spending money on something your customers may not actually need.

🚨 A Mistake I Often See

Some businesses decide they need an app simply because their competitors have one.

But having an app doesn't automatically create engagement.

Before building one, ask:

Why would someone install my app?

Then ask an even more important question:

Why would they keep it installed?

If your customers only interact with your business once every few months, asking them to install an app may create unnecessary friction.

A fast, well-designed mobile website might be enough.

💡 Start With the Problem, Not the Technology

Instead of saying:

"I want to build an app."

Start with:

"What problem am I trying to solve?"

Then think about:

Who are the users?
How often will they use the product?
How will they discover it?
What features do they actually need?
Do you need mobile hardware features?
What's the initial budget?
How quickly do you need to launch?

Once you answer these questions, the technology decision usually becomes much clearer.

My Simple Rule

If you're launching something new and still validating your idea:

Start with the simplest product that solves the core problem.

For many businesses, that's a website or web application.

If users engage frequently, need device-specific capabilities, or genuinely benefit from a dedicated mobile experience, build an app.

Sometimes, the answer is both.

But don't build both because every modern business is "supposed" to have an app.

Build them because your users actually need them.

Final Thoughts

A website and a mobile app aren't competitors.

They're different tools for different problems.

Your goal shouldn't be to choose the most impressive technology.

It should be to choose the solution that delivers the most value to your users while supporting your business goals.

Start simple.

Validate your idea.

Understand your users.

Then scale based on real needs.

Because the best software decisions aren't driven by trends.

They're driven by problems worth solving.

What do you usually recommend to clients: website first, mobile app first, or both?

I'd love to hear how other developers and founders approach this decision.

webdev #mobile #programming #startup

💰 How Much Does It Cost to Build Software in India in 2026? (A Practical Breakdown)

Ankiit janggid — Fri, 26 Jun 2026 11:29:17 +0000

Introduction

Most people ask one question before starting a software project:

"How much will it cost?"

The honest answer is...
"It depends."

But it doesn't have to be confusing.

Here's how software pricing actually works in 2026.

Factors That Affect Cost
Features
Design
Mobile vs Web
Admin Panel
Third-party APIs
AI Integration
Payment Gateway
Scalability
Maintenance
Approximate Pricing
Project Estimated Cost
Business Website ₹20k–₹80k
Company Website ₹30k–₹1L
E-commerce Store ₹75k–₹4L
Custom CRM ₹1L–₹10L+
Mobile App ₹1L–₹15L+
AI Integration Depends on usage
Biggest Mistake

Don't choose the cheapest developer.

Choose the developer who understands your business.

Cheap software often becomes expensive later.

How to Reduce Cost
Build MVP first
Prioritize features
Reuse existing services
Keep the first version simple
Avoid unnecessary complexity
Conclusion

Software is an investment, not an expense.

A well-built product saves time, increases revenue, and grows with your business.
The question shouldn't always be:

"How much does it cost?"

It should also be:

"What value will it create?"

I'd love to hear your perspective.

How do you estimate software costs for clients? Or, if you're a business owner, what has been your biggest challenge when budgeting for software development?

webdev #softwaredevelopment #programming #india #startup #webdevelopment #mobileapp #business #technology #developers

Why I Often Tell Clients Not to Build a Mobile App (At Least Not Yet)

Ankiit janggid — Thu, 18 Jun 2026 11:58:19 +0000

When business owners reach out to discuss a new digital product, one request comes up surprisingly often:

"We need a mobile app."

And in many cases, my response is:

"Maybe. But probably not yet."

That answer usually surprises people.

After all, some of the world's biggest companies have successful mobile apps. So shouldn't every business have one?

Not necessarily.

Over the years, I've worked with businesses across different industries, and I've noticed a common pattern: many companies rush into mobile app development before solving more important business problems.

In this article, I'll explain why I often advise clients to focus elsewhere first—and when building a mobile app actually makes sense.

The Mobile App Myth

Many businesses assume:

Mobile App = More Customers
Mobile App = Faster Growth
Mobile App = Better Business

Unfortunately, that's rarely true.

A mobile app doesn't automatically create demand.

If customers aren't actively using your service today, launching an app won't magically change that.

Technology should support a successful business model—not replace one.

What Most Businesses Actually Need First

Before investing in a mobile application, I usually ask a few questions.

Do You Have a Strong Website?

For many businesses, a website is still the most valuable digital asset.

A good website helps customers:

Discover your business
Understand your services
Build trust
Contact you
Make purchasing decisions

A website is searchable, easy to update, and usually much more cost-effective than maintaining mobile applications.

Do You Understand Your Customers?

A successful app solves a specific problem.

Before building anything, businesses should know:

Who their users are
What challenges they face
How they currently interact with the business
What would make their experience better

Without this information, app development often becomes an expensive guessing game.

Do Users Need Frequent Access?

Mobile apps make sense when users interact regularly.

Examples include:

Food delivery services
Banking platforms
Fitness tracking apps
Messaging applications
Ride-sharing services

If customers only visit your business occasionally, a well-designed website may be all they need.

The Hidden Costs of Mobile Apps

Many people focus only on development costs.

However, launching the app is often the easiest part.

Ongoing costs include:

Bug fixes
Operating system updates
Security maintenance
Performance monitoring
App Store management
Feature updates

A mobile app is not a one-time investment.

It's a long-term commitment.

When Building a Mobile App Makes Sense

There are situations where I strongly recommend mobile applications.

For example:

Frequent User Engagement

If users interact with your service daily or weekly, an app can improve convenience and retention.

Push Notifications Matter

Apps are powerful when timely communication drives engagement.

Examples:

E-commerce offers
Order updates
Appointment reminders
Offline Access Is Important

If users need access without an internet connection, mobile apps become much more valuable.

Customer Experience Is the Product

Some businesses rely entirely on the mobile experience.

In these cases, an app is often essential.

The Smarter Approach

Instead of this:

Build Mobile App
↓
Hope Users Arrive

I usually recommend:

Build Website
↓
Validate Demand
↓
Grow Users
↓
Launch Mobile App

This approach:

Reduces risk
Saves money
Improves decision-making
Creates better products

Most importantly, it ensures you're building something users actually want.

Technology Should Follow Strategy

One of the biggest lessons I've learned over the years is this:

The smartest technology decisions are often the simplest ones.

Businesses don't need every new technology.

They need the right technology.

A mobile app can be a fantastic investment when the timing is right.

But for many businesses, the better first step is:

A strong website
Clear customer validation
Effective marketing
Sustainable growth

Once those foundations are in place, a mobile app becomes much easier—and much more valuable—to build.

Final Thoughts

I love building mobile applications.

But I also believe technology should solve real business problems.

Before investing in an app, ask yourself:

What problem am I solving?
Do my users actually need an app?
Am I building this because it creates value—or because it sounds impressive?

Sometimes the best decision is not building more technology.

It's building the right technology at the right time.

What do you think?

Have you seen businesses invest in apps too early—or do you believe every modern business should have one?

I'd love to hear your perspective in the comments.

About Me

I'm Ankiit Janggid, a Technical Consultant, Software Developer, and Entrepreneur passionate about helping businesses build practical digital solutions.

🌐 Website: https://ankiitjanggid.online

webdev

business

startup

mobile

How I Host Multiple Node.js Applications on a Single AWS Lightsail Server

Ankiit janggid — Fri, 12 Jun 2026 12:01:18 +0000

A few years ago, whenever I started a new project, I thought:

"This project needs its own server."

After a while, that approach became expensive, difficult to manage, and honestly unnecessary for many business applications.

Today, I host multiple Node.js applications on a single AWS Lightsail instance using Apache Virtual Hosts and PM2.

This setup has helped me reduce infrastructure costs, simplify deployments, and manage projects more efficiently.

Here's how it works.

Why I Chose AWS Lightsail

For many business applications, AWS Lightsail provides:

Predictable pricing
Full server control
Easy scalability
Good performance for small and medium projects

Instead of spinning up separate servers for every client or internal application, I consolidate multiple applications on a single instance.

My Architecture

The basic flow looks like this:

Internet
│
▼
Apache Reverse Proxy
│
┌──┼───────────┐
│ │ │
▼ ▼ ▼
App 1 App 2 App 3
3001 3002 3003

PM2

Apache handles incoming traffic and routes requests to the correct application.

PM2 keeps all Node.js applications running.

Folder Structure

I typically organize projects like this:

/var/www/
├── client-project-1
├── client-project-2
├── internal-app
└── admin-panel

Each project has:

Separate repository
Separate environment variables
Separate PM2 process

This keeps deployments clean.

Why PM2 Is Essential

Running Node.js applications directly is risky.

If the process crashes, your application goes offline.

PM2 provides:

Auto restart
Monitoring
Logs
Startup scripts
Process management

Example:

pm2 start server.js --name client-project-1
pm2 save
pm2 startup

After a reboot, everything comes back automatically.

Apache Virtual Hosts

Each domain points to a different internal port.

Example:

ServerName project1.com

ProxyPass / http://localhost:3001/
ProxyPassReverse / http://localhost:3001/

Another application:

ServerName project2.com

ProxyPass / http://localhost:3002/
ProxyPassReverse / http://localhost:3002/

The user never sees the internal ports.

Everything feels like a normal website.

Biggest Benefits
Lower Costs

Instead of paying for multiple servers, several projects can share one instance.

Easier Maintenance

One server.

One monitoring setup.

One backup strategy.

Faster Deployments

Deployments become predictable and repeatable.

Better Resource Usage

Most business applications never fully utilize an entire server.

Mistakes I Learned to Avoid

A few mistakes I made early on:

Running applications without PM2
Exposing internal ports publicly
Forgetting SSL configuration
Mixing all projects in one folder
Not monitoring logs

Fixing these made the setup much more stable.

When I Wouldn't Use This Setup

I would choose dedicated infrastructure when:

Traffic becomes very high
Security requirements are strict
Applications consume significant resources
Microservice architecture becomes necessary

For many small and medium business projects, though, a single Lightsail instance works surprisingly well.

Final Thoughts

One of the biggest lessons I've learned is that infrastructure doesn't need to be complicated.

A simple combination of:

AWS Lightsail
Apache
PM2
Node.js

can power multiple production applications reliably and cost-effectively.

How are you hosting your Node.js applications today?

I'd love to hear your setup in the comments.

node

aws

devops

webdev

# 7 Mistakes That Make Software Projects Fail (And How to Avoid Them)

Ankiit janggid — Tue, 09 Jun 2026 07:52:23 +0000

Over the years, I've worked on software projects ranging from simple business applications to large-scale platforms.

One thing I've learned is that most software projects don't fail because developers can't write code.

They fail because of poor planning, unclear requirements, communication gaps, and unrealistic expectations.

In fact, many projects are already heading toward failure before development even begins.

Here are the seven most common mistakes I've seen and how businesses can avoid them.

1. Starting Development Without Clear Requirements

Many projects begin with an idea but no documented requirements.

This usually leads to:

Scope confusion
Frequent changes
Budget overruns
Delayed delivery

A few days spent defining requirements can save weeks of development time later.

2. Focusing on Features Instead of Problems

Teams often ask:

"What features should we build?"

A better question is:

"What problem are we solving?"

The most successful products focus on solving real user problems rather than simply adding more features.

3. Ignoring User Experience

A technically perfect application can still fail if users struggle to use it.

Good software should feel simple, intuitive, and fast.

4. Poor Communication Between Stakeholders

I've seen projects where:

Clients assume developers understand everything.
Developers assume business goals are clear.
Teams work with outdated information.

Regular communication prevents expensive misunderstandings.

5. Constant Scope Changes

New ideas are great.

But uncontrolled scope changes can quickly derail a project.

Every new feature should be evaluated against:

Business value
Timeline impact
Development effort

6. Treating Testing as an Afterthought

Testing shouldn't happen only at the end of a project.

The earlier bugs are found, the cheaper they are to fix.

7. Choosing Speed Over Scalability

Many businesses want everything delivered immediately.

While speed matters, ignoring scalability often creates larger problems later.

A balanced approach is usually the best approach.

Final Thoughts

Technology rarely causes projects to fail.

Planning, communication, and execution do.

The good news is that most of these mistakes are preventable.

Before starting your next software project, invest time in planning, communication, and understanding your users.

Your future self—and your development team—will thank you.

What project management mistakes have you seen most often?

I'd love to hear your experiences in the comments.

webdev

programming

softwareengineering

projectmanagement

Why Most Software Projects Fail Before Development Starts

Ankiit janggid — Mon, 01 Jun 2026 12:27:37 +0000

Most people think software projects fail because of bugs, bad code, or poor developers.

In reality, many projects are already on the path to failure before a single line of code is written.

Over the years, I've noticed a pattern: teams spend months discussing technologies, frameworks, and features, but very little time understanding the actual problem they're trying to solve.

As a result, development starts with confusion, changing requirements, unrealistic expectations, and unclear goals.

Here's why it happens.

1. Nobody Defines the Real Problem

Many projects begin with statements like:

"We need a mobile app."
"Let's build a CRM."
"We want AI in our product."

But these are solutions, not problems.

Before writing code, teams should answer:

What business problem are we solving?
Who are the users?
What pain point exists today?
How will success be measured?

Without clear answers, even a technically perfect product can fail.

2. Requirements Exist Only in Conversations

One of the most expensive mistakes is relying on verbal discussions.

Clients explain features.
Developers interpret them.
Designers imagine them.

Everyone ends up with a different understanding of the same requirement.

This leads to:

Rework
Delays
Budget overruns
Frustration on both sides

Documenting requirements early saves countless hours later.

3. Teams Focus on Features Instead of User Experience

Many projects become feature collections.

Dashboards.
Notifications.
Reports.
Integrations.

But nobody maps the actual user journey.

Questions that should be answered first:

How does a user sign up?
What is the first action they take?
What happens if something goes wrong?
How do they achieve their goal?

Great software feels simple because someone planned the experience before development started.

4. Scope Changes Every Week

When planning is skipped, requirements keep changing.

A feature gets added.
Another feature gets modified.
Priorities shift.

Soon the project becomes larger than originally estimated.

This phenomenon, known as scope creep, is one of the biggest reasons software projects exceed budgets and deadlines.

5. There Is No MVP Strategy

Many businesses try to build everything in Version 1.

The result?

Long development cycles, higher costs, and delayed launches.

Successful products usually start with an MVP (Minimum Viable Product).

The goal is simple:

Build the smallest version that delivers real value, gather feedback, and improve based on actual user behavior.

6. Technical Planning Is Ignored

Questions like these often appear too late:

How will the system scale?
What database structure should be used?
How will security be handled?
What happens when traffic grows?

Fixing architecture mistakes after launch is far more expensive than planning them beforehand.

What Successful Projects Do Differently

Successful software projects spend time on:

✅ Requirement gathering

✅ User journey mapping

✅ Wireframes and planning

✅ Technical architecture

✅ MVP definition

✅ Clear success metrics

Only after these steps does development begin.

Final Thoughts

Software development isn't just about writing code.

It's about solving problems efficiently.

The strongest projects are usually the ones that invest heavily in planning before development starts.

Before starting your next project, ask yourself:

"Have we clearly defined the problem, the users, and the path to success?"

If not, the next step probably isn't coding.

It's planning.

About Me

I'm Ankit Jangid, a software developer focused on Node.js, APIs, business software, and digital products.

🌐 Portfolio: https://ankiitjanggid.online