01The symptom
WordPress handles content and standard ecommerce well. It falls short when business rules are complex, permissions apply per record, several consumers need the same data, work runs in the background, or the product needs an application interface rather than a page. Forcing that into posts, fields and plugins adds debt and makes maintenance fragile. A custom application is the alternative, and it is not always the right answer.
If nobody can explain today what happens to a record, who approves it and what occurs when it fails, building first only moves the confusion into the code. The diagnosis has to make that clear before the first line is written.
02What it covers and what it does not
Includes
- Diagnosis of users, business rules, data and integrations
- Domain model: entities, states, permissions and transactions
- Stack decision across WordPress, Laravel, Node.js and React for the case
- API with a stable contract for the consumers that need it
- Admin panel adapted to the people who will use it
- Integrations with the systems already in place
- Tests for the critical flows
- Deployment in the agreed environment
- Handover with repository and documentation
Does not include
- A template or a purchased theme with the logo swapped
- A plugin installed and configured with no development
- A cheap landing page presented as an application
- A team that does not exist: no part of the work is promised to people who are not there
- A fixed price before the scope is understood
- A delivery date promised without written agreement
03How we do it
-
01
Diagnosis
Users, rules, data, integrations and what the system does today are reviewed. Without that, any technology decision is a guess.
-
02
WordPress or application
What WordPress already solves is compared with what forcing it would cost. If WordPress is enough, that is the answer; if not, the application and its parts are justified.
-
03
Scope and price
What will be built, what is out of scope and what it costs are defined together. The price is closed with the scope in front of you, not before.
-
04
Build
The domain model, API, panel and integrations are implemented in reviewable increments.
-
05
QA
Critical flows, permissions and foreseeable errors are tested before deployment.
-
06
Handover and agreed support
The repository, documentation and environment access are handed over. Ongoing maintenance is agreed separately, with its own scope and cost.
04Price and scope
Quoted after diagnosis
What determines the costDomain scope: entities, states, rules and transactions that have to be modelled. · Number of roles and permissions: how many profiles exist and whether access depends on the record. · Integrations: how many systems have to be connected and whether they expose a stable API. · Data migration: volume, quality and format of what already exists. · Admin panel: what each profile must be able to do without touching code. · Testing and deployment: critical flows, a separate environment and going live.
- Domain scope: entities, states, rules and transactions that have to be modelled.
- Number of roles and permissions: how many profiles exist and whether access depends on the record.
- Integrations: how many systems have to be connected and whether they expose a stable API.
- Data migration: volume, quality and format of what already exists.
- Admin panel: what each profile must be able to do without touching code.
- Testing and deployment: critical flows, a separate environment and going live.
05Timelines and response
Set after diagnosis; it depends on scope, integrations and access. No date is committed before the domain, the data and the systems involved have been reviewed.
Response policy: First response within 1 business day, Monday to Friday, Colombia and Spain time.
06Compatibility and access
To start, I need the person who knows the process end to end, the current data with a real sample, access to the systems or APIs that have to be integrated, a separate test environment and the person who decides the scope. If an access does not exist yet, it is recorded as a dependency and resolved before building.
07What evidence we deliver
Declared capability. There are no publishable cases, metrics or verified certifications with Laravel, Node.js or React, and evidence per technology is still pending. This page explains what is built and when it fits, not proven experience.
08What you receive
| Deliverable | When |
|---|---|
| Scope document | At the end of diagnosis |
| Architecture and technical decisions | Before building |
| Code repository | At each delivery |
| Test environment | Before the first test |
| Critical flow tests | At each delivery |
| Documentation | At handover |
| Handover | At handover |
09What happens next
At handover you receive the repository, the documentation and access to the environment. After that come the agreed maintenance, dependency updates, error review and whatever monitoring has been contracted. There is no implicit support or permanent availability: what is included is written into the proposal.
See support and maintenance10Frequently asked questions
When is WordPress no longer enough?
When the problem involves business rules with states and transactions, per-record permissions, several consumers of the same data, background work or an application interface rather than a page. If the case is standard content and ecommerce, WordPress remains the default: simpler and with a more predictable operating cost.
Do Laravel, Node and React have to be used together?
No. Only what the problem requires is chosen: Laravel for a PHP application with a panel, queues and its own rules; Node.js for an API or integration service; React for an application interface that justifies it. Adding all three without need duplicates deployment and maintenance.
Can it be maintained?
Yes, if maintenance is planned from the start: updated dependencies, tests, reversible migrations, backups and an owner to operate it. Running a custom application costs more than running a content website, and that should be clear before work begins.
Do you work with agencies?
Yes. Work can be delivered as external capacity for an agency, with scope and confidentiality agreed and without contacting their end client unless asked. The commercial relationship stays with them.
How is the price set?
After the diagnosis, with the scope written down: what is built, what is excluded, what is delivered and what maintenance it needs. No figure is published beforehand because it would change with users, integrations and permissions, and an invented figure does not help anyone decide.
What happens to existing data?
It is reviewed during diagnosis: where it lives, in what format, who uses it and how consistent it is. Migration is planned with a prior copy and checks, and live data is only touched with authorisation and a rollback plan.