Understand
We start with how the work actually runs: who touches what, where it breaks, which systems already hold your data. You get that back in writing, in your words, before anyone proposes anything.
SCOPE · BUILD · REVIEW · HANDOVER
Know what you are buying. See the work as it takes shape.
We agree the deliverables, price and responsibilities before building. You review working stages, understand the decisions and know what happens at handover. Start with one useful piece of work and decide what should follow from there.
01 · The method
The same four stages, whether the job is one screen or one platform
Prioritise
Everything we find gets ranked by what it costs you now and what it would take to fix. You choose the order. Some items get deliberately parked, and we write down why.
Deliver
Work lands in stages you can look at, not one reveal at the end. Each stage has a named owner, a demonstration you can click through and a route back if the change turns out to be wrong.
Improve
After release we watch what people actually do with it, fix what gets in their way and tell you which of the remaining ideas are worth building and which are not.
02 · How a project starts
It starts with a conversation, not a proposal document
The first conversation is not a pitch. We ask what is not working, what you have already tried and what would count as this being fixed. One call is usually enough for both sides to tell whether we are the right people for the job. If we are, we write back with what we understood, what we would do first and what we would leave alone.
Scope is agreed in writing before anything is built, and it is deliberately narrow at the start. If the honest answer turns out to be smaller than you expected, a setting changed or one form rebuilt or a tool you already pay for switched on properly, we will say so and quote for that. Fixed price for defined work, a retained arrangement for continuous work. We tell you which shape fits rather than waiting to be asked.
03 · How delivery stays visible
You should not have to ask how it is going
Not knowing where a project has got to is what makes it feel like it is going wrong. We deal with that by making progress something you can look at rather than something we describe in an email. If a date slips you hear it from us first, with the reason and the revised plan attached.
- 01Working demonstrations rather than status percentages: you click through the real thing at each stage
- 02A named person accountable for the work, reachable directly, not a rotating support queue
- 03Decisions written down as they are made, including the options we rejected and why
- 04Releases go out in controlled steps, at times agreed with you, never unannounced on a Friday
- 05A tested way back is prepared before a release goes out, so a bad change can be rolled back rather than repaired live
- 06Documentation, credentials and access handed over as standard: the work belongs to you
04 · Ways to engage
Three shapes of work, and the ones each is wrong for
One focused fix
One defined problem, one price, a clear finish. Suits an organisation that already knows what is wrong. It is the wrong shape if the real problem is still vague, and we would rather scope it properly first.
Multi-stage delivery
A larger build broken into stages you approve one at a time, each usable on its own. Suits rebuilds and migrations. It asks for your time at every gate, so it needs someone internally who can decide.
Ongoing partner
A standing arrangement where we hold your platforms, keep them current and take on new work as it arrives. Suits organisations with no internal technical staff. Not worth paying for if you have a single job in mind.
05 · What we will tell you plainly
The advice that costs us the work
There is work we will tell you not to build. If an off-the-shelf tool already does the job, we will name the tool and charge nothing for saying so. If the process underneath is the problem, software laid over the top only makes it faster to do the wrong thing. If the volume is not there yet, we will say wait and come back when it is.
We build and run software of our own, including answered phones powered by something we built in-house. The trade-offs we describe here are ones we have had to make on our own systems and pay for ourselves, which is why we are blunt about the work that is not worth buying.
NamedOne accountable owner per project, not a queue
WrittenScope, decisions and changes recorded as we go
ReversibleA tested way back prepared before release
YoursCode, access and documentation handed over
06 · How the work starts
Before you start. Practical questions, answered.
What to consider when deciding whether this work is right for your business.
What actually happens on a first call, and do we need to prepare anything?
No. The call is us asking you to walk one process end to end out loud, from the enquiry arriving to the invoice going out, naming every system and spreadsheet it touches. The useful detail is almost always in the gaps where somebody re-types something. We write it up and send the notes back to you afterwards. Start that conversation
Who will we actually be dealing with once the work is under way?
Usually the same people from the first call through to handover. There is no account manager sitting between you and whoever is writing the code, which means the person who heard you describe the process is the person building against it. Questions go to that person directly, and answers do not arrive translated.
What happens if you decide we do not actually need what we asked for?
Often we say so and the conversation ends there. If the thing you described is a setting in software you already pay for, or a habit rather than a system problem, you should not pay us for that. We would rather write the short note explaining where the setting lives than sell a build that solves nothing. What we actually build
What do you need from our side while the work is going on?
Usually one person who can answer questions and make a decision without convening a meeting, plus access to the systems being changed. The access matters more than people expect: read-only credentials to a live system, or a sandbox with real-shaped data in it, are what stop us guessing at edge cases and building something that only works on tidy records.
Something breaks after launch. Who fixes it, and does that cost extra?
Usually we do, and whether it is chargeable depends on what broke. If it is our code or our configuration, it gets fixed and there is no invoice. If a third party changed an API, retired an endpoint or altered a data format, that is new work and we say so before starting it. Faults get logged either way.
Do we own the code, the domain and the accounts at the end?
Yes. Domains and third-party accounts are registered in your name from the start rather than transferred later, and the source code sits in a repository you have access to throughout. Leaving means changing a password, not negotiating a release. Anything we host is documented well enough for another developer to pick it up without ringing us.
07 · Where to go next
If this sounds like how you want to work
SIX CAPABILITIES
Whatever the problem needs
From a website or first automation to a controlled migration and custom platform.
EXPLORE → WEBSITES AND SYSTEMS FOR UK BUSINESSESDifferent businesses
A contractor needs job details on site. A practice needs the right information on the right file.
EXPLORE → ABOUT LIGHTNINGBuilt to make progress
A UK software company that turns business problems into working digital solutions.
EXPLORE →You are not buying a promise about results. You are buying a way of working that lets you see what you are getting while you are getting it, and stop us at any point if it is not right.
NEXT · Tell us what you want to improve
Start with the change you want to make.
Tell us what you use now, where the work slows down and what a better result would look like. We will explain the next step, with any paid work agreed before it starts.