Some problems are not a website. They are a process: a request that moves through states, people who may only see their own records, approvals that must be recorded, and a report somebody rebuilds by hand every month. We build these as custom web applications on Drupal's entity and permission system, so sign-in, roles, audit history and admin screens start as tested infrastructure, and the budget goes into your rules, your dashboards and the integrations with the systems you already run.
Who this is for
- A process runs on spreadsheets and email. The spreadsheet is the application: no permissions, no audit trail, and one copy that matters.
- A subscription nearly fits. The tool covers most of the process, and the rest is done by hand around it, or it cannot be changed at all.
- Several organisations share one system. Each company, branch or partner sees its own records and nothing else. The application we built from scratch for CreAct works this way: each company using it has its own permissions.
- Staff need an intranet or a portal. Documents, tools and personal dashboards behind a login, like the SPREP staff intranet Fagogo. More on intranets and portals on Drupal.
- Customers apply and track online. Applicants submit their documents and follow the status, and staff work through each case in an admin view, as in the visa applications we built for H&N Corporation.
What you get from an application build
- A working application on your own infrastructure
- Roles and permissions modelled on how work flows, not on a list of job titles
- Workflow states and approvals, each change recorded in an audit trail
- Dashboards, reports and exports built for the people who use them
- Integrations with the systems you already run, each with its failure behaviour defined
- Automated tests on the code we ship, and documentation for operators and administrators
Example An approval workflow, state by state
- Draft The applicant fills in the form and uploads documents. Only they can see it. Audit entry: created
- Submitted The record locks for the applicant and appears in the reviewers' queue. Audit entry: submitted
- Reviewed A reviewer checks it, or returns it with notes until it is complete. Audit entry: returned or passed
- Approved A manager with approval rights signs it off; the applicant is notified. Audit entry: approved
- Reported The record counts in the dashboard and the monthly export, with no one rebuilding it by hand. Audit entry: exported
An engineer reads it and replies within one business day.
How an application build runs
An application lives or dies on its data model, so the entities, roles and permissions are what you see running first, before the screens are finished. Changing an entity relationship at that point is cheap; changing it after reports and integrations depend on it is not.
How a web application build runs
- Discovery Who does what, in what order, and what has to be recorded, broken down into entities, roles and integrations. Output: the process map
- Prototype The entity model and admin screens running on your own data, before you sign, for you to correct. Output: the prototype
- Fixed price Quoted once the model runs and every integration has an owner and a way in. You keep the architecture document
- Build Workflow, permissions, dashboards and integrations, shown working on staging as each part lands. You keep the repository
- Acceptance Each role walks through its own tasks on real data before launch. You keep the test record
- Warranty Defects in what we built are fixed by the team that built it. You keep the handover pack
When building beats subscribing
Most operations should buy software rather than build it, and we say so when that is the answer: a subscription that nearly fits is often cheaper than a system that fits exactly. Building earns its cost in fewer situations, and the table is how we test for them.
| Question | Subscribe | Build |
|---|---|---|
| The process | Follows the product's model of the work | Follows yours, including the exceptions |
| Your data | Held by the vendor, under the vendor's terms | On infrastructure you choose, when rules or contracts require it |
| Permissions | The roles the product offers | Modelled on who may see and change what |
| Integrations | The connectors the vendor built | Whatever your other systems offer |
| Cost as you grow | Rises with every user | A build cost, then hosting and maintenance |
| Leaving | An export, if the vendor provides one | You hold the source code and the database |
There is a middle route. Our own platforms are applications of this kind: MineRooms for hotels, MineCourt for court bookings and MineTickets for ticketing, each with bookings, payments and roles already working. When your process is close to one of them, starting from it costs less than starting from nothing: see platform implementation.
Integrations decide the timeline
The screens are rarely what makes an application late. The integrations are, and usually for reasons that have nothing to do with code: an API nobody has credentials for, a system whose owner has not agreed to the project, a data export that turns out to be a person running a report by hand.
Integrations around a web application A typical shape; your systems decide the real one
Single sign-on Your identity provider
HR system Staff and roles
SAML or OpenID Connect
Your application Workflow, roles, approvals and reporting on Drupal
REST APIs and webhooks
CRM Contacts and cases
Accounting Invoices and payments
So we establish in writing, before the price is fixed, which systems must be connected, who owns each one, how it authenticates and whether a test environment exists. Anything without an answer is flagged then, not discovered in the sprint that depends on it. Where a system cannot be reached, the application is designed to work without it and to take the connection later.
Applications we have built
Beside CreAct and H&N above: an intranet with personal dashboards for SPREP staff, and the back office of our own hotel platform, which runs live at mine-rooms.com.
CreAct's project owner, on the application we built for them:
Working with the WeebPal development team has been a real pleasure. For creact.ae, they built us a completely custom, highly tailored application that truly has its own unique character.
What a custom web application costs
An application is scoped from its entity model and its integrations: how many distinct things the system tracks, how many roles see them differently, and how many external systems have to stay in step. The price is fixed once that model is running on real data.
Applications usually sit higher on the pricing ladder than websites of a similar size, because the cost is in the rules rather than the pages. Search, staged approval and two-way traffic with systems of record put a build in the Large band; everything behind a login, with roles deciding what each person reaches, is Secure Portal / Intranet; a system that runs the work itself, with live links to ERP, CRM or finance, is the Enterprise band. What each includes is on the pricing page.
Work we have delivered
The full case studies behind the screenshots on this page.
-
Creact (CAB/ICAB)
Custom web application built from scratch for CreAct: CAB process documents, iCAB strategy visualisation, per-company permissions.
Read the case study -
H&N Corporation
A Drupal site that brings H&N Corporation's services together, with online Vietnam visa and passport applications. Built and maintained by WeebPal.
Read the case study
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Why build on Drupal rather than a bare framework?
Because a large share of any business application is users, roles, permissions, audit history and an admin interface. Drupal has those tested and maintained. Starting from a bare framework means rebuilding them and owning their bugs.
How do you handle permissions that do not fit neat roles?
Few organisations fit neat roles, so permissions are modelled on how work flows rather than on a list of job titles: who may see a record, who may change it, and at which state. That model runs in the prototype, on your own data, before anything is committed.
What about dashboards and exports?
They are built for the people who read them, not as a developer tool. If somebody rebuilds a report by hand every month, tell us early: that is usually the feature with the clearest return.
What if a system we need has no API?
We find out before the price is fixed, not in the sprint that depends on it. Where a system cannot be reached, the application is designed to work without it and to take the connection later.
What if the requirements change during the build?
They will. That is why you see working software early and each part as it lands: scope decisions are made against something real. Material changes are re-scoped openly rather than absorbed silently.
Can our own developers take it over?
Yes. It is standard Drupal with documented custom modules, coding standards and tests, so the people who can maintain it are the people who can maintain Drupal. More on continuing without us is in our FAQ.
Not covered here? Ask us directly.
Describe the processAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Headless and Decoupled Drupal
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Describe the process, not the screens
Tell us who does what, in what order, and what has to be recorded. The entity model falls out of that, and so does a clear view of whether this needs building at all.
An engineer reads it and replies within one business day.