About

Working With Existing Software

1. Understand What Is Currently Happening

Before making changes on a legacy system it's best to understand how things are currently working on the software. All existing systems I work on begin with a short diagnostic stage. I'll download the code and run it on my computer and get an understanding of the core concepts before starting to make changes.

2. Understand What Is Needed

I work closely with clients to understand exactly what they're trying to achieve. That often involves translating vague or non-technical goals into something precise enough to build safely.

From there, I usually outline two or three viable options, explaining the pros and cons of each so clients can make informed decisions based on risk, cost, and long-term impact.

3. Safe, Predictable Changes

The implementation stage is deliberately cautious - changes are made in a way that respects the existing system and avoids unintended side effects.

I work iteratively - building and testing as we go, so you can see progress early and give feedback often. This keeps surprises to a minimum and ensures we stay on the right track.

4. Protect Uptime

Once changes are ready to go live, I handle all the details - deploying to your server, cloud provider, or app store. I make sure everything runs smoothly, prioritises uptime, and where appropriate performs well in tools like Google Lighthouse.

5. Support If You Need It

After launch, I can stay on to maintain and improve the project, or hand things over with clear documentation and support.

Starting From Scratch

Every project is different, but I aim to keep the process simple, collaborative, and transparent from start to finish.

1. Understand the Goal

We start with a conversation. I'll ask questions about your idea, your users, and what success looks like. If you're not technical, that's fine - my job is to translate your goals into software.

2. Choose the Right Tools

I don't push one stack for every job. I'll recommend technologies that fit your project's scope, timeline, and budget - whether that's a custom-built app, a static site, or something in between.

Advisory and Technical Guidance

Sometimes the most important work happens before any code is written.

I often work with clients who know something needs to change, but aren't sure what the right next step is. In these cases, I focus on understanding how the system currently behaves, what the real constraints are, and what risks are involved in different approaches.

That can involve reviewing an existing codebase, talking through proposed changes, or helping translate business goals into technically realistic options - without committing prematurely to delivery.

This kind of advisory work is particularly useful when:

• a system feels fragile or hard to change
• previous attempts to improve it haven't gone well
• you need a second opinion before investing more time or money

The aim is clarity and confidence - so any decision to change the software is made with a clear understanding of trade-offs, cost, and risk.