Small businesses already have ways of getting work done.
There is usually a calculator somewhere on the counter. A notebook with customer balances. WhatsApp for sharing bills. Maybe Excel for keeping track of something important. And a surprising amount of information that simply lives in the owner's head.
It works.
Until the business gets busier.
Until someone forgets a payment.
Until stock doesn't match.
Until it's the end of the month and someone needs to understand exactly what happened.
That was one of the problems we kept thinking about while building Vyapar.
We weren't interested in building another piece of software filled with screens, settings and features simply because business software is expected to have them.
We started with a simpler question:
Can software fit around the way a business already works instead of forcing the business to change the way it works?
That question continues to shape Vyapar.
The problem wasn't a lack of software
There is already a lot of business software available.
Billing software. Accounting software. Inventory software. CRM systems. ERP systems.
The challenge isn't always finding software.
The challenge is finding software that someone actually wants to use every day.
For a small shop owner, a technically powerful application isn't necessarily a useful application.
If creating a simple bill takes too many steps, the software has already made the person's work harder.
If checking how much a customer owes requires opening three different screens, something is wrong.
And if someone needs training before they can perform tasks they were already doing comfortably in a notebook, we've probably introduced complexity instead of removing it.
That's something we've tried to keep in mind while building Vyapar.
We started with the counter, not the dashboard
When you're building business software, it's easy to start with dashboards.
Revenue graphs.
Sales charts.
Analytics.
Reports.
They look impressive.
But that's rarely where someone's working day begins.
For many businesses, the day begins with a customer standing at the counter.
They need an item.
The quantity needs to be entered.
A bill needs to be generated.
Payment needs to be recorded.
And there may already be another customer waiting.
That moment matters more than almost anything we could put on a dashboard.
So we started thinking about smaller questions.
How quickly can someone create a sale?
How easily can they find an existing customer?
Can they immediately understand what that customer still owes?
Can they send the invoice without downloading it, finding it and uploading it somewhere else?
Individually, none of these sounds revolutionary.
Together, they determine whether software feels useful or frustrating.
Simple software is difficult to build
“Keep it simple” sounds like easy advice.
In practice, simplicity is one of the hardest parts of product development.
Every new feature introduces another decision.
Every new setting creates another thing someone has to understand.
Every new field on a form adds a little more friction.
Adding functionality is often easier than deciding what shouldn't be there.
While building Vyapar, we regularly come back to one question:
Does this make the user's work easier, or does it simply make the product look more powerful?
Those aren't always the same thing.
A product doesn't become better simply because it has more options.
Sometimes the better product is the one that understands what the user is trying to do and gets out of the way.
Udhaar is a workflow, not just a number
One thing that makes Indian businesses interesting to build for is how much business happens through relationships.
A regular customer buys something today and pays later.
Maybe they pay everything next week.
Maybe they pay part of it.
Maybe they come back and purchase something else before clearing the previous amount.
Everyone involved understands this naturally.
Software sometimes doesn't.
Something as familiar as udhaar can quickly turn into invoices, payments, outstanding balances, ledger entries and accounting terminology.
The technology underneath may need to handle all of that.
The person using it shouldn't have to think about all of it.
If a customer owes ₹5,000 and pays ₹2,000, the important information is simple:
₹3,000 is still pending.
The product should make that obvious.
This is a small example, but it reflects something bigger we believe about software.
Complexity can exist underneath the product without being pushed onto the user.
Real businesses change your product decisions
Products look different when they're discussed inside a meeting room.
Everything can seem logical on a whiteboard.
Then someone uses the product while answering a phone call, speaking to a customer and checking stock at the same time.
Suddenly the button that seemed obvious isn't obvious.
The form that seemed short feels too long.
The feature that seemed essential doesn't matter.
And something the development team thought was minor becomes one of the most important parts of the product.
That's why we're interested in getting our products in front of real users as early as possible.
We want to understand where people hesitate.
What they ignore.
What they use differently from how we expected.
And what makes them say:
“This should be easier.”
Those moments teach us more than adding another feature to a roadmap.
We're still learning
Vyapar is still evolving.
There will be things we get right.
There will be things we change.
There will probably be features we build and later simplify or remove altogether.
That's part of building a product around real people instead of assumptions.
We're not trying to tell businesses how they should operate.
We're trying to understand how they already operate and use technology to make the difficult parts a little easier.
For us, that's what good business software should do.
It shouldn't demand attention.
It should quietly help people get their work done.
And that's the direction we're building Vyapar toward.