When is bespoke software preferable to an existing product?

Compare the actual process, permissions, exchanges and total operating effort first. An existing product may fit well. Bespoke work becomes relevant where important gaps cannot reasonably be resolved, without assuming that it will always cost less over the lifetime of the system.

How would existing records enter a new platform?

A migration needs defined sources, mappings and result checks before a switch. Initial trials use synthetic material. Real records require an authorised environment, reconciliation of differences and a return plan that accounts for new writes rather than simply restoring an old copy.

What should the platform handover include?

Code rights, documentation, access, exports and transition support should be agreed from the start. Third-party dependencies and the steps required to operate the system must be identifiable. These are contractual deliverables to verify, not consequences of a general ownership promise.

Will the client portal work on a phone and with a keyboard?

Small screens and accessibility should be explicit design and acceptance criteria. Automated checks detect some defects but cannot establish complete accessibility. Review should also examine keyboard use, assistive reading, error recovery and the effort required to complete a longer task on a phone.

Custom platforms · Monaco

The portal and the back office need the same rules.

One case, distinct views

Diagram of a proposed workflow to build and verify. It does not represent a client case or an operating production service.

Client
Submit and consult their own material
Team
Work on assigned cases
Responsible officer
Examine actions requiring approval
Client update
Share only the approved information

A client request becomes work for a team, then a response or a decision. Our software engineering approach starts with that journey: what each person needs to see, what they can change and what happens next. With your organisation, we define the client portal, team tools and integrations to build, together with the checks needed before launch.

Connect the views without exposing everything

The portal is the client's view: a request to complete, a document expected or a result shared. The back office is the team's view: assignment, examination, correction and follow-up. Business rules connect them by defining case states and permitted transitions. A status change must mean the same thing in both places, even when each screen presents different detail and offers different actions.

The scope should also specify what remains internal, such as reviewer comments, working notes and material belonging to another case. These boundaries must apply at the data access layer. Removing a button does not protect a document whose address can still be opened. Verification therefore needs direct access attempts as well as the intended sequence of clicks through the interface.

Describe permission changes, not just fixed roles

A permission matrix should distinguish reading, editing, assignment and approval. It needs to cover departures, temporary replacements and clients linked to several cases. The system must enforce current rights on the server. A role declared in a browser, or a screen that was opened before access changed, should not become an alternative source of authority for later operations.

The intended event record should preserve useful context and authorship while avoiding unnecessary personal details. Its integrity, exports and retention need mechanisms that can be examined and tested. Calling a log immutable before those mechanisms exist would give an unsupported assurance. The design should explain which questions the record needs to answer and who is allowed to inspect it.

Make integration limits visible

An integration begins with the available interface, its permissions and authorised exchanges. Accounting, electronic signature, messaging and case management may have different constraints. A missing interface does not automatically justify replacing an application: a limited export or an explicit manual step may be the better fit. The scope should show those alternatives and their operational consequences before implementation is promised.

Failures belong in the workflow too: refused operations, late replies, duplicate requests and records changed since the previous synchronisation. Recovery should avoid repeating an external write. A future connection to Vedetta may support due diligence, but the product and its interfaces remain under development for all relevant Monaco professions. The proposed connection is not an available compliance service or an automatic decision mechanism.

Scope a complete first chain of work

A useful first release connects one task from entry to treatment, with acceptance criteria at both ends. Screen count does not reveal the complexity of importing existing records or enforcing a subtle permission. The quotation and schedule should include dependencies, verification and operational preparation. No standard number of weeks can stand in for the examination of those conditions.

The handover should leave the organisation able to understand and operate its platform: named accounts, documented data access, agreed code rights and a clear route for requesting changes. Recovery belongs in that package, with the information needed to restore the service and the people responsible for doing so. These details are agreed alongside the interface, so a change of staff or supplier does not depend on reconstructing undocumented decisions after the project has ended.

Examine the scope

Service outline

Proposed service scope

Explore how we plan a website or business application, from visitor journeys and content to delivery and handover.

Read the presentation

Text reviewed on September 5, 2026

Questions and answers

When is bespoke software preferable to an existing product?: Compare the actual process, permissions, exchanges and total operating effort first. An existing product may fit well. Bespoke work becomes relevant where important gaps cannot reasonably be resolved, without assuming that it will always cost less over the lifetime of the system.
How would existing records enter a new platform?: A migration needs defined sources, mappings and result checks before a switch. Initial trials use synthetic material. Real records require an authorised environment, reconciliation of differences and a return plan that accounts for new writes rather than simply restoring an old copy.
What should the platform handover include?: Code rights, documentation, access, exports and transition support should be agreed from the start. Third-party dependencies and the steps required to operate the system must be identifiable. These are contractual deliverables to verify, not consequences of a general ownership promise.
Will the client portal work on a phone and with a keyboard?: Small screens and accessibility should be explicit design and acceptance criteria. Automated checks detect some defects but cannot establish complete accessibility. Review should also examine keyboard use, assistive reading, error recovery and the effort required to complete a longer task on a phone.

Explore related topics

Define the right scope

A workflow, its users and the information they need: a concrete starting point for a project.

Contact Blaze