Our process
How we work
One process, whether we are building something new, starting from a platform we already run, or taking over a site somebody else built. What changes is what you see at step two, not the shape of the work.
-
-
Share your pain point
Fifteen to thirty minutes. You describe the problem, we ask what the system has to do, who uses it and what it has to talk to. No proposal is written at this stage, because there is nothing yet to write one against.
-
We show you how it works
A design, a clickable prototype, or a working demo on real code. What you see depends on where you are starting from, and it is the first thing we produce rather than the last.
-
Demo and discussion
You click through it and tell us what is wrong. We change it before anything is signed, because a correction here costs a conversation and the same correction after the build costs a change order.
-
-
-
Contract and deposit
Scope written down, price fixed against it, milestones agreed. You are signing against something you have already used, not against a document describing something that does not exist.
-
Build and complete
You see working software every week and say what to change. Scope decisions get made against something running, which is the only way they get made honestly.
-
Approve
We hand you a system we have already tested against what was agreed, and walk you through it. Nothing deploys until you have approved it. Approval is yours to give, and withholding it is not a difficult conversation.
-
-
-
Deploy and launch
Server setup, data migration, go live. The cutover is planned so your current system stays available until the new one has proven itself, and every existing address keeps working.
-
Warranty
One year by default, up to three on development projects, agreed in writing before the work starts. Defects in what we built are fixed by the team that built it, and Drupal core and contributed security releases are applied during the term, at no charge.
-
Maintain and grow
New features, upgrades and support when you want them, on a separate agreement you can end. The warranty does not depend on you buying it.
-
Step two
What you see before you commit
The second step is the one that differs, and it is the reason the rest of the process holds. For a new build or one of our platforms, it is a prototype or a working demo, made at no charge before anything is signed. For a site somebody else built, it is the paid takeover audit, because nobody can commit to a system they have not read.
-
Starting from a platform we already run
See the platformsA working demo built from the real code of a platform already in production, configured towards your case. Not slides, and not a mockup: software you can use badly and see what happens.
-
Building something new
Drupal developmentThe entity model and the admin interface, running against your own content. Editorial workflows, roles and languages are far cheaper to change at this point than after the build, so this is where we spend the time.
-
Taking over a site somebody else built
Maintenance and takeoversThe paid takeover audit: what is actually deployed, with root causes rather than symptoms and the risks ranked, in a report you keep whether or not you continue with us.
Compare
Ways to work with us
The process above is the same in each. What changes is who signs with us, who holds the code and the warranty, and how the work is priced.
Who signs, who owns the code, and how it is priced
| Way of working | Who signs with us | The code | Warranty | How it is priced |
|---|---|---|---|---|
| A fixed-price project | Your organisation | Yours from the first commit | 1 year by default, up to 3 years, with core and contributed security releases applied | A fixed price once the architecture is agreed, in the project tiers |
| Monthly maintenance | The site's owner, including for a site we did not build | Stays yours | Not a warranty: maintenance picks up where the warranty leaves off | A monthly agreement |
| White-label work for an agency | The agency; its client signs with the agency | Delivered into the agency's repository; the client receives the system and its source code | Held by the agency: 1 year by default, up to 3 years | A fixed price per project, quoted to the agency |
| A dedicated team | Your agency or organisation, which directs the team | Yours, or your client's, from the first commit | On development projects, held by the party that signs with us | Monthly, by role |
| A platform implementation | Your organisation, or your agency with us deploying under its name | You receive the running system and its source code | 1 year by default, up to 3 years, on what we build for you | In the project tiers, by what the finished system has to do |
A named place in an agency's tender or consortium is subcontracting, compared with white-label work and a reserved team on partners. The tiers, the monthly agreements and the rate for each role are on pricing.
What we build
The kinds of system this applies to
Platforms and web applications
Workflows with states, roles, approvals and reporting. Portals, dashboards, booking and learning systems. Built on Drupal’s entity and permission model so authentication, audit trails and admin interfaces are solved infrastructure rather than bespoke code you maintain forever.
Drupal sites that carry a brand
Corporate and multilingual sites where the content model has outgrown a simple CMS: several editorial roles, structured content reused across contexts, systems that must stay in step. Accessibility and performance are build requirements, not a later purchase.
Work on systems already running
Migrations off Drupal 7 and ageing platforms, version upgrades, security and accessibility audits, and maintenance on sites we did not write. The starting point is always reading what exists, because nobody can commit to a system they have not read.
Commitments
The same commitments every time
These do not vary with the size of the engagement or with how you came to us.
Full source code
Yours from the first commit, not at handover. You can host it anywhere and hire anyone to continue it, including instead of us.
A warranty on development work
One year by default, up to three, on development projects, with the term written into the contract before the work starts. The security releases of Drupal core and contributed modules are applied while it runs.
Drupal and open source
Standard, community-backed tooling. Nothing in the stack exists only because we sell it.
AI-assisted engineering
AI tooling is part of how our engineers work, under the same review gates and test coverage as everything else. It changes how fast the work goes, not who is answerable for it.