---
title: "Bespoke CRM & Database Development Company, Norfolk"
description: "RD Research are a leading bespoke software development company offering database, CRM & ERP development in and around Norwich, Norfolk. Call us today."
canonical_url: "https://rdresearch.co.uk/our-process"
last_updated: "2026-07-16T16:00:44.079Z"
---

<container color="blue">

# Our Process

What follows is why our projects are delivered so reliably and why we can confidently say this: **we do not charge for bug fixes and no support is needed.**

Just like our <span className="text-rdr-gold">

software

</span>

 the text below was written by a <span className="text-rdr-gold">

human

</span>

.

<br />

## <span className="text-rdr-gold">Built on clarity</span> from the beginning

Successful software projects start before a single line of code is written. Below is some of what we do but given this is a public website we won’t disclose everything here.

Every project begins with a detailed proposal and technical summary, prepared by us at no cost to the client. It gives you a clear understanding of our proposed solution, scope and the technical approach.

</container>

<container color="black">
<service-design-partners :evenSplit="false" :slotThreeActive="false">
<template v-slot:one-left="">
<service-design-partners-left :start="0" :stop="2" label="OUR PROCESS / PROPOSAL" title="Detailed Proposal and Technical Summary">

Unlike many software companies, we start by writing a detailed proposal that includes a technical summary, at no cost to you.

This allows you to:

- Understand how the system might work.
- What key modules may be required.
- Try different ideas.
- Fully understand where costs are incurred.
- Compare different solutions at an early stage

</service-design-partners-left>
</template>

<template v-slot:one-right="">
<service-design-partners-right alt="Developers and designer collaborating over technical documents" className="block,aspect-16/10,w-full,object-cover" color="blue" src="/images/services/web-design-partners/designer_and_dev.jpg" caption="This is a real image of the technical proposal and documentation being created.">



</service-design-partners-right>
</template>

<template v-slot:two-left="">
<service-design-partners-left :start="1" :stop="2" label="OUR PROCESS / SPECIFICATION" title="Detailed Specification">

Once the proposal is agreed, we produce a full written specification. This includes screen designs, key modules, process flows, report outputs and the functional detail needed to guide development properly.

This specification-first approach is why we consistently deliver on time and on budget and why we never charge for bug fixes. It achieves three things:

1. This stage lets you to review the system in depth before coding starts. Clients often refine ideas as the project progresses and a strong written specification makes that possible without creating any disruption.
2. It lets us give you an exact quote as we will then know exactly what we are developing. You are under no obligation to proceed after the specification is written.
3. It lets you see exactly what the system will look like and how it will work at the outset. The only time this does not apply is when it is a pure research project.

This approach is one of the main reasons our projects stay on time and on budget.

</service-design-partners-left>
</template>
</service-design-partners>
</container>

<container>
<service-design-partners :evenSplit="false" color="blue">
<template v-slot:one-left="">
<service-design-partners-left :start="0" :stop="1" label="OUR PROCESS / STANDARDS" title="Coding Standards">

We do not rely on shortcuts, fashionable quick fixes or unclear code that becomes difficult to support later. Vibe coding is definitely not on the menu.

We maintain and update our own internal Software Engineering Company Policy each year. The current document, authored in April 2026, covers coding standards, version control, code review, database management, documentation, CI/CD, secure coding and broader engineering principles. It is designed to be the team’s single source of truth and to keep standards consistent across all projects.
Our standards include structured code, consistent naming conventions, documented functions and classes, peer review before code reaches production and a strong emphasis on readability and maintainability.

The policy also sets out framework and language standards across PHP, Laravel, Vue, JavaScript and TypeScript, alongside expectations around testing, documentation and separation of concerns.

The result is: reliable code that is cleaner, more stable, easier to extend and far less likely to create problems later.

</service-design-partners-left>
</template>

<template v-slot:one-right="">
<service-design-partners-right alt="A stack of detailed specifications" className="block,aspect-16/10,w-full,object-cover" color="blue" src="/images/our-process/specifications.png" caption="Image of real internal and external specifications. (Also avaliable in PDF format)">



</service-design-partners-right>
</template>

<template v-slot:two-left="">
<service-design-partners-left :start="0" :stop="1" label="OUR PROCESS / SECURITY" title="Security Best Practices">

Security is built into our process, not added at the end. Our internal policy sets out secure coding practices, secure communication standards, environment management and access control. It specifically covers SSL/TLS and HTTPS for secure communication, secure handling of configuration through environment variables rather than hard-coded credentials and ongoing attention to patching, monitoring and operational security.

In practice, we go further. We use SSL as standard and we apply two layers of encryption to sensitive data: software-level encryption within the application and hardware encryption at infrastructure level. This layered approach helps protect your data both in transit and at rest. There are also other techniques we employ that we won’t go into detail on a public website but happy to discuss in detail with you.

</service-design-partners-left>
</template>

<template v-slot:three-left="">
<service-design-partners-left :start="2" :stop="3" label="OUR PROCESS / DEVELOPMENT" title="Development and Testing Process">

Our process is built around controlled modular development and practical client feedback.

We develop in clearly defined modules, allowing features to be reviewed and tested as they are completed. Code is deployed first to our **sandbox** environment, where clients can see functionality taking shape and test features safely before anything reaches the live system. Our internal policy also reflects this staging approach, with GitHub, Docker and a sandbox server forming part of the CI/CD workflow before production release.

We also make feedback easy. Each screen includes a built-in bug reporting and improvement tool, so users can click the relevant area, add a note and send it directly to us. It means bugs, change requests and improvement ideas are captured quickly and in context.

Alongside this, we use a unique testing module that helps ensure every field, process and workflow is tested properly. This makes testing faster, more thorough and reliable. This is another reason our systems are so dependable and why we **do not** need to charge for bug fixes or ongoing support.

</service-design-partners-left>
</template>

<template v-slot:three-right="">
<service-design-partners-right alt="A developer developing a client's website" className="block,aspect-16/10,w-full,object-cover" color="blue" src="images/services/web-design-partners/developer_coding.jpg" caption="A real image of Dean building an integration with a 3rd party application.">



</service-design-partners-right>
</template>
</service-design-partners>
</container>

<container color="black">
<service-design-partners :evenSplit="false" :slotThreeActive="false">
<template v-slot:one-left="">
<service-design-partners-left :start="0" :stop="1" label="OUR PROCESS / DEPLOYMENT" title="Deployment Process">

When a module has been approved it is prepared for live deployment through a controlled release process. Our development policy already formalises this staged workflow: code is developed in branches, reviewed, tested, deployed to sandbox, then promoted to production once approved.

For the client, this means deployments are structured, low-risk and carefully managed. Changes are introduced in sensible stages rather than large, disruptive launches. We also maintain a rollback process, so if an unexpected issue ever arises, the system can be reverted quickly and safely.

The goal is straightforward: smooth releases, minimal disruption and complete peace of mind.

</service-design-partners-left>
</template>

<template v-slot:one-right="">
<service-design-partners-right alt="The billing process" className="block,h-full,object-fit" color="blue" src="images/our-process/flow.png" caption="Our development process">



</service-design-partners-right>
</template>

<template v-slot:two-left="">
<service-design-partners-left :start="0" :stop="1" label="OUR PROCESS / BILLING" title="Billing Process">

We agree staged payments across the development of the project, so billing is aligned with progress and clear milestones. This keeps the process transparent and fair for both sides.

Where appropriate and subject to suitable credit references, we can also offer payment over a significantly longer period. Most importantly, the final payment is not due until you sign the project off and are entirely happy with it.

Our clients stay with us for good reason, our solutions are reliable and so are we.

</service-design-partners-left>
</template>

<template v-slot:two-right="">
<service-design-partners-right alt="The billing process" className="block,aspect-16/10,w-full,object-cover" color="blue" src="images/our-process/billing.jpg">



</service-design-partners-right>
</template>
</service-design-partners>
</container>

<contact-us-section color="blue">



</contact-us-section>

<app-footer color="black">



</app-footer>