My Approach

With a diverse and unusual career — seeing how small businesses, large agencies, government, and my own business all actually operate — I've settled on a process that works. It runs in eight stages: discuss, design, suggest, build, deploy, support, improve, adapt. And then it loops right back to the start — as systems like this must evolve as your business does.

1. Discuss

Every project starts with a conversation, in person where possible. Understanding your business, your goals, and the problem you're actually trying to solve comes before any talk of a solution. The depth of the problem often can't be seen fully at first — that's fine, it gets refined as we go — but by the end of this stage we agree on what we're solving.

2. Design

Once the problem is defined, I break it down into manageable parts. What are the real constraints? What's the budget that still makes this profitable for you? What's the deadline? What's essential now, and what can safely wait?

From there comes a plan: what has to happen and when, what can be deferred, and what (if anything) needs to be cut to hit a deadline. And it gets documented — clearly enough that a brand new person could read it and understand exactly what the system does and why. Documentation isn't fixed in time either; it evolves as the system does, with changes tracked so everyone stays on the same page.

3. Suggest

With the plan in hand, I present the recommended solution, or a short list of real options with tradeoffs, so you can make an informed decision — not a sales pitch, a genuine recommendation based on what fits your business and budget.

4. Build

This is where it actually gets built. I'm particular about implementation:

• The plan should be followed, but flexibility matters when reality differs from theory — you often won't know until you're actually building it. Good documentation lets those changes get captured and agreed as they happen.
• I have to be able to walk away knowing the system does exactly what I say it does. That means:
  • Automated tests confirming the logic works — invaluable as the system evolves, so new features don't quietly break old ones.
  • Manual testing checklists — a list of things that must work, walked through line by line, which doubles as a "how to use this" guide.
  • User acceptance testing — real users trying it out to confirm it actually meets their needs in practice.

Systems are built and tested in an isolated development environment first — somewhere you can go wild without risking anything real. The best development environments mirror production in excruciating detail: real databases and real third-party services rather than mocked-up versions, and load testing that answers "what happens at 100,000 orders? A million? A billion?" before it's a live surprise.

5. Deploy

Once it's built and tested, it moves into a dedicated production environment — with proper security controls, backups, documentation detailed enough to rebuild from scratch if it ever had to be, monitoring and alerting to catch issues immediately, and audit logging so you always know who did what, and when.

6. Support

Once live, ongoing support means troubleshooting issues quickly and keeping the system running the way it's supposed to.

7. Improve

Systems aren't "set and forget." I come back and review how things are actually performing, looking for what's working well and what could work better.

8. Adapt

Your business changes, and the system should change with it. This stage feeds straight back into "Discuss" for the next round of improvements — the process is a loop, not a straight line.

Why this matters in practice

I've used this process on dozens of projects. One clear example: a sports tipping system I rebuilt from scratch for a digital marketing agency. The old version had no automated tests. The rebuild had tests covering 90% of the code and simulated entire tipping seasons before going live. It was the first year the results weren't contested — no more "two winners due to a bug." The system then ran for nine years afterward with virtually no updates required, because it was done properly from the start.

I don't think I know everything, and there's always more to learn — but this process is how I make sure the systems I build for you are reliable, maintainable, and built to last.