Development
Product support
The product does not stop at launch: dependency updates, errors traced from logs, changes by request, and someone on duty when things break.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 3–5 days
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Week one
Taking the product on
We take the product over: it gets stood up locally from your instructions — which is precisely where the gaps in those instructions surface. Then a map: where the code lives, where it deploys, which services are paid for and in whose name. The first small changes reach production the same week, and they double as proof that deploy and rollback work.
You get — A map of code and services, deploy proven
Week two
Rules and the backlog
We agree the rules: how a request reaches us, what counts as urgent, which hours are covered. The backlog is split three ways — fix, rebuild, leave alone — and the third pile is usually the biggest; owning up to it costs less than repairing everything in sight.
You get — Agreed rules and a sorted backlog
From week three
The queue and releases
The work runs as a queue: urgent items jump it, the rest is gathered into a release every week or two, so changes travel together and get checked together. Dependency updates go in small steps — twenty of them at once breaks the product in a way that makes the cause impossible to find afterwards.
You get — A request queue and changes shipped together
Every release
The same release route
Every release takes the same route: staging, a short check of what was touched, deploy inside the agreed window, rollback ready. If there was no monitoring and no log collection, it goes in at this point — otherwise the first to report a failure is a user rather than a system.
You get — A repeatable release with rollback and monitoring
Once a month
The monthly review
A short review: where the hours went, which requests keep coming back, what is cheaper to fix at the root than to patch every time. It is also where you see the moment support has stopped being enough and development needs to become its own piece of work.
You get — Hours accounted for and the requests that repeat
What the work covers
Taking the product on
the project running on our machine from your instructions, a map of code, environments and paid services, and the gaps it exposes.
Errors traced from logs
picking out what repeats, reproducing it on staging, finding the cause, checking that it stopped coming back.
Changes by request
a column in a report, a filter on a list, a new role permission, a notification email, estimated first and shipped in a release.
Dependency updates
in small steps with a check after each, closing vulnerabilities already published, moving language and database versions.
Answering the urgent
the call taken inside the agreed hours, the product brought back up, the cause looked at afterwards.
Hours accounted for
what was done in the month and what it took, which requests keep returning, what each return costs you.
What we need from you
- The repository with its history, and access to the server, the logs and the hosting panel.
- The keys, environment variables and test data without which the project will not start on our machine.
- The hours you need us reachable, and the person on your side who decides what counts as urgent.
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.