Around 2017 I stopped trying to be a one-size-fits-all developer. The cost of constantly switching tooling, languages, and platforms per project - and the cost of inheriting other developers' codebases written in whatever they happened to like that year - had become bigger than the cost of saying no to work that did not fit one stack.
This post is the reasoning. It also names what is in the stack now, what it has shipped, and what it does not try to do.
What I was doing before
For years before the switch, the day-to-day was custom features and plugins for WordPress and WooCommerce. PHP and MySQL underneath. The work paid the bills and built the WooCommerce specialisation that still gets called on today (more on that in the WooThemes-era post).
The friction was not WordPress or PHP themselves. The friction was that every project beyond a custom plugin needed more than WordPress could give it cleanly - a real API, a mobile app, a dashboard, a separate reporting database. Each of those came with its own language and its own stack. By 2017 I was maintaining work in PHP, JavaScript, occasional Python, native iOS, and native Android. None of it composed well.
The decision
The decision was to commit to one stack across everything: front end, back end, APIs, mobile. The constraint was that the same language and the same idioms had to work top to bottom.
JavaScript was the only candidate that hit all of those at the time. React for the UI. Node.js for the API. React Native for mobile. PostgreSQL underneath for serious data. The whole thing in one language meant one set of dependencies, one build tool family, one mental model.
Next.js arrived in February 2022 and folded the React + Node story into a single framework. The deeper Next.js post covers that decision separately.
What is in the stack now
| Layer | Tool |
|---|---|
| UI framework | React (TypeScript) |
| Web framework | Next.js |
| API server | Node.js (Express, sometimes more specific) |
| Mobile | React Native |
| Database | PostgreSQL (relational), MySQL (when the source system is WordPress) |
| Static hosting | Vercel / Netlify class |
| Image pipeline | sharp + comfyui for generated covers |
The whole thing speaks one language. The same engineer reads the front-end code, the API code, and the mobile code without context switching.
What the stack has shipped
This is the part that keeps the choice honest. The stack is not theoretical. It is what built:
- antondevilliers.com itself. Next.js, server-rendered, structured data per page. The page that ranks first-page Google for "custom software developer Cape Town" is on this stack - see the case study.
- BX1X - a 37+ module business operations platform: billing, bookings, CRM, accounting, inventory, e-commerce. One Next.js app surface, one database, one auth model.
- Authentikor - my own SaaS product. React + Next.js + Node + PostgreSQL. Multi-tenant with subscription billing.
- Custom Node.js + PostgreSQL reporting layers over WordPress / MemberPress installs - see the worked case study.
- Headless WordPress + Next.js builds - WordPress as the back-end content / admin store, Next.js as the public render layer. Performance and SEO scores in the 99-100 range.
- Custom Shopify apps - the front end of the embedded app is React; the back end is Node; the store-side widgets are TypeScript.
A single stack covers the full surface of work I do. The exception is when a client comes in with an existing system on a different stack - then the work is integration, not rebuild.
Technical detail (what each layer is doing)
For developers reading this who want the structural picture:
- React owns the rendered UI tree. Component model, prop flow, hooks for state and effects. TypeScript on every component.
- Next.js owns the page-render decision per route - server, static, client, edge - and the build / deploy pipeline. The blog post you are reading is statically rendered by Next.js from a Markdown file.
- Node.js owns the API. For most Next.js apps the API lives inside Next as routes. When the API work is heavy (warehouse refresh, third-party joins, queue processing), it lives as a separate Node service alongside.
- React Native owns the mobile surface when one is needed. The same engineer who wrote the web UI writes the mobile UI, with shared types and shared logic where it makes sense.
- PostgreSQL owns serious data - anything multi-tenant, anything reporting, anything that needs partitioning or strong indexing. MySQL stays in the picture only where the source is a WordPress install.
The interesting decisions in any project are usually about how the layers compose for that specific business, not about which technology to use. The stack is settled. The architecture is what is decided per project.
Why "single stack" matters at handover
Three years into a software project, the question that decides whether the build is a long-term asset is: who maintains this when the original team rotates off?
If the answer is "anyone who can read modern JavaScript and React", the answer is good. The hire pool is huge. The mental model is shared across the industry. Documentation is everywhere.
If the answer is "the one developer who happened to know the niche tooling we picked in 2018", the answer is bad. Maintenance becomes a hostage situation. Costs go up.
A single, mainstream stack is what makes a custom build a long-term asset instead of a long-term liability. That is the operational reason single-stack matters more than the technical reason.
What the stack does not try to do
Three things I deliberately do not pull onto this stack:
- Heavy data science / ML training. JavaScript is not where the model training happens. When a project needs that, it lives in Python (separate service, called via API).
- Game / real-time engines. Different problem class, different tools.
- Embedded / IoT firmware. The stack does not pretend to be C.
For everything else - most business software for SMBs and senior internal teams - the stack covers the surface.
When the stack is the answer (and when it is not)
The stack is the answer when:
- The build is going to outlive the original team
- The same developer needs to write the UI, the API, and the mobile app
- One repo, one deploy, one language is operationally cheaper than polyglot
- The project benefits from server-rendered pages for SEO and LLM citability
It is not the answer when:
- The work is a one-off marketing site with no backend (Astro / Eleventy is lighter)
- The project depends on heavy ML training (Python lives in a separate service)
- An existing in-house team is already operating on a different stack and switching costs more than the rebuild benefit
For most of the business software I get asked to build, the answer is the stack. For everything else, the consultation is where we figure that out.
How this connects to the rest of the site
If you want to see what gets built on this stack, /projects has the project list. The BX1X post describes the largest single build. The Next.js stack post goes deeper on the framework choice. The Node.js + PostgreSQL reporting post shows the API + warehouse pattern in production.
For service-page entry points: /services/cloud-applications for the broad custom application work, /services/api-servers-microservices for the API side, /services/mobile-app-development for the React Native side, /services/wordpress-woocommerce for the WP / WC work that the stack still touches.
If you have a project that needs custom software and you want to know whether this is the right stack for it, get in touch. Decided in the consultation.