Skip to content

Services / Software development

Software that already exists, and needs to keep working

Most development money is not spent on new products. It is spent on things already running, that need a feature, or a fix, or a rescue. That work is harder to quote and less appealing to sell, which is why it is worth being good at.

Book a discovery call

Discovery, fixed fee · Features · Takeovers · Maintenance

What this covers

Which of these is yours?

Sorted by the situation you are in rather than by engineering discipline. The first step is the same for all five: we read before we quote.

  • SD-01

    New features on a running product

    Customers use it, it works, and you need it to do more without breaking what it already does.

  • SD-02

    Taking over someone else's project

    An agency that finished and vanished, a contractor who moved on, or an engineer who left with the context in their head.

  • SD-03

    Fixing what has become fragile

    Deploys frighten people, the same bug returns monthly, and nobody wants to touch one particular file.

  • SD-04

    Keeping it running

    Dependencies age, platforms deprecate, certificates expire. Unglamorous, and the reason products quietly stop working.

  • SD-05

    Backend and API work

    Data models, integrations, queues and the other parts with no interface, which take the blame when the app is slow.

Taking over from whoever built it

If a rewrite would cost you less than the repair, we will say so. Even though the repair is easier for us to sell.
Said early, in writing, on every takeover

How the work runs

Three steps. The first one is the product.

Everything else on this site follows from these three steps.

  1. 01

    Discovery that ends in a written plan

    A short piece of paid work. We sit with the problem and you get back a document that says what is being made, how it fits together, what order it gets built in, and what it costs. The plan is yours unconditionally. Take it to us, take it to another firm, or decide not to build at all.

  2. 02

    A named team, and one person you can reach

    The people who understood the problem build the thing. You get names rather than a rotating cast, and one lead who answers to you directly. If someone is not working out, we raise it first and manage the replacement ourselves.

  3. 03

    Progress you can check, changes you can price

    Work arrives in increments you can see and use, not in a reveal at the end. When scope moves, and it will, the change is costed in writing before anybody starts it.

Where discovery differs here

For an inherited codebase, discovery is less designing and more reading. The plan opens with what you actually have: what shape it is in, what will cause trouble, and what continuing versus rewriting would each cost, before it prices the work you originally asked about.

Ownership

What you own

From the first commit, everything belongs to you. Not at handover. From the beginning.

  • Code and repositories

    All of it, in accounts you control. There is no private framework underneath and no dependency on continued payment to keep the thing running.

  • Infrastructure and keys

    Cloud accounts, domains, credentials and certificates are created in your name. We hold nothing that you cannot revoke yourself.

  • Documentation

    Decisions, diagrams and runbooks are written while the work happens, so the knowledge leaves with the documents rather than with the people.

  • The freedom to leave

    If you stopped paying us tomorrow, the product would keep running without us. That is the test we design against.

Questions

What people ask first

Our last developer left no documentation. Is that a problem?

It is the normal condition of inherited software, so no. It costs time at the beginning, which is what the reading step absorbs. You get a written description of your own system out of it, and that document is yours whatever you decide about the work.

Do we need a rewrite?

Probably not, though occasionally yes. Rewrites appeal because working in the old code is miserable, and miserable is not the same as beyond repair. Targeted repairs around the part that hurts usually cost a fraction and land sooner. When the arithmetic genuinely favours starting over, we will put that in writing with the numbers beside it.

How do you take over from another team?

Reading first, changing second. Repositories, deployment history, incident notes, what the tests actually cover. Before quoting the work you asked for, you receive an assessment of what is there: what is sound, what is load bearing, and what can be left alone indefinitely. Only then does anyone touch anything.

The system is old. Is that a security problem?

Age alone is not the risk; exposure is. A framework three versions back behind a login is a different problem from the same framework facing the public internet. The first assessment lists what is exposed, what is out of support, and what to upgrade first, ordered by how much risk each step removes rather than by how bad it looks on a scanner report.

Next step

Tell us what you are trying to build

Name the system, what it does today, and what is going wrong.

Tell us about the system

A few lines about the situation is plenty. We read every one.

No newsletter, no drip sequence. A reply from a person who read this.