Product engineering · Walsall, West Midlands

We build clever useful software. Clever is optional. Useful is not.

Pickleworks designs and engineers mobile apps, web products and interfaces for organisations who would rather their software worked than impressed a conference. We trim the brief, build what matters, publish it properly and stick around afterwards.

The method, sans buzzwords

  1. Trim

    Most briefs arrive with three products hiding inside one. We find the one that matters first and write the rest on a "later" list you can keep.

  2. Test

    A clickable prototype goes in front of real people early. It is cheaper to be wrong in a prototype than in a release.

  3. Build

    Short, visible build cycles. Every cycle ends with something you can poke on your own device.

  4. Ship

    Store listings, privacy forms, domains and the other admin that stands between "done" and "available".

  5. Keep

    Fixes, updates and steady improvement so the product stays crisp rather than going soft on the shelf.

A minimal desk with a laptop, keyboard and a few accessories
Where the trimming happens.Illustrative stock photo. Not our team, office or client work.

Grown-up humour, serious engineering

We like a good line, but we save the jokes for the website. Inside your product, words are plain, buttons say what they do and nothing is cute at the expense of being clear.

Our work is mostly for small and medium-sized organisations, founders and teams inside larger businesses who need something specific built well, and who appreciate being told when an idea is half-baked.

More about us

On the shelf

The Scope sharpener

Sort typical feature requests into Now, Later or Never. Your first release is whatever survives in "Now". Brutal, but therapeutic.

  • User accounts and sign-in
  • Payments
  • Push notifications
  • Admin dashboard
  • Social sharing
  • Offline mode
  • Dark theme
  • In-app chat
  • Reporting and exports
  • Multiple languages

Nothing sorted yet. Go on, be ruthless.

Now
0
Later
0
Never
0
Glass jars of lime and pink pickles on a dark aubergine shelf beside a notebook
Illustrative generated still life. Not our office, not a client project, and not lunch.

What you ask for, and what we usually suggest

Requests arrive in a familiar shape. Our suggestions are not always smaller, but they are usually more specific. Here is how common asks tend to change after a first conversation.

“An app like Uber, but for…”
A booking flow for one type of customer in one area, with manual dispatch behind it until demand proves the automation is worth building.
“A new website”
A clear answer to the three questions your visitors actually arrive with, a contact form that reliably reaches you, and pages your team can edit.
“A dashboard for everything”
One screen answering the question your manager asks every Monday, with exports for the rest.
“Make it look modern”
Fix the three places users get stuck, then refresh type, spacing and colour so the product looks as considered as it now behaves.

Launch-date back-planner

Got a date in mind? Enter it and choose where the product is going. The planner works backwards to show when each stage would need to finish. It assumes a modest first version and ordinary working weeks; treat it as a sense-check, not a promise.

Where will it live?
  1. Choose a date to see the plan.

Red-pen snippets for your brief

Free to steal. These edits turn vague requirements into ones a designer can test and a developer can estimate.

BeforeIt should be user-friendly.

AfterA first-time visitor can book an appointment on a phone in under two minutes without help.

BeforeWe need a modern, clean design.

AfterText meets contrast guidelines, buttons say what they do, and nothing important hides behind a menu on mobile.

BeforeIt must be fast.

AfterMain pages load usefully within three seconds on an ordinary 4G connection.

BeforeUsers can manage their account.

AfterUsers can change their email, reset their password and delete their account without contacting us.

BeforeIntegrate with our systems.

AfterNew orders appear in the existing spreadsheet within five minutes, with these named columns.

When something goes wrong after launch

Software meets new phones, new browsers and new kinds of user every month. Our support plans cover fault fixing, platform and dependency updates, health checks on certificates and backups, and a small allowance for improvements. Arrangements are agreed per product.

When you report a problem, these four details save most of the investigation time:

  1. What you were trying to do.
  2. What happened instead, in your own words.
  3. The device, browser or app version.
  4. Roughly when it happened.

Please never send passwords or customers’ personal data. Requests are read Monday to Friday, 09:00–18:00 UK time.

Support and request form

Questions, answered without spin

Will you tell us if the idea is not ready?

Yes, politely and with reasons. We would rather lose a project than build something that is likely to disappoint you.

Do you build native or cross-platform apps?

Usually cross-platform, so one codebase serves iOS and Android. If the app relies on demanding hardware features, we recommend native work and explain the trade-off.

Can you publish an app someone else built?

Yes. We review its readiness, prepare listings and privacy declarations, submit it and deal with review feedback.

Who owns the result?

You do: code, designs, store accounts and domains are in your organisation’s name.

Do you work outside the West Midlands?

Yes. Our registered office is in Walsall and we work with clients across the UK through calls and shared preview builds.

What does a first conversation cost?

Nothing. It is a chance to understand the problem and for both sides to decide whether we are the right fit.

Bring us the brief. We will bring the red pen.

Start a conversation