how we work

Every engagement nura takes on is governed by our PLAN, DESIGN, BUILD, STATUS programme, and the weight of that programme scales to the job, not the other way round.

Every case study on this page is real work, and carries a number we can stand behind.

Worksop Workspace homepage

Worksop Workspace

A public website, and wwOS, the operating system behind it, rebuilt subsystem by subsystem from an audited prototype to launch-ready.

worksopworkspace.com
websiteoperating systembookingsevents
full PLAN → DESIGN → BUILD → STATUS programmeread the case study →
South Yorkshire Property Buyers homepage

South Yorkshire Property Buyers

A lead-generation site and backend built fast, with AI doing the heavy lifting on page architecture and form handling, plus the Google Ads sat on top of it.

southyorkshirepropertybuyers.com
websitebackend automationGoogle Ads
fast AI co-build, no formal programmeread the case study →
Mockup of a campaign dashboard showing five phases, progress and an approval gate

AI Campaign Management

A governed dashboard where an AI model plans and runs a marketing campaign from public data and a spreadsheet, reporting its own progress phase by phase.

AI dashboardlead scoringcampaign ops
governed PLAN → DESIGN → BUILD → STATUS programmeread the case study →
Diagram of Freshworks and BigChange connected through an n8n bridge

CRM Bridge

A governed n8n bridge joining Freshworks and BigChange two-way, so sales and operations finally share one history per client.

integrationn8nCRM
governed PLAN → DESIGN → BUILD → STATUS programmeread the case study →

data infrastructure

live marketing
data

Five systems held the numbers a business actually runs on — ad spend, web behaviour, bookings, accounts — and none of them spoke to each other. Answering “did that campaign pay for itself” meant a morning of exports. Now one nightly pull lands all five in one warehouse, layered so that raw data is never what a report reads.

5separate systems, one place to ask the question
PythonBigQueryMeta AdsGA4ClarityWellnessLivingXero
Meta AdsGA4ClarityWellnessLivingXeroNIGHTLYconnectorsWAREHOUSErawoperationalreportingdashboardreads reporting only
Five systems that never talked to each other, pulled nightly into one warehouse and layered raw → operational → reporting. Nothing reads the raw tables, so a source changing shape cannot silently break a number on the dashboard.

website

a site built from data,
with an SEO optimised migration

Ninety-nine routes, and almost none of them written by hand. The pages people arrive on are generated from content files, so re-organising the whole site around what customers actually need was an edit to a data file, not a fortnight of copy-paste. The hard part was never the build — it was landing eighty-one old URLs on the right new page without losing the search traffic.

99routes, from three content sources
static siteYAML content model34 testsredirect map
needs.yamlsite.yaml64 postsbuild99 routes7 need pages64 posts28 other81 legacy URLsredirects80 of 81 verified onto a live route
The site compiles from three content sources, so restructuring it around customer need is a data edit rather than a rebuild. The redirect layer is the part that protects the existing search traffic — eighty of the eighty-one old URLs are verified onto a live route.

audit

auditing a CRM,
re-igniting its potential

Years of automations had accumulated and no one could say what most of them did, or which ones were quietly emailing the whole database. We pulled the entire estate using the API, kept the raw response so nothing was lost to summarising, tiered every workflow, and designed the eight outcomes the estate now gets rebuilt against.

352automations inventoried, none switched off blind
read-only APIworkflow triagetagging protocol
CRM~6,900 contactsread-only API352 workflows228 marked publishedTRIAGEDtier Atier Btier C8 target outcomeswhat gets rebuilt
“Published” is a status field, not proof that anything runs — the CRM’s API returns no enrolment figures at all. That distinction is why nothing was deleted on the strength of this pull, and why the tagging protocol that came out of it makes a workflow countable from outside the CRM.

AI tooling

the AI now talks
to your data

Auditing a CRM by hand could take a fortnight. We built an MCP connector that lets Claude query the CRM directly — twenty-eight tools query the API. Thirteen of them read. Fifteen of them can write, and none of those can touch a live account until someone deliberately arms them. Every write tool will also show you the exact request it would send for approval.

28tools — and zero writes until approved
Model Context ProtocolPython stdlibCRM v2 API
ClaudestdioMCP SERVER13 read tools15 write toolsalways allowedoff by defaultCRMpublic v2 APIdry run — returns the exact request, sends nothing
The gate is the whole point. A connector that can change six thousand customer records is only safe if refusing is its resting state — so writes need an environment flag, the right API scopes, and a human turning them on.

want to see how we'd approach your build?

We'll tell you honestly whether your project needs the full programme or a fast, direct build before we start either one.

book a conversation