If a spreadsheet is genuinely fine, I will say so
Some processes do not need software. They need one person to own them and a shared file. Building a portal for that wastes your money and my time.
About
EaseBuddy is a small software studio in Gujarat, India. Every module and every system on this site was written from scratch, deployed personally, and fixed personally when something broke at 9am on a Monday.
The story
The first real project was an operations portal for a multi-unit hospital group — stock reorder, purchase approvals, an item master, work logs and recruitment, all of which were being run out of files passed around on WhatsApp.
Once that was live, something unexpected happened. The attendance and HR part of it was the piece every other business asked about. So it was pulled out and rebuilt properly as a standalone, multi-tenant HRMS with its own mobile app.
That set the pattern. Each new client had a requirement that overlapped with something already built. Rather than starting over each time, the overlapping pieces became proper modules — nine of them now, each running in production somewhere, each able to stand on its own or sit alongside the others.
That is the whole idea behind EaseBuddy: you should not have to pay for a system to be invented from nothing when eighty per cent of it already exists and has been tested by real staff for a year.
Who you are working with
I build ERP modules, web applications and Flutter apps for growing businesses in Gujarat — manufacturing, distribution, services, retail and healthcare — end to end. The requirement call, the schema, the code, the server it runs on, and the 9am phone call when something breaks. There is no team to hand you off to.
Most of what is on this site came out of one multi-unit hospital group: an eighteen-module operations portal, an HRMS that outgrew it and became a product of its own, and a pipeline that got a finance team their daily numbers out of a platform with no export button. The modules that came out of it are sector-neutral — they suit any multi-branch business.
Whichever stack fits the problem — always deployed on your own server, with the source handed over.
Straight talk
Most of this business is won by agreeing with the client. I would rather be useful than agreeable — it is why the systems I build tend to still be running years later.
Some processes do not need software. They need one person to own them and a shared file. Building a portal for that wastes your money and my time.
Accounting, payroll, ticketing — mature products exist and cost less than a custom build. Custom is for the part of your business nobody else has.
Before the contract, not three months in. A date that was never achievable helps nobody, and everyone in the room usually knows it already.
How I work
I ask to watch the person who actually does the job. The register, the group chat, the workaround nobody mentions — the real rules are always in there.
Screens, scope and a delivery plan in writing before development starts, so cost and sequence are agreed rather than assumed.
Into production, used by real staff. Every release is checked on the live server afterwards, with a timestamped backup kept for instant rollback.
Your server, your database, your source code, documented. Support if you want it — but you are never stuck with me to keep the lights on.
What you own
This is the part worth reading twice, because it is where custom development differs most from buying seats in a platform.
Deployed on your AWS account or VPS. Not a shared environment I control, and not something that stops working if we lose touch.
Your data stays on your infrastructure, backed up on a schedule you can inspect. No export request, no data-portability clause needed.
Handed over with documentation. If you want a different developer to take it forward next year, nothing prevents that.
First call is thirty minutes and costs nothing. Come with the problem — you do not need a specification or a budget.