A short stack, chosen because I can still support it a year from now.
Twelve technologies, not forty. The list is short on purpose: it is what I can maintain properly after launch, which is a different question from what I could get working this week.
A stack is a maintenance commitment, not a shopping list.
Every technology on a project is something somebody has to keep working. Adding one is easy. Supporting it in eighteen months, after an update, when the person who chose it has moved on, is the actual cost.
So I keep the list short and I say no to things I cannot maintain. That is less impressive on a capability page and considerably cheaper for you.
How I think about technology
Technology is not the product. It is the infrastructure underneath it, and the best sign of good engineering is usually how little of it you ever have to think about.
Naming tools is not proof of capability. Anyone can list frameworks. What matters is whether the choice was right and whether the result is still maintainable when somebody else opens it.
It shows up in the architecture chosen, the logic written, the dependencies avoided, and the documentation left behind for whoever comes next.
What I weigh before choosing anything:
- suitability
- maintainability
- performance
- extensibility
- integration logic
- operational clarity
- long-term usefulness
Core technologies I work with
This is the actual foundation, across WordPress sites, WooCommerce and Shopify stores, and custom applications. Nothing here is aspirational.
PHP
PHP is the language most of my work is written in, and the one WordPress and WooCommerce are built on. Used with structure it holds up for years; used carelessly it becomes the thing everyone is afraid to touch.
What I use it for
- backend development
- WordPress and WooCommerce work
- custom web applications
- CMS logic and server-side tools
Why it matters
PHP is only as good as the discipline applied to it. Coding standards, hooks and filters rather than edited core, and no clever tricks the next developer has to decode.
Laravel
Laravel is what I reach for when a system needs its own structure rather than a CMS bent into shape. My services marketplace and inventory builds sit here.
What I use it for
- custom platforms and portals
- dashboards and business systems
- operational workflow tools
- API-connected applications
Why it matters
Laravel gives serious custom work a predictable shape, which is what makes it maintainable by somebody who did not write it.
TypeScript
TypeScript is what I write the larger front ends and Node services in. The types are not ceremony; they are the thing that makes a refactor safe two years later.
What I use it for
- typed React applications
- Node and Prisma services
- desktop application logic
- anything with a long maintenance life
Why it matters
On a codebase somebody else will inherit, types are documentation that cannot go stale. That is worth the extra keystrokes.
React
React is the interface layer for anything more interactive than a page. My admin consoles and desktop app front ends are built in it.
What I use it for
- interactive front-end systems
- dashboards and application interfaces
- admin consoles
- desktop interfaces via Electron
Why it matters
React keeps front-end logic readable when an interface stops being a page and starts being an application.
Python
Python earns its place in automation, data processing and scripting around a build rather than as the build itself.
What I use it for
- automation and scripting
- data processing and migration
- internal support tooling
- one-off jobs that should not become products
Why it matters
Not everything needs to become a permanent system. Some problems deserve a script that runs once and is thrown away.
HTML / CSS / JS
The foundation everything else sits on. Semantic markup, responsive layout, and no framework where fifty lines will do.
What I use it for
- foundational front-end build
- semantic, accessible markup
- design systems and UI consistency
- front-end interactivity
Why it matters
Most performance and accessibility problems are decided here, long before a framework is chosen.
Platforms I build on
Alongside the languages, these are the four platforms the work actually lands on. They are the same four in the navigation, because that is the whole list.
WordPress
WordPress is a foundation, not a finished product. I build custom themes and plugins on it, and my name is in the core credits six times.
Why it matters: WordPress is powerful when shaped deliberately and fragile when stacked with plugins. Four of my plugins, a theme and ten block patterns are published on wordpress.org.
Shopify
Shopify is where I write Liquid by hand for stores that have outgrown a bought theme. Theme code lives in version control, not the theme editor.
Why it matters: in e-commerce the platform matters, but the refinement on top of it decides whether the store converts.
WooCommerce
WooCommerce is WordPress with money attached, which changes the standard. I build and maintain a WooCommerce invoicing extension published on the official plugin directory.
Why it matters: order data goes through WooCommerce CRUD rather than direct queries, so a platform update is routine instead of a rescue.
Electron
Electron is how a tool reaches the desktop when the browser is the wrong place for it. My isolated-profile browser and the desktop build of my point-of-sale system both use it.
Why it matters: some workflows genuinely belong on a machine rather than a tab, and pretending otherwise produces a worse tool.
AI, automation and the tooling around a build
A build is more than the code shipped. There is version control, deployment, local environments, and increasingly AI assistance in the writing of it.
I work in that space openly rather than quietly.
I use AI-assisted workflows where they:
- reduce repetitive effort
- speed up the boring parts
- structure information more effectively
- support consistency across a codebase
- catch what a second pair of eyes would catch
- free up time for the decisions that actually need judgment
Nothing reaches you until I have watched it run in the actual environment. That rule comes from core contribution work, and it is why my bug reports get accepted.
How I choose the right technology for a project
I do not start with a favourite tool. I start with what the thing has to do and who has to maintain it.
That is why the technical decisions here are maintenance-led rather than fashion-led. The goal is not to impress another developer in a code review. The goal is a system that still works, and can still be changed, long after the invoice is settled.
> Project Diagnostic: what I ask first
- ? What does the system actually need to do?
- ? Who will use it, and how often?
- ? How complex is the workflow underneath?
- ? What has to scale, and what never will?
- ? What must stay lightweight?
- ? What genuinely needs custom control?
- ? Who maintains this after handover?
- ? How much flexibility does the business actually need?
The stack follows from those answers, not the other way round.
What you are really buying when you hire technical judgment
You are not buying access to languages or frameworks. Those are freely available and largely interchangeable.
Technology alone is not differentiating. Judgment about technology is.
Why Technical Judgment Matters
You do not need to know every implementation detail. You do need confidence that the person choosing was thinking past launch day.
Weak technical choices tend to produce:
- performance problems and maintenance pain
- avoidable complexity and rigid systems
- poor scalability and fragile operations
The value is in choosing well and implementing cleanly, so the result stays workable rather than becoming somebody else’s rewrite.
The Structural Investment
When you hire technical judgment, you are investing in:
- stronger architectural decisions
- cleaner technical execution
- more reliable systems and realistic scalability
- lower friction in the finished product
- stronger platform fit
- a build more likely to hold up over time
The visible layer gets the attention. The technical layer decides how long the result stays useful.
Why businesses trust SoftGlaze with technical execution
Businesses choose SoftGlaze because the technical capability comes with restraint about when to use it.
I do not build for abstraction. I build for clarity, fit, usefulness and whether it can be handed over cleanly.
Technical work here is never separated from:
- the person using it
- the business logic underneath
- how trust is formed
- realistic performance expectations
- whether it can be maintained next year
I know how to build. More usefully, I know what should not be built, and I will tell you which is which.
If your build needs a stronger technical foundation, let’s look at it properly.
SoftGlaze is one developer working across WordPress, WooCommerce, Shopify and custom applications, with the code public wherever it can be.