Rework and support
The project already exists, but something broke, crawls or stopped. We take on somebody else's code as it stands and bring it back to working order.
From nothing, or from what is already there
01
The developer stopped replying
The project is still there, some of the access is not, and the documentation never existed.
02
It works, slowly
The page takes its time, and people leave before they see what is on it.
03
Every fix breaks something next to it
Fixed here, fell over there, and nobody will say why.
04
The stack has aged out
The libraries have not been updated in years. Updating is frightening, not updating is no longer an option.
From one bug to a new stack
01Fixing bugs
We find the cause first and fix second. Not the other way round.
02New features
Added to the code that is already there, without rewriting it all.
03Integrations and APIs
Payment, delivery, CRM, stock. So the data moves on its own.
04Moving to a new stack
Moved in pieces, with a working site at every step.
05Making it faster
We measure first, then fix what actually slows it down.
A stack any developer can take over
We choose it for the job and name it before we start. It decides what support will cost and how easy it is to find another developer later.
- What arrivesThe list is not closed. If your stack is a different one, we will still look
- WordPressWooCommerceShopifyPHPLaraveljQueryReactVueNode
- Where it moves toWhen repair works out dearer than moving
- ReactNext.jsAstroTypeScriptNodePostgreSQL
- What we measure withSo we fix what is slow, not what is visible
- LighthouseCore Web VitalsSearch ConsoleSentry
- What we connectPayment, delivery, stock, and anything that should move on its own
- LiqPayWayForPayStripePayPalDelivery servicesCRMStock systems
From the first call to working order
01
The call
You tell us what is broken and what has already been tried. The questions after that are ours to ask.
02
Review
We read the code, the access and the error logs, and tell you what is really going on.
03
Repair
In pieces, with a working project at every step.
04
Support
A monthly package of hours or separate tasks, whichever suits you.
What we do by default
These are not separate options or a line on the invoice. We work this way on every project, and you can look at it while the work is still running.
- 01Speed
- We measure before and after, so the change is visible.
- 02Checks
- After every fix we walk through whatever could have broken next to it.
- 03Accessibility
- We aim at WCAG 2.2 AA: readable contrast, keyboard operation, fields that say what they want.
- 04Phone
- Checked from 320px, both in the browser and on real devices.
- 05Search
- A move without losing rankings: addresses and redirects are kept.
- 06Handover
- The access we found is moved into your name and written down in one place.
You will not have to write a brief
01
Someone who decides
One person on your side who says yes and collects the edits. When they arrive from three people at once they contradict each other, and the work has to be redone.
02
Access
Code, hosting, database, admin panel. We start from whatever turns up.
03
What is wrong
What broke, when and after what. A screenshot or a video beats a long email.
04
The project's history
Who wrote it, what changed last, and where the documentation is, if there is any.
What people ask before the first email
How much does it cost?
It depends on what exists and what has to come out, so we work it out after a short call. A project or a stage that is clear up front gets a fixed price. Work with someone else's code, bug hunting and tasks with an undefined scope are paid hourly: nobody can price in advance what they have not seen yet.
Support and development go by a monthly package of hours. TODO(owner): exact rates and a minimum budget have not been decided.
How long does it take?
It depends on what we find in the code. After the review we name a date. If anything moves, you hear it straight away.
Will you take on code you did not write?
Yes, that is what this work is. We read the code first and tell you what is really going on in it. Sometimes rewriting costs less than repairing. Then we say so.
What if there is no documentation?
That happens often. We work it out from the code and write down what we learn, so the next developer has an easier time.
What do I end up with?
A working project, a list of what was done, and every access in your name.
Who will actually do the work?
The people who answer your email. You talk to them directly.
Send a link to the project and say what is not working. We will look and tell you what to do with it
- 01A link
to the site, the mock-up or the repository, whatever exists
- 02What to change
one sentence on what should become different
- 03Who it's for
who will use it: your customers, your team, and how many