Business Operations Platform Development
A browser-based platform built around one organisation's real operational process — the sequence of work, the people who carry it out, the records that must exist afterwards, and the approvals that sit between them.
The situation this service is built for
An organisation reaches a size where the process that once lived in someone's head no longer fits there. Work is tracked across shared spreadsheets, email threads and a folder structure that made sense two years ago. Everyone knows where things are, until the person who knows is on leave.
Off-the-shelf products have usually been tried by this point. They either cover a fraction of the process, or they cover far more than is needed and force the organisation to work in a way that does not match how it actually earns money. Neither situation is a technology problem; it is a fit problem.
A bespoke operations platform is appropriate when the process is genuinely specific, when several people need to work in it at once with different permissions, and when the record of what happened matters as much as the work itself.
Problems this service may address
- No single version of the truthSeveral copies of the same information exist and nobody is certain which is current, particularly when two people edit on the same day.
- Status is invisibleAnswering "where has that reached?" requires asking someone, and the answer varies depending on who is asked.
- Approvals happen informallyDecisions are given verbally or by email with no consistent record of who approved what, when, and on what basis.
- Re-entering the same dataThe same customer or job details are typed into several places, creating inconsistencies that only surface at invoicing.
- No safe way to delegateWork cannot be handed to a new team member because the process is not written down anywhere that is enforceable.
- Documents driftQuotations, reports and confirmations are produced from copied files, so formatting and content vary by author.
- History is lostUnderstanding why a decision was made last quarter means searching mailboxes rather than opening a record.
What a platform can contain
The list below describes what is possible within this service. No project includes every item — the platform is assembled from the parts that match the agreed scope, and the proposal states exactly which are in and which are not.
Possible applications
- Quotation and request management
- Operational dashboards showing current state
- Customer and supplier workflows
- Job or project tracking
- Structured internal records
- Document management and generated documents
- Approval systems with a recorded decision trail
- Role-based workspaces
Typically included in scope
- Discovery and process mappingSessions to establish the real sequence of work, not the documented one.
- Data model and permissions designWhat is recorded, how records relate, and who may see or change each part.
- Interface design for the agreed screensLayouts built for daily use rather than for a demonstration.
- Development and functional testingEach feature tested against its written acceptance criteria.
- Deployment to an agreed environmentRelease, configuration and a check that the live system behaves as tested.
- Handover documentationStructure, configuration and routine administrative tasks, written for the client's team.
What is not automatically included
These items are frequently assumed. Each can be added to a project, but only when it has been scoped, priced and agreed in writing.
- Migration of existing dataImporting historical records from spreadsheets or another system, including the cleaning that usually needs to happen first.
- Integrations with third-party servicesConnections to accounting, payment or messaging providers, each of which depends on that provider's interface and terms.
- Native mobile applicationsThe platform is responsive and works in mobile browsers; store-published native applications are a separate scope.
- Ongoing hosting and supportHosting arrangements and any support agreement are described separately from the build price.
- Staff training programmesA handover walkthrough is included; structured training for a large team is scoped separately.
- Formal security or compliance certificationSound practice is applied, but no penetration test, audit or certification is claimed or provided.
Engagement process
Discovery and process mapping
Working sessions with the people who do the work, following two or three real cases from start to finish. The output is a written map of the current process and a list of the points where it breaks.
Scope definition and proposal
The map becomes a defined scope: screens, roles, records, rules and integrations, with explicit exclusions. The written proposal sets the price, the indicative timescale and the acceptance criteria.
Structure, data and permissions
The data model and the permission matrix are designed and confirmed. This is the cheapest possible moment to disagree, so disagreement is actively invited here.
Development in reviewable increments
The platform is built in parts you can open and use — typically core records first, then workflow, then approvals and reporting. Each increment is reviewed before the next begins.
Testing and client review period
Functional testing against acceptance criteria, followed by a review period in which your team runs real scenarios and records anything that does not match the agreed specification.
Deployment, handover and follow-up
Release to the agreed environment, documentation handover and a walkthrough session. A short settling period follows, during which defects against the specification are corrected.
Expected deliverables
- The working platformDeployed to the agreed environment and configured for live use with the agreed roles.
- Source code for the custom workProvided in a repository, with ownership addressed in the written agreement.
- Data model documentationWhat is stored, how records relate and where the constraints sit.
- Administrative documentationHow to add users, adjust permissions and perform routine tasks without developer involvement.
- Acceptance recordThe agreed criteria with their test outcomes, so completion is a documented fact rather than an opinion.
- Handover walkthroughA live session covering the structure, the decisions taken and the parts most likely to change later.
Client responsibilities
Operations platforms depend heavily on client knowledge, because the process being modelled exists only inside the organisation. The following are needed for the indicative timescale to hold.
- A nominated decision-maker who can settle scope questions without a committee
- Access to the people who actually carry out the process, for discovery sessions
- Examples of real records, documents and edge cases — including the awkward ones
- Timely feedback at each review point, within the agreed window
- Any credentials or access required for hosting or integrations
- Confirmation of acceptance criteria before development begins
Factors that affect scope and price
Increase scope
- Several roles with genuinely different permissions and views
- Complex approval hierarchies or conditional routing rules
- Migration of historical data requiring cleaning
- Two-way synchronisation with an existing system
- Reporting with flexible filtering and export requirements
- Multiple document templates with variable content
Keep scope lean
- One process modelled properly rather than a whole department partly
- Two roles at launch, with others added in a later phase
- Starting fresh rather than importing years of legacy records
- Standard exports instead of a bespoke reporting engine
- A single decision-maker with authority to confirm scope
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
After delivery
An operations platform is used every day, so it changes. Three follow-up arrangements are available and are agreed separately from the build.
Settling period
A defined period immediately after handover during which defects against the agreed specification are corrected at no additional charge.
Change requests
Individual pieces of work quoted as they arise. Suitable where changes are occasional and not urgent.
Phase two
A planned second phase for the parts deliberately left out of the first, once real use has shown which of them still matter.
Questions about this service
Platforms in this service are typically designed for teams rather than mass consumer traffic — commonly a handful to a few dozen concurrent users. Expected numbers are discussed during scoping, because they influence hosting and data design.
Where far larger usage is expected, that is stated in the proposal and the architecture is planned accordingly, which affects both cost and timescale.
Yes, and it is usually the better route. Modelling one process well produces something people use within weeks, and real use reveals which of the remaining requirements genuinely matter.
The data model is designed with the wider picture in mind so that later phases extend the platform rather than requiring it to be rebuilt.
Hosting is discussed and agreed during scoping, and accounts are held in the client's name wherever practical so control does not depend on the supplier relationship continuing.
The proposal states where data will be held and how it can be exported. Data portability is treated as a requirement, not a favour.
Small refinements within the agreed scope are absorbed as normal. A structural change — a new role, a new approval path, an additional record type — is documented as a written change request with its cost and timescale effect.
Building in increments helps here: a change identified during review of increment two can often be accommodated before the affected work has started.
Not always. Where the process is well understood internally and one person can describe it end to end, discovery within this service is usually sufficient.
A separate feasibility engagement is worth considering where several departments disagree about scope, where a budget must be justified before approval, or where it is not yet clear whether custom software is the right answer at all.
Continue
Services that often accompany this one
Service enquiry
Describe the process you want to put on rails
Two or three sentences about how the work flows today, and where it fails, is enough for a first response. The enquiry form will arrive with this service already selected.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom