Backend development that keeps your business rules intact.
A saved order should stay saved, even when its confirmation email fails. WebXd develops the server-side logic behind your website or application, with clear rules for storing data and handling the work that follows.
Bring an existing backend or a feature that needs one. We can define the records, permissions, and failure behavior before choosing what to build or change.
Illustrative backend console. Synthetic order and job states show a proposed design, not a client system or measured result.
- Business rules
- Durable records
- Recoverable work
Rules that must survive every write.
Backend development starts with what the system must remember. An account, an order, and a delivery address have different lifetimes. Defining their relationships early helps prevent an ordinary edit from changing information that another task still needs.
We translate those decisions into validation and storage rules. Required fields and unique identifiers can be enforced in the database, while application logic checks whether a requested change is allowed in the record's current state. Both layers matter when several routes can update the same data.
| Decision | Rule to agree |
|---|---|
| Identity | One stable order identifier, retained across retries |
| History | Keep the delivery address used when the order was placed |
| State | Define which transitions are allowed after confirmation |
| Deletion | Agree retention and deletion rules for each record type |
An order is saved. Its receipt can wait.
Consider a customer placing an order while the email provider is unavailable. The backend needs to distinguish the durable business action from the follow-up message. Otherwise, a delayed receipt can leave the customer unsure whether to place the order again.
For this example, the order and a pending receipt job are committed together. A worker handles the email afterward. If delivery fails, the job retains a visible status and can follow an agreed retry policy without creating another order.
A repeated submission needs its own rule. A request identifier can let the backend recognize the same intended action and return the existing result. We also define what happens when the identifier is reused with different input, or arrives after the agreed retention window.
That separation makes recovery more precise. Support can investigate the pending receipt while the order remains available for fulfillment. External delivery can still be uncertain, so the design must account for provider behavior and possible duplicate messages.
Accept
Validate input and check the caller's permission.Commit
Save the order and its pending job in one transaction.Follow up
Send the receipt with tracked status and bounded retries.
Access belongs to the record.
A customer and a support agent may use different screens to read the same order. Hiding a control in the browser does not establish permission. The backend checks who is making the request and which record or field they are allowed to access.
We map permissions to actual tasks, including administrative exceptions. A support role might read an order's status but have no reason to export every customer's address. These distinctions become test cases, with changes to sensitive records logged according to the agreed scope.
| Actor | Allowed task | Boundary |
|---|---|---|
| Customer | Read their own order | Another customer's identifier grants no access |
| Support agent | Review delivery status | Bulk export requires separate permission |
| Background worker | Process pending receipts | Use only the data needed for that job |
Find the work behind a slow response.
A slow order-history screen may be waiting on a database query, a remote service, or too much work inside one request. We examine the operation before proposing more infrastructure. A useful starting point is a reproducible request and evidence of where its time goes.
The performance scope should describe realistic activity. How many records does the query read? Which tasks run at the same time? That context helps decide whether the next change belongs in the query, an index, a cache, or a background job.
Caching also needs an accuracy rule. An old product description may be acceptable for a short interval, while a fulfillment decision may require current order state. We agree which information can be stale and test performance alongside the behavior it must preserve.
Bring evidence from the operation
- A slow request that can be reproduced
- Query plans or timing traces, where available
- Typical record counts and concurrent tasks
- The response target and acceptable data freshness
Choose the change your backend needs.
An existing system can often support a focused addition. We first review its code, data model, dependencies, and release setup. The recommendation should explain which constraint calls for a change and how current users will be affected.
Extend a working foundation
Add a defined capability when the current structure can accommodate it. Keep existing callers in view, document the new behavior, and check that older tasks still work.
Repair a specific constraint
Address the part that causes inconsistent data or blocks an important operation. A targeted change needs regression evidence and a release plan, even when the rest of the application remains familiar.
Replace a defined boundary
Consider replacement when the constraint cannot be resolved responsibly within the existing system. Agree how records move, which callers switch first, and how new writes are handled during the transition.
Put failure cases in the acceptance plan.
A successful demonstration covers only part of the backend. The acceptance plan should also describe repeated requests and interrupted work. Expected behavior makes it possible to review the implementation against the business rule rather than a reassuring status message.
| Scenario | Evidence to review |
|---|---|
| The customer submits twice | One intended order and a consistent response |
| Two edits overlap | A defined conflict rule; no silent loss of an update |
| The receipt provider times out | Order retained; job status and recovery path visible |
| A customer requests another order | Access denied without exposing its private fields |
| A schema change is released | Migration rehearsal and a documented recovery approach |
Delivery also includes the information needed to run the system. The agreed handoff can cover source code, schema migrations, configuration instructions, and test evidence. Operational notes explain where failures appear and who decides whether a job should be retried.
Backups need a restoration check, and releases need a recovery approach that accounts for changed data. We define those responsibilities with your team, along with access to hosting accounts and any ongoing maintenance included in the engagement.
Agree the operating responsibilities
- Hosting and database account ownership
- Secrets, configuration, and access changes
- Failure alerts and escalation ownership
- Backup restoration and release recovery
- Dependency updates and ongoing support scope
Questions that settle the backend scope.
What does backend development include?
The scope can include server-side business logic, database design, record permissions, and background processing. Interfaces for browsers or other systems may be part of that work. Visual frontend design and external integrations are separate scope decisions, so the proposal identifies where responsibilities meet.
Do we need microservices or a particular framework?
That choice follows the system's requirements and the team's ability to operate it. A single application with clear internal boundaries can be a practical starting point. Separate services add deployment and coordination work, so the recommendation needs a concrete reason for that complexity.
What information is needed for an estimate?
Bring the main operations, current stack, and examples of the data involved. Existing code access and known failure cases help clarify the work. Migration needs, permission rules, and operational expectations can change both cost and schedule; these are resolved in the proposal rather than assumed.
Can you work with our frontend team?
Yes. The engagement can define request and response formats, error behavior, and sample data for the frontend team. Agreeing these contracts early lets both sides review the same expectations. Ownership of interface changes and acceptance testing is documented before implementation.
Who maintains the backend after delivery?
The agreement identifies ownership and any continuing support. Your team should know who handles software updates, failed jobs, and access changes, along with the coverage and limits of the support scope. Specific response commitments need to be confirmed in that agreement.
Where the backend connects.
- Custom web developmentPlan the complete application experience.
- API integrationsConnect the external systems your workflow uses.
- Application re-engineeringDefine a broader change to an existing application.