Skip to content
CipherCruCipherCru

Menu

Web Development

Web Development Services

Platforms your team can extend after we leave. We decide what should be built, then build it in slices that go live as they are finished.

Typical duration
Six to fourteen months
Team shape
Two to five senior engineers
Starts with
A three-week diagnostic

Web work that survives the handover

Most web platforms are not hard to build. They are hard to keep changing two years later, once the people who built them have gone.

What makes a platform expensive later is almost never the framework it was built on. It is that the reasoning was never written down: why the data model splits where it does, which system is authoritative when two disagree, what the retry actually does when the payment provider is slow. Two years on, those answers live with people who have moved on, and every change starts as an investigation before it becomes a change. So we write the decisions down as they are made, and we build in slices your engineers work on alongside ours from the first month, which is what makes a handover an administrative event rather than a project of its own.

Two engineers working at a shared screen
Pairing with the client team is how handover actually happens.

What usually goes wrong, and what we do instead

The failures we are called in to fix are rarely about the code.

What we are usually called in to fix

  • A platform only its original authors can safely change
  • Features built to a specification nobody re-checked against the business
  • Infrastructure held together by one person's memory
  • A test suite that passes and proves nothing
  • A roadmap made of workarounds for an integration that was never finished

How we work instead

  • Diagnose the business constraint before proposing a system
  • Ship a real slice in the first month, in production
  • Write down every significant decision and why it was made
  • Hand over as we go, so there is no handover project at the end
  • Leave infrastructure your team can rebuild from source

What we build

Ten kinds of web engagement. Most clients need two or three of them, and the first conversation is usually about which.

What that involves

The capabilities behind the work, including the ones clients most often did not know to ask for.

Product engineering

Features built in slices, each one live and usable before the next is scoped.

Data modelling

One record of truth per domain, and figures that reconcile back to it.

Integration

Translation layers rather than data copies, so no second source of truth appears.

Platform and delivery

Pipelines and environments your team can rebuild from source.

Performance

Measured against real traffic profiles, not a synthetic benchmark.

Security and access control

Roles, audit trails and secrets handling built in from the first commit.

What we build with

Chosen for what the system has to do and who has to run it afterwards.

  • TypeScript
  • React
  • Next.js
  • Angular
  • Tailwind CSS
  • Vite

Where we have built this

Sectors where we have shipped production web systems and know the constraints before the first meeting.

A banking hall desk where a laptop shows an account dashboard with a running balance, recent transactions and a monthly activity chart, a phone beside it

Fintech & BFSI

Secure, reliable systems for businesses built on trust.

We build and modernize financial platforms, workflows, integrations, and customer-facing applications where reliability, data integrity, auditability, security, and performance are fundamental to the business.

A clinician talking with a patient at the bedside while a monitor shows that patient's record - vitals, scans and recent reports - with the same case open on a phone

Healthcare

Technology that connects complex care and operational workflows.

We help build digital healthcare platforms, operational workflows, integrations, and data-driven applications designed around reliability, secure information handling, usability, and the realities of interconnected healthcare systems.

A lecture room seen from the back, a laptop in the foreground playing a course video beside its numbered module list, the same course open on a phone

EdTech & eLearning

Learning platforms designed around engagement and scale.

From learner journeys and course delivery to assessments, administration, analytics, and integrations, we develop education platforms that make learning experiences easier to operate, evolve, and scale.

A cafe table by an airport window with a laptop open on a travel booking screen showing destinations and dining, a passport, a boarding pass and a phone beside it

Food & Travel

Digital experiences that keep customers and operations moving.

We build customer journeys and operational platforms around ordering, booking, marketplaces, partner integrations, administration, and real-time workflows where experience and operational efficiency need to work together.

What you end up with

Stated from your side rather than ours.

  • A platform you own outright

    Source, infrastructure and decision history, in accounts registered to you.

  • A team that can keep changing it

    Your engineers ship alongside ours from the first month, not after handover.

  • Something live in the first month

    A real slice in production, so the risk is tested before the budget is.

  • A written record of every decision

    Why each choice was made, and what would make us revisit it.

How a web engagement runs

The same five stages whichever of the services above does the work.

Diagnose

What the business needs, what constrains it, and what already exists.

Decide

Options with trade-offs, and a written recommendation. Sometimes it is to stop.

Prove

The riskiest assumption tested in production, on real data.

Deliver

Built in slices, each one live and usable, documented as we go.

Hand over

Your team runs it with us watching, then without us.

Questions about web development

The ones we are asked most often before a first conversation.

Will you work on a codebase someone else wrote?
That is most of what we do. The first weeks go on reading rather than committing: what the application does, where the load actually falls, which dependencies are pinned to versions that no longer get security fixes, and how much of the test suite is testing anything. You get that back as a written assessment with the risks ranked, including the parts we would leave exactly as they are. Where the honest recommendation is a staged modernisation rather than a rebuild, that is what it will say, and it will say what the first stage should be.
Do you always use React and Next.js?
No, though it is where we start for most product work, because the hiring pool is deep enough that you can staff it after we leave. Angular is the better answer where an enterprise front end is already standardised on it. Where the interface is mostly forms over a well-understood domain, a server-rendered application on the stack your team already runs will beat a single-page app you then have to hire for. The question the diagnostic answers is who maintains this in three years, and the framework follows from that rather than the other way round.
Is design included, or do we bring our own?
Either works. Our designers sit in the same team as the engineers building the screens, and we are equally happy treating your design system as a constraint we work inside. What does not work is design finished in isolation and handed over as a specification: whoever does it, the person designing a screen and the person building it have to be in the same conversation, because that is where the cost of a decision becomes visible.
How large a team will you put on this?
Small and senior. Two to five engineers is the usual shape for a web platform, one of them accountable for delivery and the technical lead genuinely writing code rather than reviewing it. We do not staff a build with a large junior team and a manager to coordinate them, because coordination cost grows faster than output does. Where the work genuinely needs more people than that, it usually needs to be split into pieces that can ship independently first.
Who hosts it, and who pays for that?
You do, in cloud accounts registered to you, billed to you directly rather than through us. We size it, define it as code and run it with you during delivery, but at no point are we standing between you and your own infrastructure. A platform you cannot deploy without calling us is not a platform you own.
What happens after launch?
Launch is a stage, not the end of one. By the time the platform is live your engineers have been shipping slices alongside ours for months, so releases, rollbacks and the monitoring are already theirs to run. What we agree separately is how much of our time you want afterwards, and that is a decision you make having watched the platform run rather than one written into the contract at the start.

Have a web platform to build or fix?

Tell us the constraint you are working under. We will tell you how we would approach it.

Strictly necessaryEssential for the site to function: page navigation, security, session management, and remembering the cookie choices you make here.
Always on
FunctionalRemembers choices you make, such as language, region or display preferences, so the site opens the way you left it.
Performance and analyticsPerformance and analytics cookies show us how the Website is used: which pages are visited, how long is spent on them, where visitors came from, and what errors occur. They are set by Google Analytics and by HubSpot, whose cookies also link the pages you viewed to any enquiry you later send us.
Marketing and targetingTracks browsing activity to measure advertising and show relevant ads. We set none of these today, and will not without your opt-in.