Drupal Project FAQ: Working with WeebPal

A development company that also maintains its own platforms, and the distinction matters when you are deciding how to engage us.

We build and run our own platforms: EverLMS, MenuNerds, MineRooms, MineCourt and MineTickets, each already in production rather than on a roadmap. We also build custom systems for clients, and maintain systems other people built.

The practical consequence: where your requirement is mostly a solved problem, starting from a platform already running shortens delivery without thinning the scope. Where it is not, we build it, and the patterns proven in our own platforms carry over into the new build.

The platforms are at platforms; the client work we are free to publish is in case studies.

Different kinds of buyer, each on a different contract.

• Agencies who need Drupal engineering under their own brand. We work in your repository, to your process, and your client never meets us. Source code is assigned to you, the warranty is held by you, and the NDA is signed before requirements are shared.
• Organisations buying a system directly. The architecture is agreed first, the price is fixed against it, you own the source code from day one, and the build carries a warranty of one year by default, extendable up to three.
• Partners and operators taking one of our ready-made platforms to their own market under their own name, deployed together with us.

If you are not sure which one you are, the first call sorts it out faster than a form does.

Partner programme · how a project is priced · platforms.

WeebPal has built on Drupal since 2012, from Ho Chi Minh City. The company is independent: no holding company, no investor with a preferred vendor, and no reseller agreement that pays us to recommend one thing over another.

Rather than ask you to take that on faith, here is what you can inspect before signing anything:

• The code we give away. WE Mega Menu, Component Builder and a library of free themes are published with their issue queues. Reading them is a reasonable way to judge how we write code before you pay us to write any.
• The work we can name. Case studies with the organisation, the scope and the stack, including public-sector programmes such as SPREP and PRISMSS.
• What clients say, attributed. Reviews carry names, roles and organisations rather than initials.
• A reference call. Ask, and we will approach a current client whose system resembles yours.

Worth knowing about that list: work delivered under an agency partner's brand is theirs and is never published as ours, so the portfolio is deliberately smaller than the delivery record.

Drupal 11 is our default for systems where content has structure, permissions have to be granular, publishing happens in more than one language, and other systems need to read and write through an API. That is a narrower claim than "Drupal is best": it is the class of problem we have spent since 2012 on.

Around it we use what the job needs: Twig and SCSS in the theme layer, Vue 3 where an interface needs real interaction, Flutter only when a web project we are building genuinely needs a native client, and Python with language models where a feature is actually machine learning rather than a search box.

When we would say no: a brochure site with a handful of pages and one editor does not need Drupal, and a product whose entire value is one real-time interface is usually better built as an application with a thin backend. We would rather say that on the first call than discover it in month three.

The whole stack is listed at our technology. What a Drupal engagement looks like: Drupal development.

Our work clusters where software has to last and be handed over rather than replaced every few years.

• Government and public sector: public websites, staff intranets, document libraries and regional programme sites. Published work includes SPREP, the Pacific Islands Roundtable and PRISMSS.
• Education: learning platforms and training portals, including JFC System Australia's training platform, built on EverLMS.
• Nonprofit and intergovernmental: programme and knowledge platforms for organisations that report to their members.
• Corporate and enterprise: internal portals and operational platforms, including CreAct and H&N Corporation.
• Hospitality, sports and recreation and e-commerce: booking, venue and commerce platforms, often built on our own.

If your sector is not on that list, the useful question is not which industry you are in but what the system has to do. Most of what makes a build hard is structure, permissions and integrations, and those travel across sectors.

Yes. Ask, and we will approach a client whose system resembles yours and ask whether they are willing to take a call. We do not publish a list of people willing to be phoned, because consent is given per request rather than once.

Before that call, this is already on the record: reviews attributed to named people at named organisations, case studies with the scope and the stack, and open-source modules whose code and issue queues you can read without asking us for anything.

A limit worth knowing: work delivered under an agency partner's brand is theirs, and we neither name it nor offer it as a reference. That is the same confidentiality you would be buying.

Against an architecture, not against a brief. A brief describes what somebody hopes for; an architecture describes what has to be built, and only the second can carry a fixed price.

So the sequence is: we agree what the system has to do, we design the architecture, and then we commit to a price and a date together. The price does not move unless you change what is in scope. Where the architecture cannot be settled from a conversation, we say so and work it out with you before the contract rather than guessing, alongside a prototype you can see running. None of that is invoiced.

Work that starts from one of our platforms is priced as adaptation rather than invention, because the thing already runs and you can see it running before you commit.

What we will not do is quote a number before we know what carries it. An estimate given at that stage is a sales figure, and it is recovered later as change requests.

The published ladder, from Micro to Strategic, with what each size includes and how it is engaged: pricing.

Our pricing is a ladder of system shapes rather than a menu of packages, because what drives cost is the shape of the thing rather than the page count. In order: Micro, Small, Medium, Large, Extra Large, Enterprise, Multi-Entity and Strategic.

What moves a project up a step is usually one of a short list of things:

• Content stops being hand-placed and becomes a model with types, listings and filters.
• A second language arrives, and every other requirement multiplies by it.
• The audience becomes known, so identity and permissions turn into architecture: who you are decides what exists.
• An integration has to write back to a system of record rather than only read from it.
• The platform stops supporting a business process and becomes it, so availability turns into an operational risk.
• More than one entity, brand or country needs its own site under shared standards.
• A regulator, an insurer or a board wants evidence rather than assurances.

Most projects sit between one size and the next, which is exactly what the first call is for, including the times it turns out smaller than you feared. And the ladder starts at Micro, so small work is welcome: a single module, an audit or a migration assessment are all things we take on their own.

What each size is and how it is delivered, step by step: pricing.

No. Nothing is due before you have seen the idea running, as a proof of concept or a product demo, and every payment after that lands on something you can check for yourself. The schedule follows the size of the project:

• Micro and Small: paid at kickoff, against a scope already written down, and at go-live and handover.
• Medium to Extra Large: paid at kickoff, again after you have tested the complete system yourself and approved it, and at go-live and handover, with documentation and training.
• Enterprise and above: a deposit starts the programme, and each phase (foundation, core delivery, then scale and migration) is funded as it is accepted against written criteria, followed by hypercare under an SLA. Change control, steering cadence and escalation are agreed before kickoff rather than invented during it.

The signed contract records the terms for your engagement.

The share of the price due at each milestone, by size: pricing.

Before any contract, we turn the requirement into something you can look at: a design, a clickable prototype, or a working demo on real code, depending on the size. On larger programmes that includes the architecture, the content or data model and the integration map, with the hardest constraint proved on real code.

None of it is invoiced, and if you do not go ahead, nothing is owed for it. If you do, the fixed price is committed against the scope that work produced.

Audits are different: an audit is paid work, and you keep the findings from a security audit or an accessibility audit whether or not you hire us to fix anything in them.

What happens before the contract at each size: pricing.

It will change. A scope that survives a build untouched usually means nobody was looking at the increments. So change control is written into the contract rather than improvised when the first change arrives.

• Adjustments inside an agreed increment, such as wording, layout, the order of a form or a field that should have been there, are handled as part of that increment. That is what reviewing working software every week is for.
• Changes that move the architecture, such as a new integration, a different role model, a second language or a workflow that did not exist, get an impact assessment in writing: what it does to the date, what it does to the price, and what it displaces. You approve before anything is built.
• Nothing is absorbed silently and nothing is billed silently. If we think a change is a bad idea, we say so, and then build it if you still want it.

The reason the price holds is that it was fixed against an architecture rather than a brief, so both sides can tell when the architecture has actually moved.

How scope, price and the milestones fit together: pricing.

We commit to a date at the same moment we commit to a price, and for the same reason: both rest on an agreed architecture. Anything offered before that point is an estimate, and we will tell you which of the two you are being given.

If something puts the date at risk, you hear it when we know rather than at the milestone. That is the practical value of reviewing working software every week: a slip is visible in the increment well before it is visible in the plan.

Delivery dates, change control, how delays are notified, remedies and any compensation are set out in the signed contract for the engagement. We would rather negotiate those terms with you before the project than discover we disagree about them during one.

You own the source code from day one rather than on final payment, so stopping does not leave you with nothing to show for it. Everything produced up to that point, including code, designs, documentation and the discovery output, is already yours and already in a repository you control.

Commercially, you pay for the milestones delivered. Pausing and resuming later is possible, and the real constraint is the availability of the same engineers rather than a penalty.

The exact terms, covering notice, what happens to work in progress and how a paused engagement is restarted, are in the contract before you sign it, not discovered at the point you need them.

What "you own the source code" specifically covers: you own what we build.

Yes, and before requirements are shared rather than after. A mutual NDA signed before a codebase, a requirement document or a client name changes hands has been the starting position on every partner engagement since 2012.

What people assume an NDA covers, which it does not, so they are separate clauses:

• Non-solicitation, both ways. An NDA covers information. It does not stop anyone approaching your client or hiring your developer. That is written in at signing, runs in both directions, and lasts for a term the contract sets.
• Source code assignment. Confidentiality is not ownership. Bespoke work is assigned to you from the first commit, and when the work starts from one of our platforms, you receive the whole running system and its source code.

Yes. We complete security and accessibility questionnaires, answer WCAG 2.2 AA and Section 508 questions in the frame your buyer uses, provide the architecture and test evidence a technical evaluation asks for, work to a programme board and your PMO, and deliver alongside other suppliers under joint governance. At the Strategic size an independent assessor reviewing our design is an expected part of the process rather than an obstacle to it.

What we will not do is claim a certification we do not hold. If a tender requires a specific scheme, name it at the start and we will say plainly whether we qualify, rather than everyone finding out at the compliance stage.

Accessibility obligations by regime, whether WCAG, Section 508 or EN 301 549, are explained at accessibility audit. How programmes are governed by size: pricing.

It depends on the shape of the system, which is why a delivery horizon is published for each size on the pricing ladder rather than averaged into one number here. A compact informational site and a multi-entity platform are not the same species of work.

What sets the date more than anything else:

• Whether we start from a platform already in production or from nothing. Adaptation is faster than invention, and it is faster in a way you can verify, because the thing already runs.
• Migration. On any system with history, mapping and reconciling the old data is frequently the longest workstream, and the one most often left out of early estimates.
• Your side. Content readiness, approvals and the availability of whoever signs off. At the smaller sizes this is usually the critical path, not engineering.

The date is committed at the same point as the price: once the architecture is agreed. Before that you get a range and we will say it is a range.

With a call of fifteen to thirty minutes. You describe the problem; we ask what the system has to do. By the end of it we will usually tell you which size on the ladder this honestly is, including the times it turns out smaller than you feared, and whether one of our platforms already does most of it.

What we will not ask for is a specification first. Requirements written in prose are agreed by people who each picture something different. So the next step is something you can look at: a design, a clickable prototype, or a working demo on real code, depending on the size.

Where the requirement genuinely needs an architecture before anyone can quote it, we will say so, and that architecture work also happens before the contract, without an invoice.

Tell us what you are trying to do.

That the opening steps of our process, listed below, happen before there is a contract, and they are not invoiced.

1. You describe the problem and we ask what the system has to do.
2. We show you how it works: a design, a clickable prototype, or a working demo on real code, not a slide deck describing one.
3. You click through it and tell us what is wrong. We change it while changing it is still free.

Only then comes the contract and the deposit. The point is not generosity; it is that a prototype is corrected by people looking at the same thing, and a specification is agreed by people imagining different ones.

A programme large enough that an architecture has to exist before anyone can responsibly quote it follows the same rule: the proof of concept and the architecture come before the contract, and they are not invoiced either.

Every step, and how much rigour each carries at each size: pricing · how we work.

You see working software every week: running, on a staging URL you can open yourself, rather than a status report describing it. The formal sprint demo and its cadence are set per size and published on the pricing page; the weekly increment is the default underneath them.

Your side of it is smaller than people expect, and it is concentrated in specific places:

• One named owner who can make decisions. That matters far more than how many people attend.
• Review of each increment, which is where changing direction is cheap.
• Content and approvals, which at the smaller sizes is the critical path.
• User acceptance testing before deployment. Nothing is deployed until you have tested the complete system yourself and said so.

Sessions run on your calendar and are recorded, so the person who could not make the hour is not the person who finds out last.

Named people, and you are told if that changes rather than discovering it in the commit log.

How many people, and in which roles, follows the size of the project. The teams they come from, and what each one does, are on our team page.

We are organised around delivery rather than around accounts, which has a consequence worth knowing: the people who design a system are the people who build it and the people who fix it under warranty. That is most of why a multi-year warranty is affordable for us to offer: nobody has to learn the codebase before they can fix it.

We use AI assistance through the workflow: analysis, drafting, documentation and test generation. We are not going to pretend otherwise. What matters to you is who is accountable, and that does not change: we are.

Concretely:

• Architecture, review and the decision to ship are human, and named.
• Everything passes the same gates regardless of how it was drafted: Drupal coding standards enforced by PHPCS, static analysis with PHPStan, and automated tests in PHPUnit and Playwright.
• The warranty does not distinguish between a defect a person wrote and one a tool suggested. It is a defect in what we delivered, and we fix it.

If your organisation needs a specific restriction on tooling, or on what may be sent to a third-party model, raise it before kickoff and it goes into the agreement, where it is enforceable, rather than into a paragraph on a website, where it is not.

Where AI is the product rather than the tooling, that is a separate practice: AI solutions.

Automated test coverage ships with the code rather than being offered as an extra, because it is what makes the code maintainable by somebody who is not us.

• PHPUnit for unit and kernel tests on custom modules and business logic.
• Playwright for functional tests that drive the real interface, including the journeys that matter most to your users.
• PHPCS against the Drupal coding standard, so a reviewer on your side can read the code without a handover meeting.
• PHPStan for static analysis, which catches the class of defect that only appears on the unhappy path.
• Manual QA, including keyboard and screen-reader testing, because an automated scan finds only part of what is wrong and almost none of what matters most.

Then user acceptance testing on your side, against the agreed scope, on your own content, with the defect list worked to zero before release. We do not deploy on our own opinion that it is finished.

As a standalone engagement on somebody else's codebase: quality assurance.

Our working day is Indochina Time, UTC+7. That is a shared working day with Australia and New Zealand, and hours of overlap with Europe and the UK every afternoon. With North America the work runs asynchronously around a fixed daily handover window, agreed at the start rather than negotiated incident by incident.

• Your tools, not ours. We join your tracker, your repository and your branching model. Jira, GitLab, Google Meet and Zoom are our defaults, and we switch to whatever you already run.
• English throughout, including every document and every commit message.
• Recorded reviews, so the people who could not make the hour are not the people who find out last.
• One route in and one route out. Your contact talks to our engineer. Nobody improvises a new channel during an incident.

The overlap window and the escalation path are settled before kickoff. Deciding them during the first outage is how distributed teams actually fail.

Only if you decide they should. The default is that they do not.

• We are not named to your client and we do not contact them.
• We never invoice your client and never appear in their vendor list.
• We hold no credential of theirs that you did not issue to us.
• Work delivered under your brand is not published as our case study, now or later.
• If you want one of our engineers on a client call, that happens under your brand, on your bridge, with your introduction.

The NDA is signed before a codebase, a requirement or a client name changes hands, which has been the starting position on every partner engagement since 2012.

The thing that actually damages an agency in a subcontracting arrangement is rarely malice; it is an email sent to the wrong person during an incident. So the communication rules are settled before the work starts: one route in, one route out, and if something breaks in production we tell you what we know and what we do not, and you decide what your client hears and when, because you are the one who has to say it.

White-label Drupal development · the partner programme.

Yours, and yes: from the first commit, in your own account.

A subcontractor who shows you the code only at handover is asking you to carry a risk you cannot price. So we join your tracker, your repository and your branching model, and work to your definition of done and your release cadence. You do not write a process document for us and we do not ask you to adopt ours. Where your standards are stricter than ours, we work to yours.

What travels with our people rather than with the client is the engineering baseline: code review, Drupal coding standards enforced by PHPCS, static analysis, and automated test coverage on what we ship. That is what lets a reviewer on your side read the work without a handover meeting.

Drupal subcontracting for agencies.

Bespoke work is assigned with full source from the first commit to you, as the party that signs with us, and onward to your client if that is how you contract with them. We do not sit in the middle of that chain and we do not need to be asked twice.

When the work starts from one of our ready-made platforms, we deploy it together with you, and your client receives the running system and its source code. Customisation we build on top of a platform is a development project and is assigned like any other.

What "full source code" specifically covers: you own what we build. Platform partnerships: the partner programme.

Your agency does, as the party that contracts with us: one year by default, extendable up to three, agreed before the work starts.

That arrangement exists so the warranty runs along the contract chain rather than across it. What you promise your own client is yours to set, and you are never in the position of relaying our terms to somebody who has never heard of us.

The boundaries, stated plainly. The warranty covers defects in what we built, not new features: the same exclusions as any other engagement. And it cannot follow code we did not write: on an inherited codebase what we can offer is a maintenance agreement, plus a warranty on whatever we subsequently build.

Escalation is agreed in the same conversation as everything else: who to reach out of hours, what counts as critical, and what the first response target is. Our published targets are four hours for critical issues, one business day for high priority and three business days for normal. Those are first-response targets rather than resolution commitments; anything tighter belongs in your agreement and is set per engagement.

Full terms including exclusions: warranty policy.

Yes, at signing, and in both directions. It covers your clients and your staff, and ours.

It is a separate clause from the NDA on purpose. An NDA covers information; it does not cover approaching a client or hiring a developer. Agencies who assume one implies the other tend to find out at the worst possible moment.

We work with agencies who also sell Drupal, sometimes into the same market. That is precisely why the clause is written down rather than left to good intentions.

These commercial arrangements get called the same thing. What separates them is what you are buying and when you pay for it.

For live sites there is also white-label support and maintenance, a monthly retainer patching, fixing and answering tickets under your name, including on sites we did not build.

For an organisation rather than an agency, the equivalent of a reserved team is outsourced Drupal development: a senior team without recruiting one, at a fixed price once the architecture is agreed.

How each is priced: fixed once the scope has edges, reserved by the month where it does not. The published bands are on pricing.

With one contained piece of work: a module, a security or accessibility audit, or a migration assessment on a codebase you have inherited.

That is a cheap way to learn how somebody actually works before a deadline depends on it: how they write, how they estimate, and what they do when they find something unwelcome. The assessment is a deliverable you keep whether or not you continue with us, and it is written to be handed to a developer or to a client without translation.

We would rather you did that than sign a large first engagement on the strength of a proposal. So would you.

Offboarding is something you do, not something you have to be granted.

• Access is revoked on your side. You remove us from the tracker, the repository and any environment you granted. You do not need our cooperation to do it.
• Nothing only runs on our machines. No build step, no deployment path, and no credential that is not already yours.
• Documentation is a deliverable, written for a developer who has never met us, which is the only useful test of whether it is any good.
• What we hold afterwards, such as working copies, credentials and client material covered by the NDA, is set out in the agreement rather than assumed, and we follow whatever retention and deletion terms you set.

The test of all of it is whether another Drupal team could pick the work up. Being replaceable is the property you should be buying.

Yes, and that is usually the whole point. Agencies rarely lose a Drupal client on the build. They lose them later, when the developer who built it has left, security advisories keep landing, and nobody on staff wants to own a codebase they did not write.

A white-label support retainer is scoped per site, because a brochure site and a Commerce platform with several integrations are not the same commitment. It covers security advisories for core and contributed modules on the agreed schedule with urgent ones handled out of band, bug fixes against a defined ticket allowance, backups with a restore actually tested rather than assumed, and uptime and error monitoring with alerts that reach a person.

We take tickets from your system, write in the voice and format your client already receives, and everything that goes back out carries your name. Your client pays you and talks to you.

Taking over a site we did not build starts with an audit rather than a contract, because nobody can commit to a system they have not read.

White-label support and maintenance.

The platforms below are already running in production rather than on a roadmap:

• EverLMS: enterprise learning management on Drupal 11, with courses, chapters and lessons, a range of quiz types, automated certificates, Zoom, H5P and SCORM, payment integration, multilingual.
• MenuNerds: restaurant ordering and management, from table service and the kitchen to the counter and multi-store franchises.
• MineRooms: hotel booking and operations, with a soft-hold reservation model that closes the overbooking window during checkout, plus multi-property, channel management, housekeeping and in-room ordering.
• MineCourt: sports facility and court booking and management.
• MineTickets: multi-sector booking and ticketing.

Each can be demonstrated on request and adapted to your market. There is no per-booking commission and no per-user fee: what you run is a system, not a subscription that meters you.

More are in development and will be released over time; we list them when they are in production, not before.

All of them, with feature detail and user guides: platforms.

Your client receives the whole running system and its source code. What a partnership adds is how the platform is deployed: together. You bring the market and the client relationship; we deploy, adapt and upgrade the platform with you, under your name, and we do not appear in the relationship unless you decide we should.

Neither side takes the platform away to deploy it alone, so every deployment stays on the maintained platform. Territory, exclusivity, fees and renewal are set per partnership, before you commit.

Customisation we build for you on top of a platform is a development project and carries the project warranty.

A bespoke build is simpler: you own the code from the first commit, with no licence and nothing to renew.

The partner programme · why we contract ownership the way we do.

On the axes below, and they only start to matter once the system is doing real work.

• Where the data lives. Self-hosted on infrastructure you choose, in a database you can export. Not in a tenant you rent.
• What you may change. Any business logic, because you have the source. Not whatever the plan tier happens to expose.
• What you pay. No per-user fee, no per-transaction fee, and no renewal that has to keep rising for the vendor's model to work.

Where no-code and SaaS genuinely win is the simple end: a landing page, a small brochure site, an MVP you intend to throw away. We will say so rather than sell you a platform for it.

They stop winning at the point you need multi-role approval workflows, deep integration with an ERP, a CRM or a legacy system of record, or the ability to be audited by somebody who wants to read the code. That is the line, and it is worth locating honestly before you build on either side of it.

Yes. That is a custom build, and it does not start from zero.

The patterns proven in our own platforms carry over: booking and availability lifecycles, assessment and certification engines, pricing and rule models, multi-role permission structures, and the operational screens somebody actually has to use at seven in the morning. Those are the parts that take longest to get right when they are invented from scratch, and we have run them in production long enough to know where they break.

Where the requirement is a product: product development. Where it is workflow rather than publishing: web application.

You bring the market and the client relationship; we deploy and adapt the platform together with you, under your name, and stay behind the code. Your client receives the running system and its source code.

Branding is yours completely: logo, domain, interface, everything your client sees. We do not appear in the relationship unless you decide we should, and work delivered under your name is not published as ours.

What comes with the partnership: technical documentation, training for your team, a priority support route to our engineers, and delivery under your name to your client. Deployments are done together rather than by either side alone, so every deployment stays on the maintained platform and improvements can reach all of them.

On a platform partnership we take the minority share and you take the majority. The exact terms are agreed per partnership, before you commit, and they are not renegotiated once you depend on the platform.

The partner programme, including how a platform deployment is shared.

It depends on who carries which risk, and these are the shapes we use:

• Revenue share: you sell and operate, we supply and maintain the platform, and revenue is split at an agreed ratio.
• Joint venture: both sides invest in customising the platform for a market and both exploit it.
• Retainer plus share: a fixed customisation fee for the work that has edges, plus a longer-term share.

Whichever applies, we take the minority share and you take the majority, and the reasoning is the same in each case: you own the market position, which is the part we cannot do for you, and we keep the platform maintained for every deployment.

Territory, exclusivity, fees, renewal and what happens at the end are agreed per partnership before you commit.

Partner programme.

Yes. Keeping the core current is our side of the arrangement: every deployment runs on the maintained platform, so an improvement to the core can reach all of them.

• Security advisories and defect fixes on the core are applied throughout the partnership.
• Feature releases and major version upgrades reach partners, with the timing and any migration work set out in the partnership contract.
• Your own customisation is built so that core upgrades do not overwrite it. That is a design requirement of the platform rather than something negotiated per release.

Technically, nothing traps you. The platforms are built on Drupal, which is open source, written to Drupal coding standards and documented, so another Drupal team can read them. Client data sits in a database you can export, on infrastructure you choose. There is no proprietary runtime and no licence server.

Your clients keep what they received: the running system and its source code. What we agree per partnership, before you commit, is the practical part:

• What happens to customisation in progress.
• Who supports those clients during the transition, so nobody is handed between two companies at the worst possible moment.

Partner programme.

Yes. Drupal 11 is API-first, with JSON:API, REST and GraphQL, and we have integrated with payment providers including PayPal and Stripe, conferencing and learning standards including Zoom, H5P and SCORM, marketing and CRM platforms, and legacy ERP systems reached over whatever interface they actually offer.

The question that decides the cost is not whether an integration is possible but which direction it runs. Reading from a system of record is usually straightforward. Writing back to one, which means reconciling conflicts, handling partial failures and deciding which system is authoritative when the two disagree, is real engineering, and it is one of the things that moves a project up the size ladder.

Where a system has no usable interface at all, say so early. That case is solvable and it is not cheap, and it belongs in discovery rather than in the middle of a build.

Integration-led builds are our web application practice; where the front end is separate, headless and decoupled Drupal.

Self-host on any server or cloud you like: AWS, GCP, Azure or your own datacentre. Or let us run it. The choice is yours and it can be reversed later, because nothing proprietary runs on it.

The managed option: managed Drupal hosting. Pipelines, environments and deployment: DevOps and hosting. Why there is no runtime to be tied to: you own what we build.

The running cost follows from the structure of the system rather than from a price list: there is no licence fee, no per-user fee and no per-transaction fee, so your running cost does not rise simply because the system is being used more.

What you do pay for:

• Hosting, sized against your actual traffic and your availability requirement. A small site and a high-availability platform with separate environments and disaster recovery are different orders of expense.
• Domain and TLS, which are negligible.
• Maintenance, if you want dependencies moved forward, backups verified, monitoring watched, and security releases applied and tested once the warranty term ends (during it, they are applied under the warranty). That is a separate agreement from the warranty, priced from the state of the system rather than from a page count.
• Any third-party service you chose, such as a payment provider, a CDN or an email sender: billed by them, to you.

Worth sizing honestly during discovery rather than after launch: the availability target, because high availability costs real money, and whether a compliance regime obliges you to keep environments you would not otherwise run.

Development bands, separately from running costs: pricing. What maintenance covers: support and maintenance.

Drupal core has a good security record and a dedicated security team. Almost every compromised Drupal site we have been called to was not compromised through core: it was running a known-vulnerable contributed module, an over-permissive role nobody had reviewed, or a file directory the web server was happy to execute.

So the work is a structured pass over the places Drupal sites actually fail, and it is the same list whether we are auditing yours or building ours:

• Every installed module checked against the published advisories, with abandoned modules reported separately from out-of-date ones, because the remedy is different.
• Composer dependencies audited, including the ones you never chose and pulled in transitively.
• Every role read against what it can actually do. The findings here are usually the most serious and the least expected.
• Dormant administrators, shared logins, and whether an administrator can be created without anyone noticing.
• Upload validation, what a private file directory really protects, and whether anything writable can be executed by the web server.
• Text formats and which roles reach the permissive ones; custom form handlers that build queries or render markup themselves.
• Exposed REST and JSON:API resources, what a leaked key can do, and whether credentials sit in configuration that reaches version control.
• TLS, security headers, error verbosity in production, and whether the administrative paths are reachable from the public internet.

Findings come back classified critical, high, medium and low, so they can be triaged rather than read end to end. On a self-hosted system the data never leaves infrastructure you control, and nothing reports back to us.

As a standalone engagement, on your site or on one you inherited: Drupal security audit. Continuous patching afterwards: support and maintenance.

Yes, and the difference between the two is worth getting right, because it confuses procurement far more than it confuses engineering. WCAG is the technical standard; version 2.2 is current and AA is the level almost every policy points at. Section 508 is United States federal procurement law, and since the 2017 refresh it incorporates WCAG by reference, so a Section 508 obligation is in practice a WCAG AA obligation plus documentation duties. EN 301 549 in European procurement, the UK public sector regulations and AODA in Ontario all point at the same standard.

How we work to it: accessibility is built into the templates rather than retrofitted, and it is verified by manual keyboard and screen-reader testing as well as by automated scanning. An automated scan finds only part of what is wrong and almost none of what matters most: a keyboard trap in a mega menu, a modal that does not return focus, a data table nobody can navigate by column header.

From the Strategic size, independent WCAG 2.2 AA assurance is an acceptance gate rather than a self-declaration.

On an existing site, an audit returns every finding mapped to the success criterion it fails, with severity judged by what it blocks and a recommended fix specific enough to be estimated. The report is yours whether or not we fix anything in it.

Drupal accessibility audit.

The technical foundations are built in rather than bolted on: clean URLs, controlled metadata, structured data where the content genuinely warrants it, an XML sitemap, correct canonical and redirect handling, and the performance work that page experience actually depends on.

What no agency and no CMS can honestly promise is a ranking. Search results depend on your content, your competition, your site's technical health over time, and continued measurement. Most of that is outside our control, and the rest is only inside it while we are engaged.

The one thing worth insisting on at build time is redirect preservation through a migration. More organic traffic is lost to unredirected URLs at relaunch than to anything else we see.

Drupal development · migration and upgrade.

Natively. Drupal translates interface, content, taxonomy, menus, configuration and URLs, with no ceiling on the number of languages and no third-party plugin holding it together.

The part that is not automatic, and that decides whether a multilingual site actually works:

• A translation workflow: who drafts, who reviews, who publishes, and what happens to a page in one language when the source changes in another.
• hreflang and canonical handling, so search engines serve the right market the right page.
• Acceptance testing per language. Layout, typography and translation checked in every market, not only the primary one. Text expansion breaks designs that were only ever reviewed in English.
• A named contact per market, because conflicting feedback from two markets has to be reconciled into one direction before anything is built.

Worth knowing in advance: a second language multiplies almost every other requirement, which is why it is one of the things that moves a project up the size ladder.

Everything we build is responsive and tested at real device widths, so a phone user gets the whole system rather than a reduced version of it. For most requirements that is the right answer, and a native app would be an expense with no corresponding gain.

Where a native app is genuinely warranted, for offline use, push notifications or hardware the browser cannot reach, we build it in Flutter against the same REST API, as part of the web project rather than as a separate practice. We do not take standalone app work.

Our own platforms are built API-first for the same reason, which is what makes a mobile client possible later without re-architecting the back end.

Headless and decoupled Drupal · the stack.

Capacity on Drupal is a sizing decision rather than a ceiling: caching layers, a CDN and horizontal scaling are ordinary architecture, not heroics. Systems we have built run in production for organisations including SPREP, the intergovernmental environment programme for the Pacific region, and JFC System Australia, whose training platform runs on EverLMS.

What we do rather than assert it: load-test and size each system against its own projected peak before go-live, and give you the results. If the numbers say the architecture will not hold, that is a finding to act on before launch rather than a surprise on the first busy day.

The cases that actually hurt are rarely average traffic. They are the predictable spike: enrolment opening, results day, a campaign deadline, a public announcement. So name yours during discovery and the architecture gets sized for the peak you already know is coming.

DevOps and hosting.

Yes: Drupal 7 to Drupal 11, WordPress to Drupal, and legacy PHP applications, as work we take on directly and for agencies.

What a migration actually consists of, in order: an audit of the existing codebase and content model, a field-by-field data map, migration scripts that are run repeatedly rather than once, a trial migration you inspect before anybody commits to a date, redirect preservation from every old URL, and a rehearsed cutover.

What is preserved: content and its revision history where the source has one, users and their roles, media and the references to it, and taxonomies. What honestly is not: a design built on assumptions the old system made, and custom code depending on APIs that no longer exist. Those are rebuilt, and saying so during discovery is the difference between a migration that lands and one that stalls at eighty percent.

The trial migration is the part to insist on with any supplier. It converts the unknown into a list.

Drupal migration and upgrade · upgrade to Drupal 11 and 12.

One year as standard on development projects, extendable up to three. The term is agreed before the project starts and stated in the contract rather than offered afterwards.

The same team that built the system does the warranty work. That is most of why a multi-year warranty is affordable to offer and useful to hold: nobody has to learn the codebase before they can fix it.

Covered work carries no additional charge for the agreed term.

Published first-response targets are four hours for critical issues, one business day for high priority and three business days for normal. Those are targets for our first response rather than resolution times; operating hours, severity definitions and escalation are set in the support agreement for your system.

Full terms including the exclusions: warranty policy. What happens after it ends: support and maintenance.

They get sold as one thing and they are not, which is how a buyer ends up paying monthly for something they were told was included.

An SLA is something else again, and not a category of work at all: it is the set of measurable commitments attached to whichever of warranty and maintenance is in force: severity definitions, response targets, operating hours, escalation. It is priced for what it obliges us to staff, because a commitment to answer at three in the morning has to be staffed at three in the morning, and pretending otherwise is how it fails the first time it matters.

We will tell you which of these you actually need, and it is often less than was being sold.

Warranty policy · support and maintenance.

You do, from day one: not on final payment, and not on a handover date that can be missed.

What that covers specifically: the repository, meaning application code, custom modules, theme, build tooling and deployment configuration. Not a compiled artefact and not access to a hosted instance. It is built on Drupal and open-source infrastructure, so it runs on your servers, your cloud account or ours, and no per-seat fee or annual renewal is required to keep your own system running.

The practical test of ownership is whether another team could pick it up. That is why Drupal coding standards, automated test coverage on the code we ship, and documentation written for a developer who has never met us are deliverables rather than extras.

If your system starts from one of our ready-made platforms, you receive the whole running system and its source code as well, and the customisation built for you on top of it is yours like any other bespoke work.

The full position, including why we contract this way: you own what we build.

An availability commitment is a separate agreement from the warranty, and it is priced for what it obliges us to staff rather than published as a number that costs nothing to print. So the honest answer is: yes, where you need one, written per engagement.

What already applies without a separate SLA are the published warranty first-response targets: four hours for critical issues, one business day for high priority, three business days for normal. Those are first-response targets, not resolution or availability commitments, and we would rather you read them that way than be surprised later.

What a managed hosting or maintenance agreement covers as standard: backups taken, with a restore actually tested rather than assumed; uptime and error monitoring with alerts that reach a person; and security releases applied and tested on the agreed schedule, with urgent advisories handled out of band.

What goes into an SLA when you need one: the availability target and how it is measured, severity definitions, operating hours and time zone, the escalation path, and any remedies. From the Strategic size, high-availability architecture with rehearsed disaster recovery and a performance test against the agreed SLA is an acceptance gate rather than a promise.

If you are self-hosting, we provide the architecture and the monitoring setup; the availability commitment then belongs to whoever operates the infrastructure.

Managed Drupal hosting · DevOps and hosting · warranty policy.

Yes, and handover is treated as a deliverable rather than a final meeting. A project is done when it is running in production and your team can operate it, not when it changes hands.

• Training by role, on your own system with your own content. An editor, an approver and an administrator need different sessions, and one generic walkthrough serves none of them.
• An architecture walkthrough for whoever will hold the technical side, whether that is your developer or another agency.
• Written documentation, plus guides for the tasks people actually repeat. It is written for someone who has never met us, which is the only useful test of whether it is any good.
• Recorded sessions, so the person who joins your team next year is not dependent on somebody's memory.

Drupal's editorial interface is learnable by non-technical staff, and the configuration work that makes it so, such as sensible field labels, help text and a form arranged in the order a human fills it in, is part of the build rather than an afterthought.

If you would rather not run it in-house: support and maintenance.

Yes, and making that true is a design goal rather than a courtesy.

You have the full source from day one, in a repository you control. The code follows Drupal coding standards, so a developer who has never spoken to us can read it. Automated test coverage ships with it, so another team can change something and find out whether they broke anything. Documentation is written for a developer who was not there. There is no build step that only runs on our machines and no deployment only we can reach.

The practical test of ownership is whether another team could pick it up, which is exactly why those things are deliverables rather than extras. Being replaceable is the property you should be buying.

When your system starts from one of our ready-made platforms, you receive the whole running system and its source code as well. Customisation built for you on top of the platform is a development project and is assigned to you like any other.

You own what we build · platform partnerships.

As scheduled work, on a separate agreement from the warranty. The warranty covers defects in what we built, and a new feature is not a defect. Conflating the two is how people end up disappointed by both.

In practice that means small fixed packages where the work has edges, or a monthly arrangement where the roadmap is continuous. Either way changes are planned and released rather than handled as emergencies, and the system is built modular so extensions do not destabilise the core.

Security releases for core and contributed modules are applied and tested on the schedule agreed with you, with urgent advisories handled out of band. Module end-of-life warnings come with the reporting, because the expensive version of that problem is the one nobody mentioned for two years.

Support and maintenance.

Yes. The service is deliberately not restricted to our own work.

It starts with an audit rather than a contract, because quoting work on a codebase nobody has read is a guess with a number attached. The audit establishes which Drupal version is running and how far behind security releases it is, what custom code exists and what it does, which contributed modules are in use and whether any were modified in place, what the system integrates with, where the security exposure is, and what is undocumented enough to be dangerous. These questions in particular have an uncomfortable answer more often than you would expect: whether the code in the repository is the code that is running, and whether a restore from backup has ever actually been performed.

The output is an honest assessment including the bad news, and it is a deliverable you keep whether or not you continue with us. Sometimes the answer is that the system is in reasonable shape and needs updating and documenting. Sometimes it is that a component will not survive the next platform upgrade and should be replaced on a planned schedule rather than in an emergency. Sometimes it is that the site needs a migration before maintenance is worth paying for at all, and we would rather say that than bill monthly for holding together something that should be replaced.

The boundary: a warranty cannot follow, because nobody can warrant code they did not write. What we can offer is a maintenance agreement on the inherited system, and a warranty on whatever we subsequently build.

Support and maintenance · where the system is on an end-of-life version, Drupal migration and upgrade. There is a step-by-step version in your agency disappeared: how to take the site back.

A fair question to ask any supplier, and the arrangements that answer it are all made at the start rather than at the end.

• You hold the full repository from day one, in an account you own.
• It runs on Drupal and open-source infrastructure, so it can be hosted anywhere without our permission and without a proprietary runtime.
• Documentation is written for a developer who has never met us, and automated test coverage ships with the code, so another team can verify their own changes.
• Your domain, DNS and hosting accounts should be in your organisation's name, with us holding access rather than ownership. We will set it up that way if you ask, and we would suggest it if you did not.

None of that depends on our continued goodwill, which is the point. A warranty is a promise from a company; source code ownership is what turns a broken promise into an inconvenience rather than a rebuild.

You own what we build · warranty terms.