Map the process
How it runs today, including the workarounds and the awkward exceptions. Most of the value is found here, and some projects sensibly end here.
Custom Software · Delhi NCR & remote
The best outcome is sometimes talking you out of it.
Custom software is expensive to build and expensive to keep alive. A good share of the projects described to me would be better solved by a tool that already exists, and saying so is part of the job.
Short answer
Custom software development builds a system around how your business actually works, rather than adapting your process to an off-the-shelf product. It is worth doing when your process is genuinely distinctive, when licence costs have overtaken build costs, or when data is being retyped between systems every day.
Consultation before code
Source code is yours
PHP and MySQL
Support in year three
Free scoping call
Get a free quote
Four details. A real reply the same day, from me.
Software, or just a better tool?
Get a Free Quote
WhatsApp
01 The premise
When building genuinely wins.
Off-the-shelf software is one of the great bargains available to a business. The development cost is spread across thousands of customers, it is maintained by somebody else, and it works on the day you buy it. Any argument for building something custom has to beat that, and frequently it does not.
The cases where it does are specific rather than general. Your process is genuinely a competitive advantage and no product models it. You are paying per seat for software where your team uses a tenth of the features. The same data is retyped between three systems every day. Or the tool you depend on is being discontinued and there is no export path out of it.
Notice what is not on that list: wanting something that looks nicer, or a general feeling that the current system is frustrating. Those are real feelings and they are usually cured more cheaply by configuration, training, or one integration than by a build. I would rather establish that on a first call than eight weeks into a project.
02 Straight talk
Build, or buy.
The honest test, applied before anybody writes a line of code.
Build it
- The process is the advantage. How you do it is part of why customers choose you. That deserves modelling properly.
- Licence costs have overtaken build costs. Per-seat pricing across a growing team, for features you do not use.
- Data is retyped daily. The clearest and most measurable signal there is.
- No product fits without a workaround. And the workaround is now a documented part of how people work.
Buy instead
- A product covers most of it. Eighty per cent at a tenth of the cost is usually the right trade.
- Your process is standard. Accounting, payroll and CRM are solved problems. Building them again rarely pays.
- Nobody will own it. Custom software needs an owner on your side. Without one it decays quickly.
- You need it next month. Custom work has a real timeline. If the deadline is fixed, buy and revisit later.
03 Process
How a build stays finishable.
Software projects fail by growing, not by being technically difficult. Every step here is designed against that.
Decide build or buy
An honest comparison against products that already exist. If one covers most of it, that is my recommendation.
Scope version one
The smallest system that solves the worst problem, at a fixed price. Everything else goes on a list, deliberately.
Build in short cycles
Something clickable at the end of each cycle. Your team tests with real data rather than sample data.
Deploy and hand over
Training, documentation, backups and a support arrangement. Software nobody can maintain was never finished.
Free scoping call
Describe the process that keeps breaking.
The file three people edit, the data typed twice, the thing that only works because somebody remembers it. That description tells me whether you need software or a better tool.
- I will talk you out of it if that is right
- Fixed price for a defined first version
- Source code and database are yours
- Same-day reply, all 7 days
Free scoping
Get a free quote
Four details, and a real reply today.
04 Ownership
What you own at the end.
All of it, without a negotiation.
- The source code
- In your repository or on your server, in your name, commented and structured conventionally.
- The database
- Schema and data, exportable, documented where anything is non-obvious.
- The documentation
- How it works and how to deploy a change, written for a developer who is not me.
- The right to leave
- Another developer can take it over. I will help with that handover rather than obstruct it.
- A conventional stack
- PHP and MySQL, which thousands of Indian developers can maintain. You are not buying a system only I can read.
— Custom Software
Related services.
These sit next to custom software and are usually bought with it. Same person doing the work in each case.
— Questions
custom software — your questions.
Straight answers, including the ones that cost me work. If yours is not here, ask it — I reply the same day.
Buy, unless your process is genuinely different from what products assume, or you are paying heavily for features you never use. Custom earns its cost when the process itself is a competitive advantage. I would rather say that on the first call than eight weeks into a build.
It scales with the number of distinct processes, user roles and integrations rather than with the number of screens. I scope a fixed price for a defined first version after a mapping session, so you are not signing an open-ended hourly commitment.
A focused first version is usually weeks rather than months, which is deliberate — long projects are where scope grows and budgets fail. Getting something small into real use early tells you more about what to build next than any requirements document.
PHP with MySQL for most business systems. That is a pragmatic choice rather than a nostalgic one: it runs on ordinary hosting, any competent developer in India can maintain it, and it does not tie you to one vendor. Where a project genuinely needs something else, I will say so.
It is the right question to ask a single developer. The answer is documentation and conventional technology — commented code, a documented database, and a stack thousands of developers know. You are not dependent on me specifically.
Sometimes. It depends on whether the code is comprehensible and the database sane. I will review it and give you a straight assessment, including the case where maintaining it will cost more than replacing it.
Free consultation · No obligation
Start with the process, not the features.
One call, no charge. You will get a straight answer about whether this needs custom software, an existing tool, or one integration between two things you already pay for.
- I will recommend buying when that is right
- Fixed scope and price for version one
- Source code and database stay yours
- A stack any developer can maintain
Start here
Send your enquiry
Name, number, email, what you need.