Client work
Linked Corporate International
A marketing site for a London import and export company trading agricultural produce, food commodities and recycled materials.
Eight pages covering a ten item product catalogue with sourcing origins, two recycling service pages, and a filtered photo gallery of trade shows and site visits. Enquiries go through a floating button that opens WhatsApp with the current page already quoted, because that is how the buyers actually make contact. No database, no forms, no login: the whole site is a build artifact.
What it does
- Eight page static site with no backend to maintain
- Product catalogue of ten items across three categories with sourcing origins
- Dedicated ship recycling and green recycling service pages with process sections
- Image gallery with nine client-side category filters and per-category counts
- Floating WhatsApp enquiry button pre-filled with the page the visitor is on
- Contact page carrying registered office, company number, SIC code and a Companies House link
- Cookie consent banner storing the choice in the browser
- Structured data for organisation, local business and site, with a generated sitemap and robots file
A buyer moving a container of sugar is not sitting at a desk. He is in a yard, or in an office two time zones away, on a phone, and this morning he is messaging several suppliers to find out which one answers first. Linked Corporate International sells into exactly that habit. Its website therefore has one job, and about ten seconds to do it: say what is for sale, say where it comes from, and put the reader into a conversation with a person. The interesting half of this project is everything we decided not to build.
Why it exists
Linked Corporate International Ltd is a London company, number 14243624, registered at 21 Rectory Square in E1 and filed under SIC code 46341. It imports and exports agricultural produce, food commodities and industrial materials, and separately handles ship dismantling and material recovery. The people it deals with are wholesalers, importers, food manufacturers and distributors, and the goods come from Egypt, Brazil, South Africa, Turkey, Australia, Canada, Palestine and Europe.
Trade of that kind runs on introductions, trade shows and messaging apps. A website does not close a deal in that world and nobody involved expects it to. What it does is answer the two questions a stranger has before they will start a conversation: is this company real, and does it actually handle the thing I need. So the brief came out narrow. A catalogue that names goods and origins precisely enough that a buyer can tell whether it is worth an enquiry. Registration details a sceptic can check. Photographs from farms, factories and trade stands, because in commodity trade the evidence that you were physically there is worth more than a paragraph of adjectives. And one route to a human.
There is no email address anywhere on the site or in the code. That is not an oversight, it is the client's read of how their buyers behave, and the whole build follows from it.
How it works
Eight pages: home, products and services, gallery, scrap ships recycling, green recycling, contact, terms and cookie policy. The catalogue carries ten items in three groups. Agricultural products covers Medjool dates, apples and oranges, lentils, yellow corn and wheat. Food commodities covers ICUMSA 45 sugar, milk powders and cooking oil. General trade covers fruit and vegetables, textile chemicals and textile garments. Each item gets a description and the countries it is sourced from. The two service pages each carry a feature list and a process section.
Nothing on the site talks to a server of ours, because there is no server of ours. It ships as a static export: a folder of files.
| What the page does | Where it happens | What it needs at runtime |
|---|---|---|
| Product catalogue with sourcing origins | Rendered to HTML at build time | Nothing |
| Gallery filtering, nine categories with counts | The visitor's browser, over a fixed set of images | Nothing |
| Cookie consent choice | Local storage in the browser | Nothing |
| Sitemap and robots file | Generated at build time from the route list | Nothing |
| Structured data for the organisation, the local business and the site | Rendered to HTML at build time | Nothing |
| Enquiry | The visitor's own messaging app | Nothing of ours |
The enquiry route is a floating button on every page that opens a chat, and the detail that makes it earn its place is the prefilled first message: it carries the URL of the page being read. Someone on the sugar section taps once and the supplier's first line already says which product prompted it. No fields, no captcha, no confirmation email, and no opening message that reads "I am interested in your products".
The contact page does the unglamorous credibility work. Registered office, company number, SIC code, opening hours of nine to six Monday to Friday, and an outbound link to the Companies House record so anyone who wants to verify the company can do it in one click instead of writing to ask.
The decision that shaped it
Two choices, and they are really the same choice made twice.
The first was to ship no contact form. A form is a queue the buyer never agreed to join and a small piece of infrastructure you agree to run forever: a submission endpoint, spam filtering, storage, a person who checks the storage, and a lawful basis for the personal data now sitting in it. Its failure modes are all silent. The notification address belongs to someone who left, the alerts have been going to junk for a month, the form service changed its API. Enquiries stop and everyone concludes the market is quiet. We wrote up the full argument, including the four cases where a form still wins, in a chat link beats a contact form.
The cost is real and worth naming. The enquiry history lives on a handset rather than in a database, so if the person holding that phone leaves, the thread history goes with them. Not everyone has the app, and some corporate networks block it. And with no form and no analytics script, the business can see how many conversations started and nothing whatsoever about how many people looked and left. For a company whose enquiries arrive through trade shows and reputation, that was acceptable. For one buying advertising it would not be, and we would have built it differently.
The second choice was to leave out a content management system. That is the decision most likely to be questioned, so here is the arithmetic behind it: a brochure site with a CMS behind it acquires a login, a dependency tree, a monthly patching obligation and a renewal date, in exchange for edits that in practice happen when the product range changes. Two years on, the versions are old, nobody wants to be the one to upgrade, and a two word copy change costs a day of work before it costs a minute of typing. Without a backend there is nothing to patch, nothing to compromise and nothing to renew.
What that costs is straightforward. Content changes need a developer and a rebuild. We only take that trade when the honest count supports it: how many people need to edit, how often, and can they wait a day. The same question came out the other way for Taxcare Accountancy, where twelve service pages and around eighty-five articles change often enough that the content had to live in a database with an admin area in front of it.
Where it stands today
The site is live and serving all eight pages. A few things about it are worth stating plainly rather than leaving to be discovered.
The trading history figures on the homepage, including the years of experience and the count of countries served, are the company's own claims. We have not independently verified them, and the UK company registration is more recent than the earliest date quoted. The employee range declared in the structured data is likewise uncorroborated by anything else on the site. No prices appear anywhere: the homepage offers competitive pricing and flexible payment terms as a selling point and the structured data carries a generic price band, but there are no figures, tiers or published quotes. The two recycling pages describe facilities and processes without naming a yard, site or partner, so whether that work is operated directly or brokered is not something the site establishes.
On our side of the fence, the repository README has drifted away from what the repository contains: it names an older framework version than the one pinned, and it omits the enquiry button entirely. Hosting is not declared in any config file in the project, so it is inferred from response headers and one old commit message rather than known from the source. Neither of those breaks anything today. Both are the kind of small untruth that costs somebody an afternoon in two years, which is why they are written down here.
What this says about how we work
The strongest argument for a build with no moving parts is not speed, although it loads quickly. It is that a static site cannot rot from the inside. We have the counterexample in our own portfolio: 360nutri still paints its sign-in screen perfectly while the hostname behind it no longer resolves, which is the ordinary way software dies and the reason we are sceptical of running infrastructure that nobody has a reason to look at.
Choosing the smaller shape is a decision, not a shortcut, and it is one we argue for often enough that it shows up in how we scope and price work. The version of this site with a headless CMS, an admin login, a form pipeline and an analytics stack would have taken longer to build, cost money every month, needed patching by someone and been worse at its job. Most brochure sites are running a stack in order to serve a form that could have been a link. Work out which channel the buyer already has open, build that one properly, then delete everything the site no longer needs.
What we wrote about building it
More of the same kind
Want something like this?
Tell us the shape of the problem and we will tell you honestly whether we are the right people for it.
Start a conversation