The website a Melbourne conveyancing practice has to stand behind
Choosing a conveyancer happens fast. Someone has a contract in hand, a settlement date already moving toward them, and perhaps 10 minutes to decide who to call.
In that window a website has to explain a process most people go through a handful of times in their lives. It also has to show, by how carefully it is built, that the firm behind it is careful too.
RET Conveyancing is a licensed conveyancing practice in Melbourne. Conveyancing is the legal transfer of property, and the firm covers the full range of it, including the work many firms would rather pass on:
- self-managed super fund work
- trust work
- subdivisions
- developer work
It is a small, director-led team whose whole positioning is precision and low risk, which is a high bar for a website to meet.
What we built: Drupal 11, a component library and client intake forms
The site runs on Drupal(Opens in a new tab/window) 11 with a single page type and a library of components the team stacks to build any page:
- heroes, media and text bands
- service grids and icon cards
- statistics and explainer steps
- team profiles and testimonials
- FAQ accordions
- an office map with opening times
Each editorial component has a matching front-end component in the theme, one to one, so what an editor assembles is exactly what a visitor gets. For the firm, that means a new page is something their own team assembles, not a job that comes back to us.
The firm also takes work in through the site: an enquiry form, and 4 client intake forms covering a purchase, a sale and the matched pair either side of a related-party transfer. We built them natively in Drupal rather than on a separate form product, which means:
- one interface for the team
- one place where uploaded documents live
- every file scanned before it is stored
That last part matters when the uploads are identity documents and contracts.
How the build stayed predictable: one blueprint, a generated backlog
A small site is no reason to improvise. We started from one versioned blueprint describing the whole content model and generated the delivery backlog from it, each story naming what it depends on.
Components were built before the pages that assemble them, so by the time page building began, every part a page needed already existed. We were just as deliberate about what not to build: established Drupal modules carry the forms, search, maps and opening hours, and only the presentation is custom.
The design reference lived in the repository as a static prototype beside the code, which turns "does it match the design" from an opinion into a difference anyone can point at. And when the finish date moved by a day, we sent that as its own note before anyone had to ask. For a client who chose us on precision, that is the only shape bad news should take.
Vortex: the same machinery a government platform runs on
This is the part we would most like people to notice. The site is built on Vortex(Opens in a new tab/window), our open-source Drupal project template, and inherits everything that comes with it:
- a build, test and deploy pipeline that runs on every change
- separate development, staging and production environments
- dependency updates that arrive automatically as pull requests
- coding standards and static analysis enforced automatically
- automated browser tests over the journeys that matter
None of that is remarkable on a government platform. It is remarkable on a small practice's website, and it should not be.
The investment in that tooling was made years ago, so the marginal cost of bringing it here was close to nothing. What the firm gets for it is a site that takes updates through automated tests, deploys through the same pipeline on every change, and could be handed to any competent Drupal team tomorrow.
What that buys a small firm is time: updates arrive as pull requests to review rather than a project to schedule, so the team only touches the site when they have something to say.
Where it stands: built, handed over, kept current
The build ran through June 2026 and went to the firm for review with a written guide to building pages, adding media, managing menus and reviewing enquiries. We have kept the platform current since: core and the project template were last updated in late July 2026.
A small practice's website, running the same build, test and deploy pipeline a government platform runs on.
A website for a small practice does not need heroics. It needs to stay current, stay fast, and keep working quietly while the team gets on with settlements.
That is a maintenance question as much as a build question, and it is the part small sites most often go without.
For firms whose website is the first proof of care
Everything on this page is 4 of our services running on one small practice's website: UX and design, Drupal development, DevOps and hosting on an automated pipeline, and ongoing support and maintenance. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If you run a conveyancing practice, a law firm, or any small professional business where the website is the first evidence of how carefully you work, this is the shape the engagement takes: a component library your own team builds pages from, intake forms that accept client documents safely, and a platform kept current after handover.
If your client intake still arrives as email attachments, or your site is old enough that nobody wants to touch it, tell us how the work comes in.