Business systems and customer portals
Business software development
We build internal systems and customer portals for orders, tasks, documents and approvals. We start with one workflow: who initiates it, which data it needs and who owns the outcome.
Discuss your workflowWhat is worth building from scratch?
Custom software makes sense when your working rules do not fit existing tools and workarounds cost time or cause errors. A new system is not always necessary: configuring a CRM, connecting two applications or cleaning up data may be enough. We compare these options first.
Problems we can start with
- The same order is copied into several spreadsheets, with its status buried in the latest email.
- Employees, clients and external partners need different access to the same project.
- Approvals, document versions or responsibilities get lost between teams.
- Existing systems are still useful, but reliable data exchange is missing between them.
When we would start with something simpler
- A standard sales or accounting process fits an established tool — we assess configuration first.
- The problem is only data transfer — a focused integration may be more useful than another interface.
- The team has not agreed how work should happen — the first stage would be process mapping and a prototype, not a full system build.
Permissions are part of the workflow
We define access by organisation, project and action, not just job title. Below is an illustrative order-portal matrix, not a system delivered to a client. Actual rules are agreed before implementation and checked at the server and database level.
| Participant | Visible information | Actions and boundaries |
|---|---|---|
| Client | Assigned orders within their organisation and public comments. | Submits requests and comments. Cannot read internal notes or another client’s data. |
| Coordinator | Assigned projects, tasks and their history. | Assigns work and changes status under agreed rules. Cannot grant themselves additional permissions. |
| External partner | Invited projects and information needed for their work only. | Updates their tasks. Cannot see invoices or other projects; access can be revoked. |
| Finance team member | Information and documents needed for billing. | Manages financial records. This role does not grant system administrator access. |
| Administrator | Users, access settings and the agreed activity log. | Grants and revokes permissions. Sensitive actions are recorded; additional sign-in protection is planned. |
One working process first
- 01
Map the current workflow
Review the trigger, responsibilities, data sources and exceptions. Identify what should stay in existing tools and which problem to address first.
- 02
Define the first release
Prepare a prototype of the key screens, a permission matrix and testable acceptance criteria. Explicitly list what is outside this stage.
- 03
Connect and verify
Implement the workflow, access controls and agreed integrations. Test not only successful actions, but duplicates, interrupted connections and unauthorised access.
- 04
Move in stages
Rehearse data migration with an agreed sample, reconcile the results and define a rollback plan. Hand over usage guidance and agree responsibilities for further development.
What affects scope, cost and timing
- The number of workflows, exceptions and approval steps.
- Organisations, roles and data-isolation rules.
- Integration capabilities, API limits and reliability of the source data.
- Existing data quality, migration volume and business-continuity requirements.
- Documents, reports, verification and the support the team needs after handover.
Useful answers before the first conversation
- 01Which single process causes the most manual work or errors today?
- 02Who uses it: employees, clients, partners? What should each person be unable to see?
- 03Where is data stored now, and which system is its source of truth?
- 04Which exceptions occur: cancellation, requested changes, partial approval?
- 05Which testable result would make the first release ready to use?
Describe one workflow you want to improve.
The current steps, participants and main obstacle are enough. Do not send credentials or real client data — an anonymised example is a useful starting point.