A software quotation tells you what the first release will cost to build. It may tell you much less about what happens after launch. Hosting, support, paid services and changes all need an owner and a budget. You do not need a perfect forecast, but you do need to know what can change the bill.
Separate building from running
Development usually covers an agreed scope: planning, design, coding, testing and deployment according to the proposal. Ongoing work can include monitoring, backups, updates, troubleshooting and new features.
Clarify the defect-support period after launch. A problem in an agreed feature and a newly requested business rule are different kinds of work. Your contract should explain how each is handled, rather than leaving the distinction to an urgent conversation later.
Hosting depends on how the application is used
Ask the developer what the hosting recommendation is based on. Relevant inputs include concurrent activity, database size, uploaded files, scheduled jobs and the consequences of downtime.
The number of registered users is not sufficient on its own. Twenty users uploading large files may create a different workload from hundreds who occasionally view simple records.
Also identify which services are separate. The application, database, file storage, backup storage and email delivery may have different charges. A demonstration server should not automatically become the long-term production setup.
External services can add variable charges
Maps, messaging, payment processing, document extraction and AI services may charge according to usage. Ask which functions rely on them and what happens if a limit is reached or the provider is unavailable.
For a hypothetical enquiry application, email notifications may be inexpensive compared with frequent document processing. The budget should follow the expected activity, not an assumption that every API costs the same.
Set usage monitoring and sensible limits where supported. Check the provider’s actual controls; an alert does not necessarily stop spending.
Support needs a defined scope
A maintenance arrangement is easier to evaluate when it explains what someone will do. Ask about backup checks, software updates, error investigation, response arrangements and the process for approving additional work.
Do not compare support packages by hours alone. Availability, responsibilities and exclusions affect the value. Confirm whether third-party subscription renewals and infrastructure management are included or billed separately.
For the development itself, review how Auspian approaches custom business systems and request a scope that separates delivery from ongoing support.
Changes should have their own budget
Businesses change. A report may need an additional filter, a new branch may require access controls, or an integration may change its requirements. These are easier to manage when there is a defined approval process and a record of requested changes.
Keep the first release focused. Building every possible feature immediately increases the development commitment and gives you more functionality to maintain before you know whether it is useful.
Questions to ask before signing
- What infrastructure is required at launch, and why?
- Which charges are fixed and which depend on usage?
- Who owns and renews the hosting and service accounts?
- How are backups retained and recovery tested?
- What does post-launch defect support cover?
- What maintenance is included, and how are changes quoted?
- What access and documentation will we receive?
Use the same period when comparing proposals. Twelve months of subscription charges cannot fairly be compared with a one-time build quotation that excludes a year of operation.
Build a simple first-year budget
Make a worksheet with four columns: item, charging basis, payer and renewal date. Put development in the one-time section. Put hosting and support in the recurring section. Add separate rows for services charged by activity, such as messages or AI requests.
For each variable item, record a low-use and higher-use assumption. These are planning scenarios, not promised costs. Ask the developer which assumptions are realistic and what monitoring is available. This turns a headline quote into something your business can actually plan around.
Frequently asked questions
Is an AMC compulsory for every application?
The support model depends on the contract and who will operate the system. Even without a developer AMC, maintenance responsibilities and a recovery plan still need an owner.
Can we use our existing hosting?
Possibly. Its resources, supported software, access and backup arrangements must be checked against the application requirements.
Does adding users always increase the bill?
Not necessarily. Usage, workload and any user-based third-party licensing matter. Ask which limits actually apply.
Bring your expected users, daily activity and file requirements to Auspian’s custom software team. Ask for development and ongoing responsibilities to be explained separately.
