A web application is easy to start and hard to keep.
Getting a first version onto a screen has never been quicker. The difficulty arrives later: the release that has to serve ten times the users, the security review that lands the week you are busiest, the small change that turns out to touch forty things because nobody drew the seams in the right place. Most of what a web application costs is spent after it launches.
None of that is bad luck. It is the cost of decisions taken early, and we would rather spend an afternoon getting the architecture right now than a fortnight unpicking it in year three.
When the app is your business
In SaaS platform development the application is the thing customers pay for. It has to scale when the sign-ups arrive and stay stable enough that shipping a feature on Tuesday does not break someone's Wednesday. If you are building a product to sell, the multi-tenancy, billing and scale specifics live on our SaaS application development page.
When the app runs your business
In business operations software the application is the system your team lives in all day. When it is down, they are idle, and when the business changes, the software has to change with it. It earns its keep by removing the spreadsheets and the copying between systems that used to hold everything together.
01Architecture that fits the problem
Serverless, containers, event-driven or a mix, chosen to match your workload rather than a house style. When Rubber Ring's platform needed a rebuild, that meant an event-sourced design with a DynamoDB source of truth streamed into a PostgreSQL read model. Yours might need none of that, and we will say so.
02A modern, accessible front end
React and TypeScript, built to WCAG standards and quick on the devices people actually hold. The interface is where your users decide whether the software is any good, so it is treated as part of the product rather than a coat of paint.
03Secure by default
Authentication and authorisation on every request, least-privilege access, validation of anything a user sends, and encryption in transit and at rest. Security is part of the design from the first diagram, not a hardening pass bolted on before launch.
04Built to scale, priced to match
Serverless components on AWS Lambda scale with demand and cost nothing while idle. Steady workloads run on containers. CloudFront caches what can be cached. We measure before we optimise, and we tell you when a change would buy speed you do not need.
05Infrastructure as code, in your account
The whole platform is defined with the AWS CDK and runs in your own AWS account. Environments are reproducible, the deploy pipeline is boring by design, and you get a copy of all of it. You can take it elsewhere whenever you like.
The web applications these businesses run on.
A recent build shows the current shape of the work: Rubber Ring's live insurance platform, rebuilt on an event-sourced architecture with a DynamoDB source of truth streamed into a PostgreSQL read model, React on the front, all defined in code with the AWS CDK, and the entire book migrated in a single cutover. We are an AWS Select Tier Services Partner and run a Well-Architected review on every engagement, which is a large part of why the running cost does not surprise anyone in month four.
Jaguar Land Rover
A business-critical global web platform, used by retailers, auditors and JLR teams worldwide, that we have built and run for over a decade.
Insurance platform rebuild
Rubber Ring, rebuilt
A live insurance business re-platformed on an event-sourced AWS architecture, with the whole book cut over in one move.
Duwio
A cloud-native SaaS platform for managing high-resolution image libraries, built from an earlier product and run by us.
The relationship between us is genuinely a partnership rather than a supplier/customer scenario. They have suggested changes which we would probably never have considered but which have added value.
We build for the version of your business that does not exist yet.
- 01
Shape
We sit down with the people who will use the thing and map what it has to do, using event storming and story mapping. The architecture follows from the work the application has to support, not from whatever framework is fashionable this year.
- 02
Build
React and Node.js on a cloud-native AWS foundation. Serverless where the load comes in bursts and containers where it is steady, with an event-driven design where different parts of the business genuinely happen at different times. The whole environment is defined in code with the AWS CDK, so a second copy is a command rather than a week.
- 03
Run
We stay. Someone has to watch the error rates, keep the dependencies current, and answer the phone when something behaves oddly at four on a Friday. In most of our engagements that is still us years after launch, which is why we build things we are willing to look after.
The things buyers ask us first.
Will we be locked in?
No. Everything we build runs in your own AWS account, and you get a copy of all of it, including the infrastructure definitions and the deployment pipeline. You can take it elsewhere whenever you want. An engagement that only survives because leaving is painful is not one we want.
Can you work with the application we already have?
Usually, yes. We will read it, tell you honestly what state it is in, and give you the options. Sometimes that is a careful evolution. Sometimes, as with Rubber Ring, it is a rebuild with the live business migrated across in one cutover.
Does it have to be React, or a full rewrite?
No. React is our default for a new front end because it is well supported and we know it deeply, but we work with the stack you have where that is the sensible thing to do. The right answer depends on where you are, not on what we would enjoy building.
Who will actually build it?
The two founders, and the trusted collaborators we bring in around them. No account manager between you and the people writing the code, and no junior learning on your project.