Professional Services systems built around real operations.

Start by trying to buy it. If a supported product covers the process closely and the objection is cosmetic, buy it — configuration is always cheaper than construction. Custom work earns its cost in three situations: the process is genuinely part of how you compete, licence costs scale badly against your user count, or integration and data ownership requirements exceed what the product permits. A fourth situation is worth naming because it is common and it is a trap: the process itself is undefined, and software is being asked to settle an argument nobody has had. That never works, and it is expensive to discover late.

A prototype tests one assumption and is meant to be thrown away — it can be ugly, hardcoded and unsafe because nobody real will use it. An MVP is a minimal operable product for actual users, which means it still needs authentication, authorisation, error handling, a way to see what people are doing and a route to fix bad data. Version one is what you build once the MVP has told you which assumptions were wrong. Conflating the first two is the most expensive mistake in this sequence: building an MVP to prototype standards produces something that cannot be operated, and building a prototype to MVP standards wastes months proving something you could have learned in a week.

Frequently, and it often produces a better result than replacing them, because they hold context nobody else has. What makes it work is a clear boundary — which system, which repository, which decisions belong to whom — and agreement on how code is reviewed and merged. What makes it fail is ambiguity about ownership, especially when something breaks and two teams each assume the other was watching. Access to environments and repositories needs settling at the start rather than negotiated per task, and it is worth agreeing early how disagreements about technical direction get resolved, because they will happen.

By reducing what is unknown before quoting, rather than padding a number to cover it. Requirements that are genuinely settled can be estimated with reasonable confidence. Requirements that are not — an unfamiliar integration, an undefined process, an unproven assumption about users — get a paid discovery step that produces a defensible scope. A fixed price quoted against uncertainty does not survive contact with the real system; it either gets renegotiated, which damages trust, or gets delivered thin, which damages the product. The honest sequence is to make the uncertain parts certain first, then price the rest.

Nothing, because it was never held anywhere you do not control. Repository, environments, database, domain and third-party service accounts should be in your organisation's name from the first day, not transferred at the end. Source code is delivered with schema and migration history, deployment steps, environment documentation and known limitations. The practical test of a handover is whether a different developer could take over from what you were given, without needing to ask us anything — and that is worth confirming during the project rather than at the point you need it.

It varies with what the system does, but a common planning figure is fifteen to twenty-five percent of build cost annually — and budgeting nothing is how working software becomes unsupportable. That covers dependency and security updates, defect response, monitoring, backups with tested restores, and the small changes every system needs as the business changes around it. Software that sits untouched for a year usually needs significant remedial work before it can ship again, because dependencies move, platforms deprecate APIs and security disclosures accumulate. Continuous small maintenance is consistently cheaper than periodic catch-up.

Usually, and it starts with an audit rather than a quote. That means establishing what it runs on, whether the source is complete, whether it can be built and deployed from scratch, what the dependency and version state is, whether backups actually restore, and what is undocumented. The audit is chargeable work and produces a written risk picture. The complications that matter are undocumented modifications, dependencies that can no longer be installed, and environments nobody can reconstruct — each of those needs a decision before an ongoing arrangement means anything.

As a build requirement rather than a review at the end. Server-side authorisation on every request regardless of what the interface prevents, validated input at every boundary where untrusted data enters, parameterised queries, secrets in encrypted storage with a documented rotation procedure, and dependency scanning in the pipeline. Beyond the code: least-privilege access to environments, audit logging on consequential actions, and a tested restore path. The gaps that show up most often in real systems are not exotic — they are missing authorisation checks on endpoints nobody expected to be called directly, and credentials that were committed once and never rotated.