When custom is the right answer
Custom development pays for itself when the software is part of how you serve customers, not just how you describe yourself. In practice that means one of these:
- Booking and availability. Rooms, tours, appointments or classes where the calendar, capacity and payment have to agree with each other.
- Calculators and quoting. Loan, insurance, freight, remittance or fee calculators where the logic is your own and a plugin cannot express it.
- Member or client portals. Logins, documents, statuses and permissions, where different users must see different things.
- Integrations. Connecting the website to a CRM, an accounting system, a payment gateway or a supplier feed so data stops being retyped.
- Directories and listings with search, filters and submissions that have to stay fast at thousands of records.
- Internal tools that live next to the site. Where the tool is mostly workflow rather than a public website, internal tool and dashboard development is usually the cheaper route.
When it is the wrong answer
If the requirement is a brochure site with a contact form, custom code costs more to build, more to maintain and more to hand to the next developer, for no gain. That belongs on WordPress development. A shop with standard products and shipping belongs on eCommerce website development. I will tell you when your requirement is a plugin rather than a project; losing that quote is cheaper for both of us than building something you have to maintain for five years.
How a custom build runs
- Discovery and scope (one to two weeks). I map the flows, the user types, the data and the rules, and write them down as a specification. The specification is a deliverable in its own right; if you take it elsewhere, it still works.
- Fixed quote and plan. Priced against that specification, with phases, dependencies and what is explicitly out of scope. Anything discovered later is quoted as a change, not absorbed silently.
- Build in phases. Working software you can open at the end of each phase, starting with the flow that carries the money.
- Testing. Real data, real edge cases and a real phone on a Nepali mobile connection. Payment flows are tested in the gateway’s sandbox and then with a live transaction before launch.
- Launch. Staged release, monitoring, tracking verified, and a rollback plan written before it is needed.
- Handover. Source code in your repository, deployment documentation, an admin guide and a walkthrough for whoever maintains it next.
Scope decides the timeline. A calculator is weeks; a booking system with payments and a portal is months. I would rather quote the second honestly than the first optimistically.
What you receive
- A written specification, including the parts we decided not to build and why.
- The application, deployed, with the accounts and hosting in your name.
- Source code in your own repository from the first commit.
- Technical documentation: architecture, environment variables, deployment steps, third-party accounts.
- An admin guide for the people who use it daily.
- Analytics and error monitoring configured so failures are visible.
- A defined warranty period for defects after launch.
Decisions worth making early
- Who maintains it. Custom software needs an owner. If you have no developer and no budget for one, that argues for a smaller build on a standard platform.
- Payments. Nepali gateways and international cards have different requirements, and which ones you can use depends on your business registration and bank. Which gateway you end up on is settled at scoping with your bank, not at launch.
- Data and privacy. What personal data the system stores, where, for how long, and who can see it. Health, financial and identity data need a decision from you, in writing.
- The public site. Most projects are a marketing site plus an application. Keeping the marketing pages on WordPress and the application separate usually gives the best of both, and keeps the SEO side under web design and development.
- What happens if we stop working together. The answer should be “nothing breaks”, which is why the repository, the documentation and the accounts are yours from day one.
Pricing pointer
Custom builds are quoted after the discovery phase, because quoting before the specification exists produces a number that is wrong in one direction or the other. Discovery itself can be bought as a small fixed-price piece of work. Prices are on request. Hosting, gateway fees and third-party services are paid by you at cost.
Next step
Describe the flow you want in plain sentences: who does what, in what order, and what the system must remember. I reply within 4 business hours saying whether this needs custom development or a smaller solution, and what scoping it would involve.