Custom Business Platforms: From Requirements to Launch and Maintenance

A custom business platform needs requirements that describe work, records and exceptions. Specify who acts, what information they need, what state changes and how the business checks the result. Launch is one acceptance point. Maintenance, data ownership and exit arrangements belong in the requirements from the beginning.

The manager has already considered whether a custom platform makes sense. The next problem is more concrete. A spreadsheet records requests, a mailbox carries approvals and another tool holds customer details. Everyone agrees that the process is difficult, but nobody agrees what the replacement must do when a request arrives twice or an approver is absent.

This guide follows requirements through implementation and operating ownership. It does not estimate development prices, promise a delivery date or assume the team will adopt a system because it works technically. The fictional examples use a service-request process. Adapt the method to the inspected work rather than copying its screens.

Download the requirements, test and handover workbook or editable CSV pack. Five web tables show the working records without a download. All photographs are generated illustrations. The capacity figures are declared synthetic inputs, not client results or a forecast.

Observe the work before specifying features

Ask a user to complete a recent ordinary task using the existing tools. Record the steps, information copied, decisions made and delays encountered. Then inspect an exception. A process described from memory usually omits the small workarounds that keep it operating. Those workarounds are often where the replacement needs the clearest requirements.

In a fictional repair business, a coordinator receives a request, checks the customer's details and asks a technical reviewer to confirm feasibility. A manager approves the quotation. The coordinator sends it and records the customer's response. A spreadsheet status may say pending even though the real reason is missing material information.

Write the problem using observable behaviour. Staff copy the same contact details into two tools. A request has no named owner after technical review. Approved quotations can be sent with an outdated attachment. These statements give a developer something to investigate. A requirement to improve efficiency does not say which behaviour should change.

Keep useful existing controls. A manual approval may protect a decision that should remain human. A separate spreadsheet may exist because the accounting system lacks a required field. Replacing every workaround without understanding its purpose can remove the process's only reliable check. Design follows the evidence about work, not a preference for fewer screens.

Write requirements as testable tasks

A useful requirement has an actor, trigger, action, result and exception. It should be understandable to the business owner and the implementer. Use acceptance evidence that follows the task. A user creates a request with required information, receives a stable reference and can find its current owner. Those are observable results.

Avoid turning screen components into business requirements. A dropdown is one possible interface for a controlled field. The requirement is that the field accepts approved values and supports the needed decision. Similarly, a dashboard is one way to show work. The requirement is that a manager can identify the records requiring action.

Table 1: requirements register. These examples describe fictional service-request behaviour.

Assign a priority based on consequence and dependency. A stable record identifier may support every later integration. A colour preference may have no operating consequence. Keep those distinctions visible during scope decisions. If a requirement is postponed, identify the temporary process and the person who owns it.

Map states and exceptions

A status field should express a useful condition. New, awaiting information, under review, approved and closed need definitions. Explain which transitions are permitted and who can perform them. A state named complete is ambiguous unless the business knows whether it means reviewed, sent, accepted or finished operationally.

List exceptions alongside the ordinary flow. A required file is missing. The same request arrives through two channels. The approver is away. The external system accepts the record but the notification fails. Each exception needs a visible state or log, a responsible person and a permitted next action.

Do not solve every exception through an unrestricted edit button. Some corrections should preserve an audit trail. Some require a new version. Some require withdrawal rather than deletion. The business should decide what matters before the developer chooses the implementation. A technically convenient action can undermine a commercially important record.

A prototype can show how an exception feels to a user. It cannot by itself prove concurrency, stored-state rules or integration recovery. Mark what the prototype demonstrates and what still requires an implemented test. That keeps visual approval from becoming accidental acceptance of behaviour that has never been built.

Define data and ownership together

List the record types and their relationships. A customer has contacts. A request belongs to a customer. A quotation belongs to a request and has versions. An approval refers to one quotation version. A notification refers to the action that produced it. These relationships make the process interpretable.

Specify stable identifiers rather than relying on names. Two customers can have similar names. A contact can change employer. A quotation can be revised while keeping the same commercial reference. The platform should preserve the distinction between a stable record and its changeable display fields.

Database rules can help enforce the intended structure. PostgreSQL constraints describe mechanisms such as unique constraints, checks and foreign keys. They can prevent specified inconsistent data states. They cannot decide whether a customer classification or quotation assumption is commercially correct.

Table 2: data ownership. The authoritative source is the place where an approved correction originates.

Decide how records can be removed. Closing a request is different from deleting its history. Removing access is different from removing a customer record. Specify retention and export decisions with the responsible business owner. Where legal or contractual obligations apply, obtain the relevant advice and translate the approved decision into requirements.

Prepare imports before building automation

Legacy data rarely matches a new model without decisions. Inspect duplicated customers, missing identifiers, inconsistent dates, free-text status values and broken document links. Define a mapping for known values. Keep unknown values in a review queue. Do not silently translate every unfamiliar status into closed.

Use a controlled sample containing ordinary records and known exceptions. Record the input rows, transformed fields and rejected rows. The import should leave enough information to explain why a record failed. A success total that omits rejected items can create a misleading impression of completeness.

In the teaching example, an import contains twelve rows. Nine satisfy the declared rules. Two lack a customer reference and one duplicates an existing request identifier. The accepted count is nine. The exception count is three. Nine plus three equals twelve. This arithmetic checks reconciliation, not the real quality of the business's data.

The underlying CSV retains those assumed inputs. Do not interpret the chart as a recommended rejection rate. A real import needs its own rules and evidence. Equal source and destination counts can still hide incorrect relationships, so inspect representative records and files after import. Reconciliation includes both counts and meaning.

Specify access below the screen

Authentication identifies a user through the implemented account mechanism. Authorisation decides what the user may read or change. The Supabase authentication overview describes its identity service. A signed-in person does not automatically have authority to approve a quotation or read every customer's records.

Write the permission model as actions on record sets. A coordinator can edit assigned requests. A reviewer can record a technical decision. A manager can approve an eligible quotation. A customer can read permitted releases. Separate administrative account work from commercial approval so broad technical access does not silently confer business authority.

Supabase row-level security is one implementation mechanism for record access. PostgreSQL privileges address database permission layers. Neither source supplies your business role model. The implementer must translate the agreed rules and test both permitted and denied operations through the actual deployment.

Test an unrelated user attempting to request a record directly. Test a role whose authority has been removed. Test an authorised person trying an action outside their role. Hiding a button is an interface choice, not evidence that the underlying operation is forbidden. The server and data layers need their own checks.

Make each integration a contract

Define the event, fields, identifier, expected response and failure behaviour for each connected system. State which platform owns the record and which merely receives a copy. Avoid promising general synchronisation without resolving conflicting edits and deletion semantics. One-direction transfer is often sufficient for a specific task.

Read the actual API documentation. Rate limits, authentication, event formats and retry rules differ by provider. The business acceptance question should be broader than did the API return success. It should ask whether the correct record appeared, in the right state, without losing a required field or creating an unwanted duplicate.

Stripe's webhook guidance describes concrete event-delivery behaviour for that vendor. Its idempotent request documentation explains a separate mechanism for certain API requests. These are useful examples of contracts a developer must inspect. They are not universal instructions for every business integration.

Table 3: integration contract. This fictional contract names business behaviour independently of implementation details.

Keep credentials outside the contract workbook. It needs names, scopes and private reference locations, not tokens. A contract should remain useful to the business owner without exposing the keys that perform the integration. Rotate or revoke temporary access through the approved operating process at handover.

Show failures to the person who can act

An integration can fail after the platform has accepted a user's action. The interface should distinguish a saved record from a delivered notification where that difference matters. If a request is safely recorded but its email fails, tell the operator where the request remains and what recovery action is available.

Use controlled failure tests. Temporarily point a test integration at a known unavailable endpoint or use the provider's supported test mode. Record what the system retries, what it stops and what it exposes to the operator. Keep the test environment isolated from real recipients and production records.

The MDN HTTP status reference helps interpret response codes. A code is only one part of the contract. Some APIs return a successful HTTP response with a business-level rejection in the body. Others accept work for later processing. Read the specific response semantics and test the final state.

Decide who owns reconciliation. A failure log without an operator is another unattended queue. Give the responsible person an action: retry a safe delivery, correct an approved field, contact the external system owner or escalate. Record when manual intervention changes the underlying business record so it does not become invisible data repair.

Use prototypes to answer specific questions

A prototype is most useful when it resolves a choice. Can the coordinator identify missing information? Can the manager distinguish a draft from an approved quotation? Can a customer find the current file without opening several versions? Design the session around those tasks rather than asking whether the screens look good.

Let participants use representative fictional records. Ask them to describe what they believe a state or action means. If they interpret approved as already sent, the wording needs correction before implementation. The observation is about the tested interaction, not evidence that every future user will understand the system.

Record changes to requirements after the session. A new field may reveal a data dependency. A requested filter may reveal that the team needs a different work queue. A request to edit every state may reveal unclear authority. Keep those findings connected to decisions instead of adding components without an explanation.

Separate prototype approval from production acceptance. A prototype may contain static data and simulated buttons. Label those limits. The production system still needs tests for stored records, permissions, concurrent actions, imports and integrations. Design clarity helps the work, but it does not replace implementation evidence.

Agree acceptance before release

Acceptance should cover important tasks and failure paths. Define the test conditions, expected result and owner who can approve the outcome. Avoid a requirement that the application be bug-free. It is impossible to demonstrate with a finite set of checks and gives no guidance about the business's priorities.

Create realistic test data without real customer details. Include two similar customers, a missing field, a duplicate request and an unavailable integration. Test users should have the relevant role. An administrator completing every task can conceal permission failures that ordinary users will face.

Table 4: acceptance tests. Passed tests establish the recorded behaviour under their conditions.

Classify unresolved defects by consequence. A misleading approval state can block release. A minor layout issue may be accepted with a scheduled repair. The business should approve that distinction with evidence. A launch decision is a record of known conditions and residual limits, not a declaration that future work is unnecessary.

Release through defined decision stages

A staged release can limit the scope of early operation. Start with the smallest group that represents the required tasks. Do not choose only enthusiastic users if they avoid the process's difficult parts. Include someone who handles exceptions and someone responsible for approving records.

Decide which system becomes authoritative at cutover. If both the old spreadsheet and new platform remain editable, explain how conflicts are reconciled. A trial can use copied data, while production work needs a clear boundary. The team should know where to enter the next real request.

Define rollback limits before release. Restoring an earlier code version may not reverse a changed database structure. Restoring a database may discard records created after the recovery point. A safe decision depends on what changed and what must be preserved. The implementer should explain the consequence in business terms.

Keep a release reference, dated tests and an exception list. After deployment, repeat the important public or private journeys through the actual environment. A build passing does not prove an external integration uses the correct production configuration. Verify the task where users will perform it.

Budget attention for operation

Recurring responsibilities include platform administration, dependency updates, integration changes, record exports, recovery checks and user support. Recurring vendor charges can depend on users, storage, compute or messaging. Describe these as components and assumptions rather than inventing a monthly price for a system that has not been inspected.

Choose signals that help someone act. A failed integration count can support reconciliation. An import error record can support correction. A storage warning can prompt a capacity review. A dashboard of decorative figures adds work if nobody knows what action follows them.

PostgreSQL backup and restore documentation describes different database recovery approaches. The actual platform may also store files and configuration elsewhere. A database backup alone may not recover the entire application. List those components and test an appropriate restoration in a controlled environment.

Table 5: maintenance responsibilities. Scope and response arrangements must be agreed for the actual platform.

The platform can work technically while the business process remains poorly adopted. Observe whether staff use the agreed source, complete the required transitions and know where exceptions belong. Treat adoption problems as evidence to investigate. They may reflect unclear responsibilities, missing information or a workflow that never matched actual work.

Work through an interrupted quotation

In the fictional platform, the manager approves quotation version three. The platform records the decision and requests delivery to the customer. The delivery service is unavailable. The quotation remains approved, while delivery becomes failed. The screen does not describe it as sent.

The operator finds the exception and checks the delivery contract. The retry uses the same business reference. The system records the later successful delivery without creating another quotation. The manager can still identify which version was approved. The customer sees the permitted file, and the operator can reconcile the request with the delivery log.

During a separate test, a late event arrives for version two. The system must follow the agreed rule. It might retain the event as historical evidence while preserving version three as current. It should not silently replace the current quotation merely because the event arrived later. Arrival time and business sequence are different.

This example tests state meaning, version identity, retry behaviour and operator visibility. It does not establish measured time savings or prove every provider supports the same delivery guarantees. The actual implementation needs a contract for its chosen systems and evidence from its own representative failure tests.

Make exit arrangements usable

Ask what the business can take with it. Source code, stored records, uploaded files, configuration references and documentation may have different ownership and export routes. Establish rights and access in the engagement terms. Do not assume a hosted account automatically includes transferable source code for every component.

Test the export with the receiving use in mind. A CSV with customer names may be readable but fail to preserve relationships between quotations and requests. A collection of files may omit revision metadata. State what the export contains and what additional material a future maintainer needs.

Handover should include task exercises. The receiving operator finds a failed delivery, checks a user's permissions and locates the current release instructions. The business owner identifies the unresolved decisions. Where only the original builder can perform a routine task, record the dependency and decide whether to change the system or retain that support arrangement.

Test two people changing the same request

Concurrent work belongs in the acceptance plan when several staff share records. In the fictional platform, a coordinator opens a request while a reviewer records a technical decision. The coordinator's older screen should not silently overwrite that decision when saving contact information. The business must define the permitted conflict behaviour before the developer chooses it.

A controlled test opens the same fictional record in two sessions with the relevant roles. One session changes the review state. The other changes a permitted contact field using the earlier view. Observe whether the platform preserves both approved changes, rejects a stale update or asks the second user to reconcile. Record the expected behaviour explicitly. Do not treat whichever result the framework produces by default as business policy.

The scenario also tests language. A message saying something went wrong leaves the coordinator unsure whether the request was saved. A useful message explains that the record changed and offers a safe next step. It should preserve the person's permitted input where the design supports that behaviour, without pretending the old state remains current.

Repeat the exercise for an approval that refers to an exact version. If a quotation changes while approval is being considered, the approver needs to know which version the decision will affect. A later save should not quietly approve a different document. This is a record-identity question, not merely a screen refresh problem.

The result is specific evidence about the tested roles and operation. It does not prove every concurrent action is safe. Identify which other shared records use the same implementation pattern and choose proportionate checks. The operating instructions should explain how staff handle a visible conflict rather than encourage repeated clicking until a message disappears.

The handover exercise should include this conflict route. Ask the receiving operator to explain what was saved, what remains unresolved and who can approve the correction. Keep the test reference with the operating instructions. If staff cannot interpret the conflict without calling the original builder, the system still has a documentation or interaction gap that deserves a named next action.

Frequently asked questions

How much detail belongs in requirements?

Enough to define the important task, result and exception without prescribing every screen prematurely. Start with records, actions, authority and acceptance. Add interface detail when it resolves a real user question. Keep uncertain decisions visible so the implementer does not quietly choose business policy.

Can the team keep using spreadsheets?

Yes, when their role is defined. A spreadsheet may remain useful for analysis or a bounded export. It becomes risky when it silently competes with the platform as the source of current records. Decide where authoritative changes happen and how working copies are reconciled.

Does one successful integration prove readiness?

No. Test the required fields, repeated delivery, interrupted responses and final business state. The acceptance record should identify the actual provider and configuration. An API success response can be evidence of one stage while later processing still fails.

Can maintenance be decided after launch?

It can be revised later, but operating ownership belongs in the initial requirements. Someone must manage accounts, respond to failed work and preserve recoverable records from the first production use. Leaving that undecided creates a dependency on whoever happens to remember the implementation.

Is private application content an SEO task?

Private screens serve authorised working tasks. Public pages describing the platform or business may need search work. Keep those scopes distinct. Permission enforcement protects private data; search controls address discovery and indexing. Neither should be used as an accidental substitute for the other.

Start with a task that cannot be explained

Bring a recent request that needed repeated copying, a missing approval or a manual recovery. Map what actually happened, then decide which records and rules the replacement must preserve. The next useful step may be a process correction, a small integration or a custom platform.

Creatif Work can diagnose that working problem and scope custom software, web applications and ongoing support around it. Public website and search work can be considered separately where relevant. Start with the problem.

Sources and limits

Official sources checked on 4 October 2026. Platform mechanisms support the stated implementation distinctions. Requirements, examples and acceptance records are original planning material.

• PostgreSQL: constraints.
• PostgreSQL: privileges.
• PostgreSQL: backup and restore.
• Supabase: authentication.
• Supabase: row-level security.
• Stripe: webhooks.
• Stripe: idempotent requests.
• MDN: HTTP response status codes.