Home / How a change reaches you
How a change reaches you
Three environments, a guided tour of every change before you accept it, and feedback given by drawing straight onto the screen. You push it live yourself.
The short version
You hold the button that puts anything live.
Three environments, a guided tour of every change before you accept it, and a way to give feedback by drawing straight onto the screen. Most software firms do not work like this. It is the part clients tell us they cannot go back from.
The pipeline
Three environments. One of them is yours.
Development is ours and changes constantly. Staging is yours and only changes when something genuinely works. Production changes when you decide it does.
Our playground
Where the work actually happens. It changes many times a day, it breaks and gets fixed, and you never see any of it. You are never asked to review something half-built.
Yours to review
A change only reaches here when we believe it genuinely works. It arrives with exactly what changed, how to test it, why we did it, and what the risk is.
Your users
The environment your people log into every day. Nothing arrives here except what you accepted and pushed yourself.
Reviewer column on approvals
What changed Each approval row now shows who reviewed it, and at which revision.
How to test Open Approvals and confirm the reviewer appears in the row itself.
Why An auditor could not trace a decision without opening every record.
01 · The tour
One button, and the change walks you through itself.
You do not go hunting for what moved. Press one button in your staging environment and a guided tour opens, stopping at each interface we touched and pointing directly at what changed.
- Every stop shows whether something was added, adjusted or removed — marked on the interface itself
- Each carries how to test it, why we did it, and an honest read on the risk
- It takes minutes, not an afternoon — and no meeting has to be arranged for it
When you are happy, you accept. Then you push it to production yourself.
02 · The overlay
Draw on the screen. That is the whole interface.
A button sits permanently over your staging environment. Press it and the page freezes exactly as it is — mid-popup, mid-scroll, whatever state you had caught it in. Then draw around anything you like, at any size. The system snaps to the element you meant and your comment binds to that exact thing.
No screenshots to take, no describing which button on which page, no "it looked different on my screen". What you saw is what we get.
03 · The loop closes itself
Your note comes back as the fix, not as a status update.
Your marked element lands in our development environment carrying the frozen page and your words, so we are looking at precisely what you were looking at. When it is solved, the push to staging is attached to your feedback item with the explanation of what changed and how to check it — which closes the item.
Nobody writes "we've addressed your feedback". The change itself is the reply, and it is waiting in your next tour.
Before any of it
How work gets into the loop in the first place.
The pipeline is the visible half. This is the half that decides what enters it — and it is where a technical partner earns their keep.
You raise it however suits you
In the weekly session, by message, or by drawing on the staging environment. There is no form to fill in and no template to learn.
We push back before we build
Most requests change shape once we understand the underlying problem. Some turn out to be a configuration change. Some should not be built at all, and we say so.
You decide the order
We bring the trade-offs — effort, risk, what it blocks — and you set priority. We do not silently reorder your roadmap to suit our week.
Inside development
What has to be true before anything reaches you.
Staging is your environment, so putting half-finished work in it wastes your time rather than ours. These gates run on every single change, without exception, and a failure keeps it in development.
- Types and tests. The change compiles and the suite passes — including a test written for this change specifically.
- Migrations rehearsed. Every schema change is run against a copy of real production shape before it is allowed near your data.
- Isolation proven. Policies are re-checked so one tenant still cannot read another's data — the check that matters most and is easiest to break.
- Rollback rehearsed. If it cannot be reversed cleanly, it does not go — and you are told before it is offered to you.
Where it intersects your work
What this asks of you, honestly.
The loop only pays off if the person who can actually decide is the person walking it. That is the one thing we need.
When it goes wrong
Because sometimes it does.
Something breaks in production
We roll back first and explain afterwards — the rehearsed rollback is why that is a minutes decision rather than an argument. Then the fix enters the loop like anything else.
You reject a change
Send the step back with a note. It returns to development carrying your words, and reappears as its own stop in a later tour. Nothing is lost and nothing is argued about.
We disagree with you
We say so, once, with reasoning — and then we build what you decided. It is your system and your business. Being right about architecture is not worth being difficult about.
Why this is unusual
Most firms ask you to imagine it. We hand you the button.
You are never guessing
Every change is shown to you in place, with the reasoning attached. You are not reading a changelog and hoping.
You are never blocked
The tour is asynchronous. Walk it at eleven at night if that suits you — nothing waits on a shared calendar slot.
You are never surprised
Production only ever contains what you pushed. There is no other route in, and no Friday-afternoon exception.
Feedback costs you seconds
Draw, type, send. The alternative is a screenshot, a paragraph explaining where it was, and a reply asking which browser.
We see what you saw
The frozen page comes with it. No reproducing, no "works on my machine", no lost half-day.
The record writes itself
Every change, every acceptance and every push carries who did it and when — because the process produced it, not a person.
This is the part we would demonstrate first. The interfaces on this page are rebuilt in code rather than screenshotted, and the projects shown are generic. Ask and we will walk you through a real change on a real staging environment, end to end, in about ten minutes.
Tell us what your business runs on.
If it is the kind of system that cannot have a bad day, we should talk. One conversation, no deck, with the people who would build it.