Describe what goes wrong
Not the solution — the symptom. The retyping, the delay, the thing nobody can find.
App Development · Delhi NCR & remote
The platform is the last decision, not the first.
Most software conversations start with the wrong sentence: we need an app. The useful version names the problem, and the platform then chooses itself.
Short answer
Custom application development builds software for a specific business need, with the platform — web, mobile, desktop or a combination — decided from the requirement rather than assumed at the start. Starting from the problem frequently changes the answer and usually reduces the cost.
Problem first, platform second
Honest platform comparison
Source code is yours
Fixed price for version one
Free scoping call
Get a free quote
Four details. A real reply the same day, from me.
Not sure what you actually need?
Get a Free Quote
WhatsApp
01 The premise
Start with the problem.
When somebody opens with “we need an app”, the platform has already been chosen before the problem has been described. Frequently the underlying need would be better served by a web application, or by connecting two systems that already exist, or by changing a process rather than building anything. Starting from the platform forecloses all of that.
The more useful opening is a description of what goes wrong. The data typed twice. The information nobody can find. The approval that stalls. The customer question that takes three people to answer. From there the platform question is usually straightforward, and the answer is frequently smaller and cheaper than what was originally imagined.
This is genuinely how the first conversation goes, and it is why it is free. A decent proportion of these conversations end with a recommendation that costs me the project — use this existing tool, connect these two systems, or fix the process first. That is a better outcome than building the wrong thing well.
02 Deciding
What the requirement points to.
Once the problem is described, the platform is rarely ambiguous.
| The requirement | What it points to |
|---|---|
| Several people, several places, occasional use | A web application. No install, works everywhere, one version. |
| Field staff, camera, location, offline | A mobile app. This is genuine app territory. |
| Connected hardware or fully offline | Desktop, or a local agent alongside a web system. |
| Data retyped between existing systems | An integration, not an application. Usually far cheaper than either. |
| A process nobody has agreed | Not software yet. Settle the process first or you will automate a disagreement. |
| A tool exists that does most of it | Buy it. I will tell you when this is the case. |
03 The conversation
How the first conversation goes.
No charge, and it frequently ends the matter.
Map the process
How it actually runs, including the workarounds. Most of the useful information is in the workarounds.
Consider not building
An existing tool, an integration, or a process change. Checked properly rather than dismissed.
Choose the platform
From the requirement. By this point it is usually obvious and occasionally surprising.
Scope version one
The smallest thing that solves the worst problem, at a fixed price, with the rest listed for later.
Free scoping call
Describe the problem, not the app.
Tell me what goes wrong and how often. The platform question usually answers itself from there, and the answer is frequently cheaper than what you had in mind.
- I will recommend not building when 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 Commitments
What you get whatever the platform.
The commitments are the same regardless of what gets built.
Always
- A fixed price for a defined version one. Not an hourly rate against an open scope.
- The source code and the database. Yours, in your name, from the start.
- A conventional stack. Technology your local market can hire for. You are not dependent on one person.
- Documentation. How it works and how to deploy a change, written for somebody who is not me.
- An honest recommendation. Including the one where you should not build anything.
- Support afterwards. Optional, never a condition, and never used to make leaving difficult.
— App Development
Related services.
These sit next to custom applications and are usually bought with it. Same person doing the work in each case.
App Development
The overview — and when to skip it.
Read moreAndroid App Development
Where India’s volume is.
Read moreiOS App Development
Where the spend is.
Read moreCross-Platform Apps
One codebase, two stores.
Read moreCustom Mobile Apps
Built for one business.
Read moreBusiness Apps
Internal tools for your team.
Read more— Questions
custom applications — your questions.
Straight answers, including the ones that cost me work. If yours is not here, ask it — I reply the same day.
From the requirement. Occasional use by several people points to web. Field work with camera, location and offline needs points to mobile. Connected hardware or genuinely offline operation points to desktop. Describing the problem usually settles it in one conversation.
That is the normal starting position and it is what the first conversation is for. Describe what goes wrong rather than what to build. The platform question is usually straightforward once the problem is properly described.
Yes, and it happens regularly. Frequently the answer is an existing tool, an integration between systems you already pay for, or fixing a process before automating it. Those recommendations cost me the project and they are the right advice.
It scales with the number of distinct processes, user roles and integrations rather than with the number of screens. I quote a fixed price for a defined first version after mapping the process, so you are not signing an open-ended commitment.
Frequently yes. A well-built web application works on both, and a progressive web app adds home-screen installation and offline capability. That covers a large share of what people mean when they ask for a web and mobile app.
It goes into real use, and what people actually complain about becomes the roadmap. That is considerably better information than a requirements document written before anybody used anything, which is why version one is deliberately small.
Free consultation · No obligation
Describe the problem. I will name the platform.
One call, no charge. Tell me what goes wrong and how often, and you will get a straight recommendation — including the one where you should not build anything.
- Problem first, platform second
- I will recommend not building when that is right
- Fixed price for a defined first version
- Source code and database stay yours
Start here
Send your enquiry
Name, number, email, what you need.