Server-side logic
Request processing and rules that cannot be entrusted to the browser.
← All technologiesPHP.
PHP · BIG FISH
PHP.
Business rules.
On the server.
We develop server-side systems for websites and services: request processing, integrations, documents and data operations. Architecture follows the task and long-term maintainability.
BIG FISH / PHP
01Incoming request
02Input validation
03Transaction and uniqueness
04Confirmed outcome
Design × technology × your workflow
PRODUCT CAPABILITIES
Technology becomes
a working product.
Integrations
Event intake, validation and consistent persistence.
Documents and data
Exports and reports with controlled access and error handling.
INTERACTIVE EXAMPLE
Try the workflow.
See the outcome.
A payment notification handler validates and applies an event once. Repeating the same identifier must not increase the balance again.
Educational example with fictional data. Actions stay in your browser. This models the workflow; it is not a connected CMS, server or database.
PHP
PHPWorkflow result
The example is ready to explore.
WORKFLOW ARCHITECTURE
Every step has
a responsibility.
01
Incoming request
02
Input validation
03
Transaction and uniqueness
04
Confirmed outcome
| Layer | Outcome |
|---|---|
| Interface | Input, limits, loading and errors are clear. Keyboard operation is available. |
| Data | Values have an owner, format and freshness rules. |
| Release | Critical journeys, backups and recovery have been checked. |
BIG FISH · PHP
Server-side logic made understandable.
Custom PHP development needs clear interfaces for server-side actions. After submitting a form, users should understand whether the request was accepted, what was saved and what happens next.
In PHP services and customer portals, we present operation history, confirmations and rejection reasons in plain language. Permissions and validation remain server-side; the interface explains their outcome without technical error messages.
PRACTICAL GUIDE
Building a product
with PHP.
Architecture, constraints and testable workflows. The exact configuration follows the project requirements.
PHP / 01
Application boundaries
PHP is a language, not a complete product architecture. An application may use a framework or selected libraries, but its request handling, business rules, data and external connections should remain clear. Start with module responsibilities and failure scenarios. Avoid mixing HTML generation, payment submission and database updates in one handler.
Acceptance check
Business rules are tested outside the HTML template.
PHP / 02
Request contract
Define required fields, types, valid ranges and error formats. Casting a string to a number does not validate its meaning. Match a payment amount to the expected document and currency. Verify notification signatures separately; the browser demo uses an illustrative trust flag and does not implement cryptographic authentication.
Acceptance check
An invalid signature leaves the balance unchanged.
PHP / 03
Working with SQL
Pass values through prepared-statement parameters rather than concatenating SQL. Column names and sort directions need separate allowlists. Check connection encoding, result limits and error handling. Prepared statements address a specific class of problems; they do not replace access control or record-ownership checks.
Acceptance check
A parameter cannot change the SQL structure.
$stmt = $pdo->prepare(
'SELECT id, amount_minor FROM orders WHERE id = :id'
);
$stmt->execute(['id' => $validatedOrderId]);PHP / 04
Transactions and retries
Bind an event identifier to its source and enforce uniqueness in storage. Checking whether it already exists before insertion is insufficient under concurrency. Apply the amount and record the event consistently within a transaction. Return a clear result for duplicates and handle conflicting payloads using the same key separately.
Acceptance check
Two identical events are applied once.
PHP / 05
Files and secrets
An uploaded file must not become executable PHP. Restrict allowed types, sizes and storage locations. Connection settings and integration credentials stay out of responses and logs. Separate public assets from application internals. Configure filesystem permissions and process-user privileges as part of the environment.
Acceptance check
An uploaded file is not executed by the server.
PHP / 06
Errors and logging
Show users a safe message and give operators an identifier for locating details. Never expose stack traces or secret parameters publicly. Distinguish expected input errors from infrastructure failures. Give external calls timeouts and a deliberate retry policy so a stalled service cannot consume every application worker.
Acceptance check
Public errors do not reveal stack traces.
PHP / 07
Dependencies and environment
Lock project dependencies and verify compatibility with the chosen PHP version. Document extensions, memory limits and worker settings alongside the code. Move long-running work out of ordinary HTTP requests when the workflow warrants it. Test interpreter upgrades in staging, including compatibility warnings.
Acceptance check
A PHP upgrade is tested before production.
PHP / 08
Acceptance scenarios
Repeat an event, change its amount, simulate database failure and verify recovery. Test concurrency where uniqueness matters. Hand over input contracts, error codes and release procedures. Support covers dependency updates and error monitoring, not merely whether the homepage remains reachable.
Acceptance check
A write failure does not leave a partial payment.
FAQ
Before we start
Is this a ready-made product?
No. The example illustrates a proposed workflow for PHP. We design the production system around your requirements, data and integrations.
Can we retain our current systems?
We first review their interfaces, data ownership and constraints. The result may be an integration, a phased migration or a focused replacement of one component.
What do we receive at handover?
The agreed deliverables include design assets, source code, environment requirements and operational instructions. Scope, ownership and support are recorded in the contract.
Let’s design your product
Tell us about your workflow, audience and existing systems. We will define the interface, technical boundaries and delivery stages.