Three products designed and built by the studio: an insurance brokerage, a platform for hospitality, and an iOS app with the site behind it.
None of them is a brochure. Each one is a working system that a business depends on every day: a brokerage that has to produce an accurate quote for a stranger, a restaurant platform that has to take an order correctly while the kitchen is full, an app that has to be right about when someone’s insurance expires. That is the kind of work the studio is built for — the website is not the deliverable, the thing it has to do is.
All three are still running, still maintained, and still being changed. A portfolio of launches would be easy to assemble and would tell you very little; what is worth knowing is whether the people who built something are still answering for it a year later.
An insurance brokerage needs to do two difficult things at once: explain cover plainly enough that a person understands what they are buying, and collect enough detail to produce a real quote rather than a guess. The site separates the two audiences from the first screen — individuals and businesses — because the questions, the products and the language differ, and a single undifferentiated form serves neither.
Behind that sit a partner area for collaborating brokers and a library of guides, written so that the firm has something to send rather than something to improvise. The technical work is unglamorous and decisive: pages that load quickly on a phone in a car park, forms that do not lose what has been typed, and structured data so that search engines understand what the firm actually does.
A QR menu is simple to describe and unforgiving to build. The guest scans a code at the table, reads the menu in their own language, orders, and pays — while the kitchen and the bar see only what concerns them. Eight languages means the content model has to carry translations for every item and modifier, not just the page furniture. Ordering from the table means the system has to behave when the connection is poor, the waiter is busy and the same table orders twice.
The product serves tavernas, restaurants, beach bars, hotels and cafes, which are not the same business wearing different names: a beach bar needs speed and large type in daylight, a hotel needs room-charge rules, a taverna needs the owner to be able to change a price in ten seconds. The platform is built so that the operator, not the studio, keeps it current.
Most people cannot say what their insurance covers or when it expires, and the documents that would tell them are in three inboxes and a drawer. AppInsure puts every policy a person holds in one place — contracts, cover, renewal dates, roadside assistance and accident care around the clock — and lets their own broker keep that record current, which is the part that makes it stay true.
The app is free for the policyholder and has a second audience behind it: the brokers whose clients use it. That is two products in one, with different expectations of speed, clarity and support, and a marketing site that has to serve both without confusing either.
Some of the studio’s work belongs to businesses that would rather not be listed, and internal tools and client portals are not ours to publish. If you are weighing up the studio for a particular kind of project, ask: we can usually describe comparable work, or put you in touch with a client who is willing to speak.
Every project shown here was quoted in writing before it began, delivered with its source, and handed over with every account in the client’s name. That is the standard, not a courtesy extended to the projects that photograph well.
Someone writes with a problem rather than a specification: enquiries have dried up, the old site cannot be edited, a product exists in a spreadsheet and needs to exist for customers. The first conversation is spent establishing what the business needs the thing to do, and what will count as it working. Only then is there a brief worth quoting against.
From there the shape is always the same: a written proposal with scope, deliverables, timeline and terms; structure agreed before any surface is designed; a build that is reviewed in the browser rather than in a slide; and a handover that includes the source, the accounts and the documentation. After launch the site is kept under care, because the first year is when it needs attention most.
A launch is a date; a working product is a record. Each of these has been live long enough to meet real traffic, real edge cases and the ordinary erosion that follows any release: a payment provider changing an API, a browser changing a default, a client needing something the original brief never imagined.
That is the part of the job that is invisible in a portfolio and decisive in practice. If you are choosing a studio, ask the ones you are considering what happened to their work two years after launch, and who answered the phone when it broke.