Skip to content

Capability

Full-Stack Web Development

Twenty-five years of building for the web: PHP and the LAMP stack, .NET and C#, JavaScript, and the database design underneath. Applications that get maintained, not just launched.

What is actually included

  • PHP applications, APIs, importers, parsers, and integrations
  • .NET and C# services alongside existing enterprise systems
  • JavaScript front-ends, without a framework where none is warranted
  • WordPress as an application platform rather than only a CMS

Learned in the order it was invented

I started in 1999, which meant markup first, then servers, then databases, then everything layered on since. That order still pays off: most debugging is knowing which layer to suspect, and that instinct is hard to acquire from the top down.

The bulk of it has been PHP on the LAMP stack – applications, APIs, data importers, parsers, mail handling, and the model-view-controller plumbing underneath – alongside .NET and C# where the organisation already ran Microsoft, and JavaScript on the front end.

A view on frameworks

Frameworks are worth their weight when a team is large enough that convention beats invention. They are a liability when they are chosen for a small internal tool that then needs upgrading for a decade. The interesting question is rarely which framework – it is whether this needs one at all.

The same applies to JavaScript. Plenty of interfaces that ship as a single-page application would be faster, simpler, and cheaper to maintain as server-rendered pages with a little JavaScript on top. Sometimes the answer really is a framework – but it should be an answer, not a default.

WordPress as an application platform

Used well it is a capable content and application framework with an enormous amount of solved plumbing. Used badly it becomes forty plugins nobody can remove. The difference is usually whether anyone was willing to write the code rather than install another dependency.

  • Custom themes built to standards, without a page builder
  • Custom post types, meta, and admin interfaces for real editorial workflows
  • Plugin development rather than plugin accumulation
  • Performance and security work on installations that grew unmanaged