Skip to content
How we work

The problems we get called in for, and how we work on them.

The shape of the work: the situations that bring people here, the questions we ask before quoting anything, and what is actually in your hands when we leave.

Situations

Three situations, described as categories of work

Patterns we have met more than once, described as categories of work: without the names, logos or figures that would identify an organisation.

01 Career sites

Job listings that disagree with the ATS

The situation. A few hundred open roles live in an ATS. The careers website is a separate CMS, updated by hand. Roles go live late, closed roles keep taking applications, and the same vacancy exists twice with different salary bands. Recruiters have started sending candidates the ATS link directly, which loses the employer brand and every analytics event with it.

The approach. Treat the ATS as the source of truth and stop writing job data anywhere else. Pull roles through the documented API on a schedule, validate each record at the boundary so a malformed or half-published role fails loudly instead of appearing wrong, and keep the site's own layer for the things the ATS has no field for: office pages, benefits, hiring-process copy.

What changes. Publishing a role becomes an ATS action, not a website ticket. Application tracking stays intact because candidates never leave the domain.

One source of truth
Roles live without a release
02 Integrations

The integration is a person and a spreadsheet

The situation. Two systems that were never meant to talk — say an ERP and a CRM — are reconciled every week by someone exporting CSVs and pasting them into a sheet with rules only they understand. It works until that person is on holiday. Nobody can say which system is right when the two disagree.

The approach. Map what actually moves today, including the manual steps and the undocumented exceptions, and confirm that reading with the person doing the job before writing any code. Then a middleware layer with the boring properties: an explicit field-level contract, idempotent writes so a retry cannot duplicate a record, a dead-letter queue for what fails, and logs an operations person can read without us.

What changes. The reconciliation stops being tribal knowledge. When a vendor changes their API, it breaks in a known place with an alert, not silently in next quarter's reporting.

Failures become visible
The process no longer depends on one person
03 CMS & e-commerce

A platform the catalogue has outgrown

The situation. A CMS and shop stack chosen when the catalogue was a tenth of its current size. Category pages are slow, every content change needs a developer and a release window, and the plugin that handles pricing has not been updated in years. A full rewrite has been proposed twice and cancelled twice, because nobody can afford the URLs and the checkout going dark for a weekend.

The approach. No big-bang cutover. Inventory what exists first — URLs, redirects, structured data, integrations nobody remembers — then move it in slices behind the same domain, keeping the old and new stack serving side by side until the last slice is verified. Redirect maps and search-visibility checks are part of the build, not a post-launch surprise.

What changes. Editors publish without a deploy. The migration becomes a sequence of reversible steps instead of one weekend everybody dreads.

Editors publish without a deploy
Reversible cutover
04 Something else

If your situation is not one of the three

Tell us what the system is and what is blocked, and you will get an honest answer — including “this is not us, talk to someone who does this every day” when that is the correct answer.

Discovery

The questions we ask in the first hour

These are the questions we ask in the first hour. They are the fastest way to judge whether we know this kind of system — and answering two or three of them in your message will save us both a round trip.

Systems & data

What is really there

  • Which system is the source of truth today, and who decided that?
  • When two systems disagree, which one does the business believe?
  • What edition or version are you licensed for, and what does that exclude?
  • Is there a sandbox or test tenant, or is production the only environment?
Process & people

Who does the work now

  • Walk us through the manual step. Who does it, how often, what breaks it?
  • Which exceptions live only in someone's head?
  • Who has to approve access to the systems, and how long does that usually take?
  • Who will own this after we leave, and are they in the room?
Constraints & risk

What must not break

  • What is the worst thing this project could do to you if it goes wrong?
  • Which URLs, integrations or reports must keep working unchanged?
  • Where does personal data enter, and where is it allowed to be stored?
  • Is there a fixed date driving this, and what happens if it slips?
Definition of done

How we will know it worked

  • What will someone stop doing on the Monday after go-live?
  • Who checks that, and against which number they already trust?
  • What has been tried before, and why did it not stick?
  • If we only shipped one thing, which one would be worth it on its own?

Handover

What is in your hands at the end

This part needs no case study: it is a list of artefacts you can ask any supplier for, and check off. Everything below is yours, in your accounts, whether or not we keep working together.

The repository
Full history in an account you own, not a zip file at the end. Branch and review conventions documented in the repo itself.
Environment and deployment definitions
How the thing is built, configured and released, written down and runnable. Credentials issued by your administrators and revocable by them, never held only by us.
A runbook, not a slide deck
What to do when a sync fails, where the logs are, which alert means what, and which failures are safe to retry. Written for the person on call, not for a procurement file.
The integration contract
Field-by-field mapping, the validation rules, and the documented behaviour on missing or malformed data — so the next engineer does not have to reverse-engineer intent.
A walkthrough with your team
A live session with whoever inherits the system, recorded if you want it, plus the open questions and known limitations stated honestly rather than buried.

Straight answers

About this page

Why no client names, logos or numbers on this page?

Because we have not been cleared to publish them. The client decides whether an engagement is public, and we do not publish figures without the baseline, the measurement window and who calculated them. The situations on this page are composites: recurring patterns written up as categories of work, with anything identifying removed. It is the same standard we apply with our clients: we describe the work only where doing so does not compromise them. On a call we can walk through the technical decisions of past work in detail, including what went wrong, without naming who it was for.

What can you show me before we sign anything?

The reasoning. Send us your situation and you get back our reading of it: where we think the risk sits, what we would need access to, which parts look harder than they sound, and what the first deliverable would be. That document is the sample of our work. If it is wrong, you have lost an email.

Get in touch

Tell us what you need to connect, rebuild, or automate.

One reply from an engineer, not a form autoresponder. If it isn't a fit, we'll say so on the first call.

Locations
Italy · Czechia · Japan

A person reads it, not an autoresponder. We use your details to reply to this request; see the privacy notice.