blue pebble

I build features and fix the debt that slows your team down.

I'm Ellis Johnston.

For over a decade, I've been a remote engineer embedded with engineering teams, delivering the features on their roadmap. As a senior engineer, when something in the codebase gets in the way I fix the root cause, not just the symptom, so your team keeps moving.

A 'flaky 2FA' ticket became a stable login, 600 fewer lines, and a working single sign-on.

Email me Remote, UK

The Problem

You can feel it before you can name it.

When a codebase degrades, every new feature feels like wading through mud. These six symptoms are the friction I look for, so you can keep delivering today without borrowing against tomorrow:

01 Small changes take days. A one-line feature touches five files and a deploy everyone dreads.
02 Nobody owns the risky parts. There's a file people route around rather than open.
03 Every fix spawns two bugs. Confidence in releases is quietly gone.
04 Estimates keep growing. The same kind of work costs more than it did a year ago.
05 Onboarding takes months. The system only really lives in one or two people's heads.
06 "We'll rewrite it" keeps coming up. And keeps not happening.

For Your Business

What slow delivery actually costs.

You don't see the codebase; you see its effects. Features that took a week now take a month. New hires take a quarter to get useful. The team spends more time keeping the lights on than building what customers asked for.

None of this shows up as a single bill. It's a compounding tax on every decision you make. Making software easy to change again isn't tidying for its own sake. It's buying back speed, lowering the cost of every future feature, and cutting how much you depend on any one person.

A worked example

Build features, fix root causes.

When a bug keeps coming back, it's usually a symptom. The ticket says what broke, but the real cause is a decision made months earlier that the code has been fighting ever since.

I trace the symptom back to that decision and fix it there, so the whole class of bug stops, not just this instance.

Worked example · two-factor login

SYMPTOM

Two-factor login rejected valid codes, intermittently.

TICKET

"Fix flaky 2FA."

TRACE

Sessions were hand-rolled, racing the framework's own auth lifecycle.

ROOT

Authentication had been re-implemented by hand instead of using the framework.

FIX

Removed the custom layer. 2FA went stable, and ~600 lines of fragile code went with it.

DELIVERED

With auth back on the framework, the single sign-on it had broken started working again that same month.

The ticket said "2FA is flaky." The result: a stable login, 600 fewer lines, and a working single sign-on.

How I Use AI

A tool for thinking. Judgment stays human.

I use AI deliberately: to explore options faster, to draft, to pressure-test my own reasoning. It types fast. Whether what it wrote is worth keeping is still my call.

I don't merge code I don't understand, and I don't let a model make decisions that need a human who'll be accountable for them in six months. Used well, it raises the quality of the thinking. Used lazily, it just generates more code that looks correct.

Engagements

How we'd work together.

Format: Hands-on. I work inside your codebase, with your team, not a slide deck of recommendations.
Duration: Multi-month. Real change to a system isn't a two-week sprint.
Location: Remote, UK hours.
Rate: Day rate. Details on enquiry.

Fixed fee · £1,200

Not ready for a full engagement? Start with a Codebase & Velocity Audit.

A 3-day deep dive into your trickiest repository. I'll map your structural bottlenecks, identify why feature delivery has stalled, and give your team a concrete execution plan.

No obligation. You keep the execution plan whether or not we work together, and I reply within one business day.

Ask about an audit

If this sounds like your codebase, email me.

Tell me what's slowing you down: a flaky system, a release you dread, a roadmap that keeps slipping. I read every message myself.

Email me

ellisj1998@gmail.com