Skip to main content

Services / Secure Build

Secure Build · we build it for you

We build it for you. Secure from day one.

Websites, internal tools, automations, integrations and AI workflows for small and mid-sized businesses — designed against a threat model before anything is built, and handed over with documentation and a written risk summary. Security is part of the build, not bolted on after.

Tell us what you need → All services
BeforeThreat model first
DuringLeast privilege by default
AfterHandover with a written risk summary

What we build

Five kinds of build. One standard.

Practical software for businesses that do not have a development team, or whose team is already busy. Each build is held to the same security baseline, whatever its size.

01

Websites

Marketing sites, customer portals and web apps. Hardened configuration, a patching plan, and no plugin sprawl.

02

Internal tools

Dashboards, admin panels, trackers and small line-of-business apps your team uses every day, with sign-in and permissions done properly.

03

Automations

Scheduled jobs and workflows that remove manual copy-and-paste: reports, reconciliations, alerts, document handling.

04

Integrations

Connecting the systems you already run (CRM, finance, ticketing, identity) through their APIs, with credentials scoped to what each job needs.

05

AI / LLM workflows

Assistants, document processing and agent workflows built on large language models, with clear limits on what data the model sees and what it is allowed to do.

Not on this list?

Tell us the job

If it runs on a server, in a browser or against an API, describe what it needs to do and we will tell you plainly whether we are the right fit.

Tell us what you need →

Secure by default

What that means in your build.

Every build ships with these in place. Where one does not apply to your project, the handover says so and explains why, rather than leaving it out quietly.

ControlWhat it means in your build

01Threat modelling before build

Before the design is final we write down what the system holds, who would want it and how they would get at it. The design answers that list; it is not retrofitted to it.

02MFA, SSO and least-privilege access

Sign-in through your identity provider where you have one, multi-factor for anything administrative, and roles that grant only what each person or service needs.

03Secrets management

No passwords or API keys in code, chat or spreadsheets. Secrets live in a vault or the platform secret store, are scoped per environment, and can be rotated without a rebuild.

04Encrypted data

TLS in transit everywhere. Encryption at rest for databases, backups and file storage, with the keys held separately from the data.

05Dependency and vulnerability checks

Third-party packages are pinned and checked against known-vulnerability feeds during the build and before release. The application is scanned and tested before handover.

06Hardened hosting

Servers and cloud services configured to a hardened baseline: minimal open ports, patched images, separate environments, and administrative access that is restricted and logged.

07Logging and backups

Security-relevant events are logged where you can read them. Backups are automated, stored away from the primary system, and restored at least once before handover to prove they work.

The security review before handover uses the same verification approach as our system and application security reviews →

How it works

Scope. Build. Security review. Handover.

01

Scope

A call to understand what it must do, who uses it and what data it touches. You get a written scope, a threat-model summary and a quote. Nothing starts until you approve it.

02

Build

Built in short, visible increments against the agreed scope. You see working software early, in an environment kept separate from anything live.

03

Security review

Before handover the build is tested against its threat model: access, data handling, dependencies and configuration. Findings are fixed, or documented with the reason.

04

Handover

You receive the code, the accounts and the documentation: how it is built, how to run it, how to restore it, and a written risk summary of what remains and why.

You own what we build. Code, accounts and documentation are handed over, not held.

Optional · ongoing care

Keep it secure after launch.

Software is not finished at handover. If you would rather not look after it yourselves, we can. This part is optional and agreed separately from the build.

Updates

Framework, dependency and platform updates applied on a schedule, with security patches prioritised.

Monitoring

Uptime, errors and security-relevant events watched, with alerts that reach a person.

Periodic re-checks

The build re-tested against its threat model at agreed intervals, and after any significant change.

Questions

Before you ask us to build.

What kinds of things do you build?
Websites, internal tools, automations, integrations between systems you already run, and AI / LLM workflows. Most projects are small to mid-sized: one clear job, done well. If you are unsure whether yours fits, describe it in the form and we will tell you plainly.
Can you work on something we already have?
Yes. We can extend or rebuild an existing system. We start with a short review of what is there, so the scope reflects its real state rather than how it was described.
Who owns the code and the accounts?
You do. Code, repositories, hosting accounts and credentials are handed over at the end. Where we set up accounts on your behalf, they are created in your organisation’s name.
What does the security review cover?
Access control, data handling, secrets, dependencies and hosting configuration, tested against the threat model agreed at scoping. You receive the findings, what was fixed, and a written summary of any risk that remains.
How do you handle AI and LLM builds safely?
We decide up front what data the model may see and what actions it may take. Tools get least-privilege access, untrusted content is treated as untrusted so it cannot redirect the model, and consequential actions need a person to approve them. Prompts and outputs are logged so behaviour can be reviewed.
Do you host it for us?
Either way works. We can deploy to hosting you already have, or set up hardened hosting in an account you own. We do not lock a build into infrastructure that only we can reach.
How is a build quoted?
After a scoping call we send a written scope and a quote. Nothing starts until you approve it, and changes to scope are agreed in writing before they are built.
What happens after handover?
You can run it yourselves with the documentation provided, or add ongoing care: updates, monitoring and periodic re-checks. That part is optional and agreed separately.

Request a quote

Tell us what you need built.

Describe the job in plain language: what it should do, who will use it, and what it needs to connect to. We reply to arrange a short scoping call, then send a written scope and a quote.

  • ✓ Plain language is fine — no specification needed
  • ✓ A written scope and quote before any work starts
  • ✓ You own the code, accounts and documentation

Prefer email? hello@cyentrix.com

Plain text only — put any web address in the field above, not in this box.

We’ll only use your details to reply. No spam, no sharing.

Already built?

Have it reviewed instead.

If the system already exists, a system and application security review shows where it stands, with verified findings and the fix for each one.

See the review →