A business portal is a place where customers, staff or members sign in to view information and carry out agreed tasks. A custom database report turns stored records into an answer, such as which jobs are waiting for approval or which requests still need a response.
Both can be useful when information is scattered across emails and spreadsheets. Before commissioning either, identify one repeated problem and define what a successful first version would do.
Start with one real example of the work
Choose a recent task and follow it from beginning to end. Who starts it? What information do they provide? Who checks it? What happens if something is missing?
For an illustrative service business, the process might begin with a customer’s request, followed by a staff review, a quote and a customer decision. The problem could be as narrow as nobody knowing which quotes are still awaiting a response.
Write down the current steps and the delays before designing screens. My custom business systems service uses this kind of process review to define portals, dashboards and operational tools.
Decide whether the main need is a portal or a report
A portal makes sense to investigate when users need to do something: upload information, approve a document, check progress or request support. A report may be sufficient when the records already exist and the main need is to find or summarise them.
For example, staff may need a filtered list of overdue tasks without customers needing another login. Adding a customer portal would create account management and support work without necessarily solving the original problem.
Check whether your current software can handle the requirement before commissioning a custom build. If the need is one missing feature or connection, web development and integration work may be a more focused scope than a separate system.
Define who can see and change each record
Write down the access rules before agreeing the screens. A customer might be allowed to view their own project and upload a file. A staff member might update assigned jobs. An administrator might manage account access.
A sign-in screen alone does not establish those boundaries. OWASP’s authorisation guidance recommends denying access by default and checking permission on every request, including access to individual records and protected files.
Ask for tests that demonstrate the rules. One customer should not be able to retrieve another customer’s document by changing a link. A staff account with viewing permission should not be able to make an unauthorised update. These checks belong in the project’s acceptance criteria.
Make custom database reports answer a precise question
“Show sales” leaves too much undefined. Specify the question, the records included and the date used.
For an illustrative “quotes awaiting a decision” report, agree:
- Which status means a quote has been sent.
- Whether withdrawn and expired quotes are excluded.
- Whether the date filter uses creation date or sent date.
- Who owns the next follow-up.
- Whether the total represents quote value or money actually received.
That last distinction matters: an accepted quote is not the same event as a payment. Label reports so their meaning is clear, and allow users to inspect the underlying records where appropriate.
If you are commissioning custom database reports in the UK, include a small anonymised example with the expected result. A developer can then compare the output with something concrete instead of guessing what “monthly performance” means.
Check the quality of the source records
A report cannot reliably distinguish completed and unfinished work if staff use the same status for both. Review duplicate records, missing dates and inconsistent names before deciding which calculations to automate.
Agree which system is the authoritative source for each field. If a portal receives information from another application, define what should happen when that connection is unavailable or an update arrives twice.
For data migration, agree how old records will be checked and how exceptions will be handled. Keep the initial import separate from the decision about future synchronisation so both can be tested clearly.
Give the first release a clear finish line
A useful first release might include sign-in, account-specific project records, a status update and one report. That is an example scope, not a standard package.
Agree the essential workflow, permission tests, representative records, backups, export requirements and who will maintain the system. Include the ordinary exceptions, such as an incomplete submission or a file that exceeds the allowed size.
Vertygo’s custom systems service is quoted against requirements. Ongoing hosting and website care should be discussed against the particular system rather than assumed to cover every future change.
To start a conversation, describe one task your team repeats, the information involved and where it becomes difficult. That is enough to begin deciding whether a report, a small integration or a business portal is the right next step.