Notes from the delivery team
Short, practical write-ups on the decisions we keep making on client projects — when to move off spreadsheets, what to automate first, and why a lighter site usually wins a B2B enquiry. Open any note to read it here.
Notes
Six things worth writing down
No gated PDFs and no newsletter wall — each note opens in place.
Web performance
Why a lighter site usually converts better
Heavy client-side frameworks cost you on the first load, and the first load is the only one a new B2B visitor gives you.
A single-page application ships its framework, its router and its state layer before it can render anything. On a good office connection that is invisible. On a procurement manager's phone on a plant floor, it is the difference between a page that appears and a page that gets abandoned.
The pattern we keep coming back to for marketing and catalogue sites is simple: send finished HTML, keep JavaScript for the parts that genuinely need it, and give every image explicit dimensions so nothing jumps around while it loads. That last point matters more than it sounds — layout shift is the failure mode visitors notice most and describe least.
None of this means frameworks are wrong. An application behind a login, with real client-side state, is exactly what they are for. The mistake is paying an application's start-up cost on a page whose entire job is to load fast and say what you do.
ERP & business software
When an SME should graduate beyond spreadsheets
Spreadsheets hold up until the hand-offs between people start costing more than the software would. Here is where that line usually falls.
Spreadsheets are genuinely good software. They are fast to change, everyone can read them, and they cost nothing. The problem is never the spreadsheet — it is the hand-off. One person owns stock, another owns dispatch, a third owns invoicing, and the same number is retyped at each boundary.
The signals that a business has crossed the line are practical rather than numerical: two people maintain versions of the same sheet; someone spends a day a month reconciling figures that should agree; a customer question takes a phone call to answer because nobody can see the whole order; a month-end close depends on one person being available.
When that is the situation, the useful first step is not to buy a large ERP. It is to pick the single worst hand-off and put one system around it — usually stock and dispatch, or job cards and billing. Get that working, let the team trust it, then extend. A staged move keeps the business running and means you only pay for what you actually use.
AI & automation
Choosing the first process to automate
The best first candidate is rarely the most complex one. It is the repetitive, well-defined task nobody wants to own.
Automation projects tend to fail for one of two reasons: the process chosen was too ambiguous to automate, or it was so rare that the saving never covered the build. A good first candidate is the opposite of both — it happens often, the rules are written down somewhere, and the current owner would be glad to hand it over.
In the businesses we work with that usually means one of a short list: reading supplier invoices or delivery notes into a system, answering the same handful of enquiries on WhatsApp, chasing payment reminders, or moving data between two systems that do not talk to each other.
Two things are worth deciding before any of it is built. First, what happens when the automation is not confident — there has to be a human queue, not a silent failure. Second, how you will know it is working: a count of documents processed and exceptions raised, visible to the people who used to do the work by hand.
Mobile
Native or cross-platform: how we actually decide
The answer depends less on the technology than on who uses the app, where they use it, and what hardware it has to touch.
Cross-platform tooling has become good enough that the old performance argument rarely decides anything on its own. What still decides it is hardware and distribution. An app that leans on the camera in an unusual way, talks to Bluetooth scanners, or needs deep OS integration will cost less to build natively than to fight through an abstraction layer.
For most business apps — a field team logging jobs, a dealer placing orders, a customer tracking a shipment — a single cross-platform codebase is the pragmatic choice. One team, one set of fixes, and the feature reaches both platforms at once.
The constraint we design around more than either of those is the network. Apps used in plants, warehouses and on the road have to work with an unreliable connection: queue the action locally, show the user it is queued, sync when there is signal. That decision shapes the architecture far more than the framework does.
SEO & growth
B2B search is a different job from consumer SEO
The audience is a procurement team running a shortlist, not a shopper. That changes what a page has to contain.
Industrial and B2B search volumes are small. A query that brings thirty visits a month can be worth more than one that brings three thousand, because the thirty are engineers writing a specification. Optimising for volume in this market reliably produces traffic that never enquires.
What tends to work instead is writing the page the buyer is actually trying to find: the grade, the tolerance, the capacity, the certification, the lead time. Specifications are the content. A page that answers a qualification question without a phone call is doing the job of a first sales call.
The technical side is unglamorous and matters anyway — a site that renders quickly, has a sane URL structure, and describes its products in markup search engines can read. There is no link-buying shortcut here, and in a market this small it would be obvious.
Cloud & SaaS
Keeping multi-tenant infrastructure costs sane
Most runaway cloud bills come from a handful of decisions made early, when the product had ten customers and nobody was counting.
The first decision is tenant isolation. A separate database per customer is easy to reason about and easy to bill, and it stops scaling the moment you have a few hundred of them — migrations become a fleet operation. A shared schema with a tenant key is cheaper to run and demands real discipline about every query carrying that key.
The second is connection management. Serverless functions that each open their own database connection will exhaust the pool long before the compute bill becomes the problem. A pooler in front of the database is not an optimisation; it is a prerequisite.
The third is what runs on a schedule. Background jobs that poll every minute because it was convenient during development are the line item nobody looks at. Move the heavy ones to queues, and let them be triggered by events rather than by the clock.
Recognise any of these problems?
If any of this maps onto a problem you are sitting with, tell us about it and we will give you a straight answer on what it would take.