Scalable enterprise software continues to perform its agreed work as demand, data and organizational complexity increase. That means more than serving additional users: a system may need to process larger imports, support more branches, isolate customer accounts or remain usable while a connected service is unavailable.
For a buyer planning a custom business system, the first deliverable should be a workload and acceptance brief. A technology list cannot prove scalability. This guide explains the decisions and evidence to request before committing to an architecture or a fixed delivery scope.
Define the workload before choosing the architecture
Describe the operations that matter: searching records, approving requests, importing orders, producing reports and synchronizing ERP data. Record typical and peak demand separately. The number of registered users alone says little about how many people work at the same time or how expensive their actions are.
Include expected record counts, file sizes, retention periods and concurrent background jobs. Identify predictable peaks such as a sales campaign, shift change or month-end reporting. Record the assumptions behind growth estimates so they can be revised when real usage differs.
An illustrative acceptance requirement might be: under an agreed dataset and 50 concurrent staff users, 95% of a named search operation completes within one second. This is a sample requirement, not a Tarawud performance promise. A useful test also states the environment, test duration, error threshold and operations running alongside the search.
Google's SRE guidance distinguishes measured service indicators from target objectives and recommends choosing measures that reflect what users need. Latency, successful operations and completion of background work can matter in different ways. Service level objectives.
Start with clear business boundaries
Identify the major areas of responsibility: customers, inventory, orders, billing, approvals and reporting, for example. Define who owns each record and which rules may change it. Keep permission checks and business validation close to the operations they protect.
A modular application can keep these boundaries within one deployable system. Separate services can make sense when parts need independent releases, different capacity or distinct ownership. They also require coordination across failures, data changes and operations. Ask which concrete constraint justifies each separate service and who will support it.
Do not choose microservices solely because the expected business is large. Compare a simpler design against the proposed distributed design using the workload, team capabilities and operational requirements. A design is easier to assess when it includes the reason for each boundary rather than only a diagram of components.
Examine database work before adding more servers
Slow screens can come from repeated database queries, unbounded result sets or reporting work that competes with transactions. Review the operations behind the screen and test with a representative quantity and distribution of records.
For PostgreSQL, the official documentation explains how EXPLAIN exposes the planned execution steps and how EXPLAIN ANALYZE adds actual execution measurements. The latter runs the statement, so choose a safe test environment and handle statements that change data carefully. PostgreSQL query-plan documentation.
Ask for evidence of the bottleneck before approving an index, cache or database split. An index has write and storage costs; a cache needs a rule for when its contents become stale. Check permissions in cached results so that one company cannot receive another company's information.
For dashboards, specify whether the figures must be immediate or can be refreshed periodically. A report generated asynchronously may be more appropriate than keeping a browser request open while it processes a large dataset.
Make background work observable and recoverable
Email preparation, exports, file processing and external synchronization can often run outside the interactive request. The user should receive a meaningful status and a way to retrieve the result. Moving work into a queue does not remove the need to manage it.
Define maximum queue age, retry limits, duplicate handling and the action required after repeated failure. Measure completed business work as well as jobs accepted by the queue. A growing queue with no visible errors can still mean that customers are waiting indefinitely.
When retrying an external action, agree how the receiving system recognizes the same request. A timeout does not prove that the original action failed. The AWS guide to idempotent APIs explains this distinction. Keep a business reference that support staff can use to reconcile the result.
Keep ERP integration and customer isolation explicit
For an ERP connection, document product and customer identifiers, which system owns each field, update frequency and correction procedures. Test partial failures: the order can be accepted while its attachment or stock update fails. Decide which state the user should see and when the overall operation is complete.
For a system used by several customer organizations, specify isolation in database queries, file storage, exports, background jobs and administration. Test access by attempting to retrieve another test organization's records through each relevant route. Hiding a menu item is not a substitute for enforcing authorization.
The scope should also cover role changes, account removal, audit records and recovery of accidentally changed data. These are acceptance requirements for the actual application; a hosting provider's feature list does not prove that they have been implemented.
Plan releases, migrations and recovery together
Describe how a release changes both code and data. Test database migrations with representative records and estimate the time they need. Identify which changes can be reversed and which require a corrective migration or restoration plan.
Before moving existing users, reconcile imported counts and sample important records with the source. Agree when users can edit data during the transition and how changes made during that period will be handled. Keep the previous environment available for the agreed recovery window where appropriate.
Backups need a tested restoration procedure. Specify the acceptable data loss and recovery duration for the business process, then demonstrate whether the proposed setup meets them. Do not substitute a successful backup job for evidence that the application can be restored and used.
What evidence should be included in the proposal?
Request workload assumptions, architecture decisions, data ownership, authorization requirements, integration contracts, load-test scenarios and release responsibilities. Ask for hosting and third-party costs to be separated from development and support. Avoid comparing proposals only by the number of screens.
An initial delivery can focus on one complete business workflow and its failure cases. Later phases can expand users, integrations and capacity against measured demand. Review the original assumptions at each phase instead of treating the first capacity estimate as permanent.
Our business process automation guide helps define that first workflow. Explore custom software development, ERP integration and cloud and DevOps services, or contact Tarawud with your current system, expected workload and most important operating constraint. A technical assessment can then distinguish a targeted improvement from a broader rebuild.
If the project replaces an existing application, use the legacy software modernization guide to compare transition options and define when the old system can be retired.
