When the workflow is yours, the software should be too.
Bespoke systems in PHP, Laravel and React. Several of them are public on GitHub, so you can read how I build before you commission one.
Applications you can actually open and read
Most agencies describe custom software in the abstract. Here are systems I have built, in public, with the source available.
A point-of-sale and stock system in React, Node and Prisma that ships to both the browser and a Windows desktop build, with double-entry accounting. A local-first Electron desktop app with isolated profiles backed by SQLite. A workspace API in Fastify with a React admin console and a Manifest V3 browser extension. Two halves of a services marketplace, provider and customer. A Mapbox-backed directory search.
All of it sits at github.com/softglazee.
That is what I mean by a custom application: not a bigger website, but a system that does a specific job inside a business, written to be handed over and maintained by somebody who is not me.
What I build
- internal dashboards
- client portals
- admin environments
- booking systems
- lead distribution systems
- custom business tools
- workflow management
- account-based systems
- operational interfaces
- data-driven applications
- customer-facing platforms
- desktop tools in Electron
Why businesses outgrow generic tools
Most businesses start on ready-made platforms, and that is the right call. The trouble starts later, and it starts quietly.
The Limitation of Generic Software
- The workflow gets more complex than the tool allows.
- Somebody keeps a spreadsheet alongside the system.
- The process bends to fit the software instead of the reverse.
- Manual workarounds multiply and nobody documents them.
- Data ends up in three places and none of them agree.
- New staff take weeks to learn the workarounds.
The moment a system starts slowing the business down, it stops being a solution.
The Strategic Necessity
That is usually the point where a custom application stops being a luxury and starts being cheaper than the workarounds it replaces.
A bespoke system lets the business work the way it actually works.
What makes my approach different
I write these systems to be maintained by somebody else. That is the constraint that shapes everything, and it is the one most builds ignore.
Business logic
The system has to reflect how the business really works, not how a generic tool assumed it should.
Usability
Complex functionality should still feel obvious to the person using it at nine in the morning.
Performance
It should stay responsive under real daily use, not just in a demo with twelve records in it.
Scalability
Room for more users, more features and more operational complexity, without a rewrite.
Control
You get the repository, the credentials and the documentation. No proprietary layer you can only maintain by paying me.
Integration logic
Where it matters, the system should work coherently with the tools already around it.
Where custom applications create real value
Custom applications earn their cost when a business has recurring operational patterns too specific for generic tools to handle well.
Internal operational systems
Dashboards, workflow tools, approval flows and management interfaces. My inventory and point-of-sale system is a public example, including the double-entry accounting behind it.
Client-facing portals
Secure areas where customers or partners log in, see their own data and take action. The provider and customer halves of my services marketplace are both public.
Lead and enquiry management
Systems that organise, route, score or process incoming opportunities. My service-request build matches jobs to nearby providers by distance across twenty-plus trades.
Data and custom service platforms
Applications that carry a business model rather than describe one. My directory search build handles Mapbox-backed distance search and provider profiles off a configurable post type.
“The best custom applications do not just digitise a process. They improve it.”
The stack I actually work in
PHP and Laravel on the back end, React and TypeScript on the front, Node and Prisma where the data layer needs it, and Electron when the tool has to live on a desktop. The list is short on purpose: it is what I can still support a year after launch.
“The right architecture is not the most fashionable one. It is the one that serves the system properly.”
How I approach custom application work
These systems sit close to daily operations, so the process matters more than it does on a brochure site. Getting it wrong is expensive in a way a slow homepage is not.
1. Discovery
The workflow, the people using it, where the friction actually is, and what it currently costs you.
2. Strategy
What the system has to do, what it deliberately will not do, and how success gets measured.
3. UX and system design
The user journey, interface logic and interaction flow, so the system feels obvious rather than clever.
4. Development
Built in version control, with attention to structure, performance and the person who maintains it next.
5. Testing on real data
Tested with your actual records and edge cases, not a clean demo dataset that hides the problems.
6. Handover
Repository, credentials and documentation to you. Continued work is optional and never a condition of the build.
Who this is best suited for
Custom application work with SoftGlaze is a strong fit for businesses that:
- have outgrown generic software
- are running a spreadsheet alongside the system
- want to remove manual work rather than manage it
- need something shaped around specific business logic
- want their own code, not a subscription to mine
- would rather talk to the developer than an account manager
I am one person, so I cannot take unlimited work, and I will say so rather than let you find out halfway through a build.
Why SoftGlaze is a stronger choice
These systems usually sit close to how a business actually earns money, so a build that is merely technically competent is not enough.
It has to be logically sound, operationally honest about its limits, and readable by whoever inherits it. I write it that way because I have inherited enough systems that were not.
You can check that claim rather than take it. The source for several of these builds is public.
That matters more when the application is part of how the business runs than when it is a page somebody visits once.
If your business has outgrown generic tools, it may be time to build a system that actually fits.
Tell me what the workflow is and where it breaks. If it is not a good fit, I will say so quickly and point you somewhere better.