Websites
Marketing sites, landing pages, content-managed websites, accessibility work and redesigns. Built to be edited by the people who run them, not by a developer on a retainer.
Web application and website development
The work we take on, and what each piece actually involves.
Six kinds of work, and one way of running all of them: a systems analyst turns the requirement into something that can be priced, and the people who build it are chosen on the skills that requirement needs.
Project types
Six kinds of work.
Most projects are one of these, or two of them together. If yours is not on the list, describe it anyway and we will tell you honestly whether we are the right people.
Web applications
Custom portals, dashboards, admin systems, booking tools, internal platforms and workflow apps. Bespoke systems that do a specific job for a specific business.
APIs and integrations
Making two systems that were never meant to speak to each other do exactly that, reliably. Data connections, third party integrations, automation and API design.
Data and databases
Data modelling, migrations, reporting, dashboards and database-backed applications. The unglamorous work that decides whether everything above it holds up.
Cloud and deployment
Hosting, deployment planning, backups that restore, monitoring that means something, and failover that has actually been tested.
Accessibility and SEO
WCAG 2.2 audits and remediation, and the technical SEO that is structural rather than a monthly retainer. Built in from the start rather than bolted on when somebody complains.
How a piece of work is priced
Every project is broken into pieces, and each piece is given a number of hours by the systems analyst who scoped it. That figure is what the developer is paid for that piece, and it is agreed before they accept it.
If a piece takes longer than we judged it would, that is absorbed on our side. Our estimating being wrong is not something a client should pay for, and it is not something a developer should have to argue about afterwards.
What changes the price
Integration with systems that already exist is usually the biggest factor, and it is the one most often left out of a quote. An endpoint nobody has documented, a data format that only makes sense to the person who left, an authentication scheme from 2012. We look at that before quoting rather than discovering it in week three.
What does not change the price
Anything inside the agreed scope. That is the entire point of writing it down.
Every project, the same way
From requirement to handover.
Whichever of the six it is, the route through is identical.
-
Discovery
A conversation with a systems analyst about the problem, not the solution. No charge and no obligation.
-
Scope and price
The requirement becomes a written brief: goals, features, explicit exclusions, assumptions and a figure. Yours to keep either way.
-
The right people
The brief goes to members whose skills match it, with the hours and the rate stated. They accept or decline.
-
Build and check
Work is delivered in pieces, each checked against the acceptance criteria before you see it. Anything not right goes back.
-
Handover
Deployment, documentation and a walkthrough. The source code becomes yours on final payment.
Also available
Support for teams who already have developers.
Sometimes the gap is not people, it is process.
Scoping and technical documentation
We write the brief and the specification, and your own team builds it. Useful when the developers are good and the requirements are not.
Quality assurance and testing
Test plans, cross-browser and device testing, accessibility checks and end-to-end flow testing ahead of a launch.
Technical audits
An honest read on an existing codebase, its infrastructure, its accessibility and its search visibility, with a prioritised list of fixes.
What it costs to find out
Nothing, and here is the proof.
- For the discovery conversation
- £0
- For the written brief and scope
- £0
- If you decide not to go ahead
- £0
- Typical first reply to an enquiry
- 48h
Questions about the work itself
Do you work with existing systems or only build new ones?
Both, and integrating with what you have is often the cheaper answer. Replacing a system that works is rarely the right first move. We would rather wrap it, talk to it, and leave it where it is.
What technologies do you build in?
Mostly PHP and JavaScript on the server, with the front end built to standards rather than to a framework fashion. What matters more is that whoever maintains it after us can read it, so we do not reach for something exotic to make a simple job interesting.
Can you take over a project somebody else started?
Often, but we will want to look at it first and we will tell you honestly what we find. Sometimes the right advice is that finishing it costs more than restarting, and you are better off hearing that before you commit.
Do you do accessibility work on its own?
Yes. A WCAG 2.2 audit with a prioritised list of issues, and the remediation if you want us to do it. It is also built into everything else we make, rather than being an upsell.
What about hosting and ongoing support?
We can set up hosting, deployment, backups and monitoring as part of a project. Ongoing support is quoted separately so you are never paying a retainer for months when nothing needed doing.
How long does a typical project take?
A small website is weeks. A bespoke system that integrates with something else is months. We will not give you a number before we understand the work, because a number given that early is a guess with a decimal point on it.
Start a project
Have a software or website requirement?
Book a discovery conversation with a Rainbow Coders systems analyst. We will help shape the requirement into a clear project brief, find and engage with the very best developers, and deliver fully tested results.