Service
Web applications
Ordering portals, internal tools and catalogue systems — the software a business runs on rather than the software it shows off.
Most of this work starts the same way: a process that already exists, running on email threads and attached spreadsheets, priced by hand, with one person who knows where the current version lives. It works, until it is the only thing standing between an order and a mistake.
A web application replaces that with one place where the work happens. Not more software than the problem needs — the smallest useful system that removes the manual step and survives the person who set it up leaving for two weeks.
What this covers
- B2B ordering portals with per-partner price tiers and discounts applied across a whole catalogue
- Role-based access, so partners, staff and administrators see different things
- Catalogue and data import from spreadsheets or JSON, with upload history
- Internal tools: stock, reporting, document automation, production workflows
- Integrations with the systems a business already runs on, rather than replacing them
- Email and messaging notifications where a person needs to be told something happened
How it goes
Watch the current process
Before anything is designed, the existing spreadsheet and the existing email thread get read. They are the specification, written honestly by the people doing the work.
Data model first
What an order is, what a partner is, what a price tier is. Nearly every painful rebuild traces back to this being decided casually at the start.
Build the smallest useful system
The version that removes the manual step and nothing more. Features that sound good in a meeting and get used twice are the reason internal tools get abandoned.
Hand over so it survives
An administrator who can add a partner, upload a new catalogue and see order status without calling me. If that is not true, the tool is a dependency rather than an improvement.
Where this has been done
Internal systems have no public link, because they are not on the public internet.
Partner Ordering Portal
Replaced email threads and hand-priced spreadsheets with a portal where each reseller signs in and sees the catalogue at their own tier.
Internal system — no public link
Print Catalogue Production System
A yearly print catalogue laid out in the browser, image preparation included, exported press-ready.
Internal system — no public link
Offline Catalogue & Quotation App
The offline half of the same problem: a full catalogue and branded PDF quotations with no connection at all.
Internal system — no public link
Questions about web applications
We run on spreadsheets. Is that too small to bother with?
That is the usual starting point, and it is the right one. A spreadsheet that has outgrown itself is a well-documented specification — it shows exactly which fields matter and which rules people apply by hand. Small projects are not treated as practice runs.
Can it connect to the systems we already use?
Usually yes, and that is normally cheaper than replacing them. Import and export, scheduled syncs or a direct integration, depending on what the other system exposes. Replacing a working ERP because a new tool would prefer it is rarely the right trade.
Who can see what?
Role-based access is standard, not an upgrade. In the partner portal, a reseller sees their own prices and their own orders, staff see what they need to process them, and administrators manage accounts and catalogues. Confidential data staying confidential is a design constraint from the first sketch.
What happens when it breaks?
You reach me directly, because there is no support tier between us. That is also the honest limitation: I am one person, so if I am ill or already booked, you wait. An agency has someone else to send. That is a real advantage and worth weighing.
Do we have to keep paying for it?
Hosting for this kind of application is modest and stated up front. There is no licence fee to me for software I built for you, and no arrangement where the tool stops working if a subscription lapses.
Still running it on spreadsheets?
Describe the process rather than the software you think you need. The current spreadsheet is usually the best brief there is.
Start a conversation