Technology Solutions Built for Your Industry

How buyers and agents actually use a property site

Most property traffic arrives with a specific place and a specific budget already in mind. People open a site on a phone, often while travelling between viewings, and they expect to narrow a search in a few taps rather than browse a grid of thumbnails. That single behaviour has a large effect on the design: filters need to work before results have loaded, saved searches need to be reachable again, and every listing has to be legible at phone width with the price, the area, the number of rooms and a usable photograph.

On the other side, the people operating the site need something quite different. An agent cares about which enquiries are theirs, which ones have been contacted and which are still waiting for a reply. A manager cares about response time and about listings that have gone stale. A marketing team cares about which pages are being found and whether the detail pages are indexable. A single public-facing template rarely serves all three, which is why the internal tools matter as much as the search page.

Where property data usually causes trouble

Property data arrives from several systems at once: an agency management tool, a developer feed, a spreadsheet maintained by hand, and photographs dropped into a folder. The fields rarely line up, addresses are formatted differently in each source, and a unit that was let last month may still be live on the website. Cleaning that is unglamorous work, but it decides whether search returns anything useful.

• Normalise addresses, unit identifiers and status values into one agreed definition
• Decide what happens when a listing is withdrawn, and make sure it leaves the public site immediately
• Keep the agency feed and the website in step so nothing has to be re-entered twice
• Store media against the property record so photographs follow the listing when it moves

What we usually build into the enquiry path

The enquiry path is where most property websites are weakest, so it deserves deliberate design rather than a stock contact form. In our experience the useful pieces are unglamorous: a short structured form that asks only what an agent will actually need, an instant acknowledgement to the enquirer, a copy to the right agent based on area and specialism, and a visible status the enquirer can check. Adding a viewing booking step removes a round of email correspondence that otherwise happens for every appointment.

When an enquiry is not a good fit, saying so early is better than letting it age. A short qualification step, kept to a couple of questions, lets the team route properly and gives the visitor an honest answer instead of silence.

Integrations that tend to matter

• Agency or MLS feeds for listing data, kept in step with a scheduled import
• CRM or helpdesk for enquiry ownership, status and response tracking
• Email and calendar for viewing bookings and automated reminders
• Accounting or payment tools where deposits are collected online
• Map and mapping services for area search and boundary drawing
• Analytics and search console so the pages that bring enquiries can be identified

Security, access and scale

Agent and office tools sit behind authentication, so roles matter: an agent should see their own pipeline, a branch manager should see the branch, and an administrator should manage users without seeing anything they do not need. Sensitive material such as tenancy documents should not sit in a publicly reachable folder, and every upload should be validated by type as well as extension. For growth, the practical constraint is usually search and media rather than the listings themselves: listings paginate cleanly, images are served in responsive sizes, and the cache absorbs traffic on a launch date without a database change.

Getting started

The most useful first conversation is about the enquiry path rather than the website. If you can describe how a viewing is currently booked and where enquiries land, the technical scope follows fairly quickly. We are happy to look at an existing site or feed first and tell you honestly what is worth keeping. You can read more about how we work in our Insights section, or get in touch to arrange a conversation.

Software rarely fixes a clinical problem on its own

Most healthcare technology projects we are asked to look at are, underneath, an administrative problem. The clinical work is already being done well; what is expensive is the booking phone line, the referral letter that has to be retyped, the reminder call, the report assembled by hand every Friday. Fixing that is usually a smaller and more reliable project than introducing anything new to the clinical side, and it is where the measurable time saving comes from.

It also changes what "done" means. A booking flow is not finished when the form submits; it is finished when the confirmation reaches the patient, the diary is updated, the reminder is scheduled, the cancellation frees the slot, and the patient can rebook without ringing. Writing that whole path down before any code is the single most useful thing we do in the first week.

Patient-facing information has a different job

A condition page, a service description and a pre-appointment form are read by people who are worried, in a hurry, often on a phone, and frequently with a low tolerance for jargon. The writing matters as much as the layout. Short sentences, plain terms, a clear next step, and answers to the questions people actually arrive with. The technical SEO work still applies, but it serves the reader rather than the crawler: headings that reflect real questions, structured data that matches visible content, and no page that exists only to attract a search.

Accessibility is not an optional extra here. A meaningful share of patients use screen readers, browser magnification or voice control, and a booking flow that works for everyone is also a booking flow that finishes more bookings. We test to WCAG 2.2 AA and include keyboard and screen-reader passes in the test plan rather than treating them as a later phase.

Internal tools that remove real work

Internal systems are where the quiet savings accumulate. Dashboards that show today's list, the rota, the outstanding referrals and the stock levels, assembled from data the team already has. Report builders that turn a week of activity into something that can be sent rather than assembled. Single sign-on so staff are not maintaining another set of credentials, and sensible defaults so nobody has to remember a filter combination they use every morning.

• Role-based access so each role sees only what it needs
• An audit trail for who viewed or changed a record, and when
• Data export that the organisation's own privacy process can handle
• Interfaces to existing systems instead of a second source of truth

Integrations worth planning early

• Practice management or clinical record systems, usually through an API or scheduled export
• National or regional referral and booking services where a listing is required
• Payments for deposits, fees and prescriptions
• SMS and email providers for reminders, which are read far more reliably than email alone
• Identity and consent services where a patient's verified identity matters

Security, governance and scale

Healthcare software is held to a different standard than a marketing site, and that shows up in the build. Access is granted by role and reviewed; privileged actions are logged; data in transit and at rest is encrypted; uploads are validated by type as well as extension; and every dependency is kept patched on a schedule rather than when something breaks. Where personal data is processed, the data flows are documented so the organisation's own privacy review has something concrete to read.

Scaling is usually a reporting and export problem before it is a traffic problem. Most internal healthcare tools serve a clinical team rather than the public, so the work is making sure a year of history does not make a screen unusable and that an export completes within the time the team actually has.

Where to start

The right first step is usually the administrative task with the clearest cost. If you can point at a process that consumes staff hours every week, we can tell you what a realistic improvement looks like and whether software is the right answer at all. We write about the practical side of this in our Insights section, and you can start a conversation whenever it suits.

The catalogue is the hard part

Storefront projects are usually scoped around the design and underestimated around the data. A range of a few hundred products is straightforward. A range that includes variants, bundles, pack sizes, regional pricing and supplier-specific codes is a data modelling problem wearing a storefront's clothes, and it decides whether search, filtering, stock and checkout work at all.

That is why we model the catalogue before we draw any page. Attributes are defined once, variants inherit from a parent product rather than being duplicated, and supplier feeds are mapped into the agreed structure on arrival. When a new range is added later, the owner adds data rather than editing templates, which is the difference between a store that scales and one that needs a developer every quarter.

Search and discovery decide how much of the range is seen

Most stores show a small fraction of their range through search and category browsing. Typo tolerance, synonyms, faceted filters, correct use of structured data and genuinely fast response times all affect how much of the catalogue becomes reachable. On mobile, where a large share of sessions start, the filter has to work before the results arrive and stay usable with one hand.

Merchandising matters as much as the mechanics. Collections, bundles and recommendation slots are where a range gets browsed, and they need to be editable by the team running the business rather than frozen into a theme.

The checkout is where revenue is decided

Every field, every redirect and every validation rule in checkout is a chance to lose a sale, and each one is also a place where the implementation can be quietly wrong. We build checkout around the payment methods and currencies the market actually uses, keep it as short as the regulations allow, and make failure states recoverable. A shopper who mistypes a card number should be able to correct it, not start again.

• Guest checkout by default, with account creation offered after payment
• Address validation that adapts to the destination country
• Payment methods matched to the market, with local options where they matter
• Tax, duty and shipping calculated before the customer reaches the payment step
• Clear delivery estimates, because surprise costs are a common cause of abandonment

Operations are part of the storefront

Stock accuracy, order routing and returns are not back-office concerns; they are what the customer experiences. The storefront should read from one system of record rather than keeping a second opinion, and orders should flow to the warehouse and courier without being re-keyed. Where a warehouse, ERP or 3PL is involved, that integration is designed in the first phase, because retrofitting it after launch is where overselling and lost orders come from.

Performance and search visibility

Storefront performance is a revenue concern. We set budgets for Core Web Vitals, serve responsive images in modern formats, cache the pages that do not change per visitor, and keep the critical path short. The same discipline applies to search visibility: clean category and product URL structure, real product structured data that matches what is on the page, faceted navigation handled so it does not generate an unbounded number of indexable URLs, and canonical handling for products with several variants.

Getting started

A useful first conversation covers the range, the operational systems behind it and the markets you sell into. Those three answers determine almost everything else. We have written about choosing a platform and about storefront performance in the Insights section, and you can tell us what you are working with whenever you are ready.

The website and the learning platform are different jobs

People arrive on a college or provider website to decide whether to apply. They enter the learning platform once they have already applied. Treating those as one system is the usual mistake: it makes the public pages harder to build and the learning platform harder to change. We keep them separate and connect them deliberately, so the public site can be edited by marketing staff while course records, enrolment and grades stay owned by the system that manages them.

The consequence is that we start by asking where each piece of data is created and who is allowed to change it. When that is written down, the interface between the two systems becomes obvious and small, which is much easier to maintain than a shared database neither system owns.

Programme information is a comparison problem

A prospective student is usually choosing between several options and holding several facts in mind at once: entry requirements, duration, mode of study, start dates, fees and where it leads. Presenting that as paragraphs makes comparison hard. Presenting it as structured, consistently labelled fields makes it easy, and lets the same data drive the page, a downloadable factsheet and any internal search.

The writing matters just as much. Programme pages written internally often assume knowledge the reader does not have. Rewriting them for an outside audience, keeping the same facts but changing the order and the vocabulary, is one of the highest-value tasks in an education web project and it needs subject input rather than a copywriter working alone.

Applications lose candidates at predictable points

Most lost applications are not lost because the candidate changed their mind. They are lost because the process was unclear, something failed silently, or the candidate could not tell what happened next. The fixes are unglamorous and effective:

• Tell the applicant exactly what is needed before they start, including formats and file sizes
• Save progress so a long form can be completed over more than one sitting
• Show a real status, not a generic acknowledgement, and send the same information by email
• Allow documents to be uploaded again if something was wrong, without restarting the application
• Route the application to a person, with a named contact and a response time

Serving students, parents and staff from one place

A single authenticated portal can carry timetables, results, attendance, fees and messages, which removes a large amount of routine email. The important detail is that it presents data the student record system already holds rather than keeping a copy. Where a parent or guardian needs a separate view, that is a permission difference on the same data, not a second system.

For staff, the equivalent is usually a content and reporting workflow: who can publish a programme page, what happens to a withdrawn course, how the weekly report is produced, and where the underlying data came from.

Accessibility is part of the brief

Education organisations carry formal accessibility obligations, and the public website is usually where they are most visible to the people who care. Building to WCAG 2.2 AA from the first component is less work than retrofitting, because keyboard support, focus management, contrast and semantic structure are much cheaper to include than to add later. The same work benefits students using captions, transcripts, screen readers or a phone on a slow connection, and it improves search visibility at the same time.

Getting started

Tell us who the site is for, what the learning platform already does, and which journeys are costing the most manual effort. That is usually enough to identify a sensible first phase. We cover the practical side in the Insights section, and you can get in touch to talk it through.

Availability is the product

In most travel businesses the website is not really the product; the inventory is. A page that describes a property beautifully is of no use if the availability it shows is wrong, and an availability calendar that is slightly out of date produces complaints that reach the front desk before they reach the website owner. This is why we treat inventory as the starting point rather than the integration. The site reads from the system that owns availability and rates, and a booking is only confirmed once that system accepts it.

Rate rules matter just as much. Minimum stays, arrival patterns, closed dates, promotional rates and per-channel parity are all things a booking engine has to enforce correctly. We write those rules down with the commercial team before designing the journey, because a rule that is discovered during build usually turns into a special case that nobody maintains afterwards.

Photography and honest description

Travel is one of the few industries where the gap between expectation and reality is a direct driver of complaints and of the review score. Professional photography, accurate room and facility descriptions, clear policies on cancellation and check-in, and honest distance information do more for a conversion rate than any amount of interface work. We treat the content model as part of the build: structured, translatable, and editable by the team who own the property rather than a developer.

The same applies to accessibility. Travellers plan around mobility, sensory and dietary needs in advance, and information that is buried or ambiguous generates avoidable problems before arrival. Publishing it clearly is both better service and better search visibility.

Direct bookings need a reason

Channel managers keep a business connected to the platforms where most travellers start, and that connectivity is not optional. But a direct channel that offers nothing beyond the same room is competing on price against aggregators with a commission to protect. What usually shifts the balance is something the aggregator cannot do: flexible cancellation, a direct upgrade, a clearer arrival experience, or a better answer when something goes wrong at 11pm.

That is a commercial decision before it is a technical one. Our part is to make sure the direct journey is fast, that the policies are stated clearly enough to be trusted, and that the confirmation and pre-arrival information arrive in a way that reduces the number of calls the front desk takes.

Beyond the core booking

• Experience and tour commerce with its own availability and pricing rules
• Package construction combining rooms, transfers, tickets and activities
• Pre-arrival messaging with useful information rather than a generic reminder
• Post-stay follow-up that asks for a review at a sensible moment
• Partner and agent booking with its own access levels and reporting
• Revenue reporting that reconciles against the channel manager rather than restating it

Resilience matters more here than in most industries

A travel site carries a genuinely seasonal load, and a failure during a peak weekend is far more expensive than a failure in February. Caching, a content model that can be updated without a deploy, monitoring on the booking path rather than only the home page, and a plan for what to do when the upstream system is slow are all part of a sensible build. Where availability is read live from a third party, we design for that call being slow or unavailable, so the page degrades to something honest rather than an error.

Getting started

The first conversation is usually about which systems own your inventory today and where they disagree. Once that is clear, the scope of the website becomes much easier to define. We have written about booking journeys and site performance in the Insights section, and you can start a conversation about your own situation.

The data exists, but not where it is useful

Most manufacturing businesses we meet are not short of information. They are short of information in the right place at the right moment. A job sheet is on the shop floor, the schedule is on a whiteboard, the quality record is in a folder, the maintenance history is in someone's inbox, and the monthly report is assembled by hand from all four. Each of those is fine on its own. The problem is that nobody can answer a simple question without walking round the site and asking three people.

That is where software earns its place. Not by replacing the systems on the floor, but by connecting them so the answer is on a screen. It is a much smaller and lower-risk project than a plant-wide replacement, and it is usually the one that produces a visible change within a quarter.

Designing for the environment, not the office

A screen designed at a desk rarely survives contact with a production area. Interfaces used on the floor need to be operable with gloves, legible under poor lighting, tolerant of a dropped device and quick to use when someone is holding a part in the other hand. That usually means fewer fields, larger targets, clear confirmation and a way to undo a mistake without a supervisor.

Connectivity is the other reality. Large sites have areas where the network is weak or absent, and a workflow that stops working there will be worked around rather than used. Where that applies we design for capture on the device and reliable synchronisation afterwards, so a dropped connection delays data rather than losing it.

Quality and traceability

Quality systems are where the documentation requirements are least forgiving, and where searchability matters most. When a record is a scanned PDF in a shared drive, answering "which batches were affected by this fault" means an afternoon of manual work. When the same record is structured and linked to the batch, the answer is a query.

• Batch and serial identifiers that follow the item from goods-in to despatch
• Inspection results recorded against the job, not against a person who remembers them
• Non-conformance handling with a clear route from detection to resolution
• Supplier certificates attached to the delivery rather than emailed separately
• Retention and access rules that support both customer requirements and internal audit

Maintenance and downtime

Most maintenance systems fail because they are used to record breakdowns rather than to plan work, and a system that only ever records breakdowns tells you very little. Recording planned tasks, consumables and the actual downtime against an asset gives you the history needed to judge whether a replacement is due, which spares to hold, and whether a recurring fault is really a process problem wearing a mechanical disguise.

Where machine monitoring data is available it is worth collecting, but it should complement rather than replace the observation of the person operating the equipment. Data that cannot be reconciled with what the shop floor reports is data nobody will trust.

Integrations and reporting

Connecting to the ERP, the accounting system, supplier portals and machine monitoring is normal work, and the important decision is which system owns which data. When ownership is agreed, the interfaces are small and the reporting is straightforward, because each figure has one authoritative source. We also plan for the failure case: what the business does on a Monday morning when a system is unavailable is as important as what it does on a good day.

Getting started

The most productive first step is usually to spend a day on site and follow one job from order to despatch, noting every place information is written down or lost. That single exercise usually identifies the two or three changes that would matter most. We write about operational software in the Insights section, and you can arrange a conversation to talk it through.

Trust is a feature you have to design

People do not check the arithmetic on a bank statement; they check whether it looks right. That means formatting matters as much as the underlying data, that a figure should always be traceable to where it came from, and that an explanation should be available without needing a phone call. In regulated businesses the same principle applies internally: an auditor should be able to see who did what, when, and under which policy, without anyone reconstructing it from memory afterwards.

That combination of visible accuracy and visible control is what separates a financial platform that is trusted from one that is merely used. It is also why we resist shortcuts here. A figure that is approximately right, or an action that cannot be explained after the fact, is a defect in this sector in a way it would not be on a brochure site.

Reconciliation is where the real cost hides

Reconciliation is the least glamorous part of financial operations and usually the most expensive. It fails for predictable reasons: two systems using different time zones, rounding applied at different points, a status that means something different in each, and an exception queue that only a few people understand. Each exception is handled by a person until the backlog becomes structural.

The fix is rarely a new system. It is agreeing one authoritative source per figure, normalising the differences explicitly, and giving the operations team a queue they can work through rather than a report they have to interpret. Where an automated match is proposed, it should be a proposal: shown with the reason it was matched, confirmed by a person, and reversible.

Explaining money clearly

A large share of support volume in financial services comes from questions the interface should have answered: why this amount, why now, what this fee is, what happens if I do nothing. Those answers belong next to the figure, in plain language, available before the customer asks. It reduces contact volume, shortens onboarding, and it is also the accessibility and comprehension work that regulators increasingly expect.

Where documents are involved, the same principle applies. A terms document that is legally accurate and unreadable is not doing its job. Summarising the points that matter, in ordinary language, alongside the full document, is a small piece of design with a large effect on how confident customers feel.

Onboarding and identity

Onboarding is where a regulated business meets a customer who wants to be finished in five minutes. The tension is real: the checks have to be thorough and the experience has to be quick. The way through is usually to ask for identity information once, reuse it, and make the state of the application visible so the customer can see what is still outstanding instead of guessing.

• Progressive disclosure so a customer is not asked for everything at once
• Clear status with a named next step and a realistic time
• Document capture that works on a phone, with re-upload rather than restart
• Decision records that explain the outcome and what to do about it
• Consent capture that is specific, versioned and retrievable

Security, audit and third parties

Financial systems are attacked specifically, so the baseline is higher. We build with role-based access, encryption in transit and at rest, validated uploads by type as well as extension, dependency patching on a schedule, and an audit trail covering both user actions and administrative changes. Sensitive actions get step-up verification rather than relying on an existing session.

Third-party dependencies deserve the same attention as internal code. Payment providers, identity services, screening tools and data suppliers all have availability characteristics we do not control, so the interfaces are designed to fail visibly rather than silently, with clear retry, queue and reconciliation behaviour. Agreeing the escalation path with the operations team before launch is part of the build, not an afterthought.

Getting started

The first useful conversation is about which system owns which figure and how the business currently explains a number to a customer or an auditor. Those two answers define most of the work. We have written about regulated systems and handover in the Insights section, and you can get in touch when it is convenient.

Visibility is only as good as the events behind it

A tracking page is easy to build and surprisingly hard to make accurate, because it depends entirely on events generated somewhere else: a scan at a depot, a signature at a door, a status change in a carrier's system. If those events are late, duplicated or interpreted differently by each party, the customer-facing page will be confidently wrong, which is worse than being vague.

So the first question is always which events matter and where they come from. Then we design the vocabulary that maps them consistently, decide what happens when an event is late or out of order, and make the interface honest about uncertainty. A page that says a shipment is awaiting collection is more useful than one that shows a green tick of unknown provenance.

Handovers are where information is lost

Almost every logistics problem we are asked to look at comes down to a handover. Goods arrive and are keyed into a different system from the one the order lives in. A driver gets a manifest in one format and returns a signature in another. Customs paperwork is emailed to a mailbox that nobody checks. Each of these is a small task, and together they consume a surprising share of an operations team's day.

The fix is rarely a larger system. It is agreeing one authoritative source for each fact, mapping the differences between the existing systems explicitly, and removing the re-keying. Where information genuinely originates outside the business, that capture needs to be designed as an interface rather than a folder someone empties on a Friday.

Planning that survives contact with the day

Plan optimisation tools are often adopted carefully and then abandoned, usually because the output cannot accommodate a late vehicle, a customer who changed their window, or a load that will not fit. The useful planning tools are the ones that present a recommended plan and let a dispatcher adjust it with a clear view of the consequences, rather than producing an answer that is technically optimal and operationally unusable.

Vehicle capacity, driver hours, delivery windows, tolls, restricted zones and loading-dock capacity are all constraints that have to be represented, and the ones that matter differ by operation. We start by asking which constraints the business actually breaks when they are violated, and build the model around those.

What customers ask for

A large share of inbound contacts in logistics are the same small number of questions: where is my shipment, when will it arrive, can I change the address, who do I speak to about this delivery. A self-service portal that answers those accurately reduces contact volume more effectively than any additional phone capability, and it gives the operations team time back for the exceptions that genuinely need a person.

• Self-service tracking with the same status the operations team sees
• Proactive notification on the events that matter, not on every scan
• Address and delivery changes with clear cut-off times
• Documentation, invoices and proof of delivery available without an email request
• Booking and quote requests captured in a form rather than parsed from enquiries

Systems that have to talk to each other

Transport management, warehouse, ERP, carrier portals, customs systems, e-invoicing and customer ERPs all hold part of the picture. Integration is normal work, but the discipline that makes it maintainable is deciding which system owns each status and each figure, and refusing to let two systems both be authoritative. Where data is exchanged in files rather than APIs, the reconciliation still has to be designed, because a file that arrives twice or out of sequence will eventually do both.

Getting started

The most useful starting point is usually a single lane or customer, followed from booking to delivery, with every manual step written down. Fixing that lane properly tends to reveal most of the rest. We cover operational software topics in the Insights section, and you can start a conversation whenever the timing is right.

The most expensive problems are operational

Retail businesses rarely have a visibility problem. They have too much data, arriving from too many systems, none of which quite agrees with the others. Stock on the shop floor, stock in the warehouse, stock in the channel and stock on the marketplace are four different numbers, and the person deciding what to reorder is reconciling them by hand. That reconciliation is the cost, and it is almost invisible in the accounts because it is labour rather than a system fee.

The work we do usually starts by naming one authoritative source per fact and removing the duplicates. It is unglamorous, it is where most of the saving appears, and it has to come before anything more ambitious, because a forecasting tool is only as good as the stock data underneath it.

Replenishment is a decision, not a report

Most retail reporting tells you what happened. Useful replenishment tells you what to do next, and it has to arrive early enough to act on. That means the right granularity, a view of what is already on order, and a clear reason attached to each recommendation, because a store buyer who does not understand why an order was raised will stop trusting it.

We also design for the exception, because retail is full of them: a competitor promotion, a local event, a delivery that failed, a product discontinued. A recommendation engine that cannot be overridden with a reason is a recommendation engine that gets ignored.

Pricing and promotion across channels

Where a business sells through stores, its own site and one or more marketplaces, price consistency becomes an operational discipline rather than a decision taken once a season. The rules need to live somewhere the merchandising team can use, with effective dates, geographic scope and a record of what was live when. Marketplace listing updates in particular are best treated as a process with retry and reconciliation, because they fail quietly.

We also agree the channel strategy explicitly. Some ranges are price-led and belong in the marketplaces; others are service-led and should lead on the direct site. Making that decision once, in the system, prevents the two channels from quietly competing against each other on the same items.

Designing for the people on shift

Store and field staff use these systems on a handheld device, in a stockroom or a back office, often in a hurry. That constraints the design more than any brand guideline. Short tasks, large targets, a visible confirmation, and the ability to undo an error without escalation are what make adoption stick. Training for store staff and for administrators is different work and should be planned separately, because the two groups need very different things from the same product.

Omnichannel without the complexity

Click and collect, ship from store and returns across channels are valuable to customers and expensive to implement badly. The hard parts are inventory reservation so a collected order is actually available, refund routing that returns money to the right place, and store picking that does not take a colleague off the shop floor for an hour. Those three concerns need to be designed before the customer-facing features, not after.

Getting started

Ask which report the business relies on most, and then check how long it takes to produce and whether anybody trusts it. The answer usually identifies the first project, and it is often a much smaller one than expected. We have written about retail systems and operational reporting in the Insights section, and you can talk it through with us.

The catalogue is the product

For a media business the archive is usually the most valuable asset and the least usable one. Titles arrive with inconsistent names, duplicated records, missing artwork, and availability maintained in a spreadsheet that drifts out of step within weeks. The visible result is that people cannot find things they already pay for, and staff cannot answer a simple licensing question without a phone call.

Fixing that means agreeing a model. What is a title, what is a series, what is an episode, what is a version, and what makes something available in a given territory on a given day. Once those are defined, search, recommendations, rights enforcement and reporting all fall out of the same data instead of being maintained separately.

Playback is part of the experience

Video quality is not a technical detail that users notice when it works. It is the first thing they notice when it does not. Adaptive bitrate streaming, a player that behaves on an older phone, sensible buffering behaviour and correct handling of an unstable connection determine whether a viewer stays or leaves, and none of it is visible in a design file.

Audio and captions deserve the same attention. Captions and transcripts are stored with the asset rather than attached separately, which makes them available to players, to search and to anyone who needs them. For a public broadcaster or a regulated publisher this is a legal requirement in several markets; for everyone else it improves reach and comprehension.

Discovery beyond exact titles

Audiences usually arrive with a description rather than a title. They know they want something funny and set in a small town, or a documentary about a particular industry, and they cannot remember what it was called. Search built only on exact names and keywords will miss all of that.

Improving discovery is mostly a content problem: consistent tagging, a controlled vocabulary, descriptions written for readers, and artwork that is actually distinct at thumbnail size. Automated tagging and classification help, particularly across a large back catalogue, but they need a vocabulary to work within and a way for an editor to correct them. We treat generated metadata as a draft for a person to approve rather than as something published unreviewed.

Editorial workflows that do not need a developer

Editorial teams move quickly, and every change that has to wait for a developer becomes a bottleneck. A good content model lets a producer publish, schedule, update and retire an item, set rights windows, attach captions and artwork, and see the result in every channel, without writing code. That is largely a question of the admin interface being designed for the way the team already works, with sensible defaults and an undo.

Subscriptions and reconciliation

Subscription businesses live or die on trust in the numbers. Product, trial, entitlement and cancellation behaviour needs to be defined precisely, because each ambiguity becomes both a support contact and a reporting dispute. The reporting has to reconcile against the payment provider, and where a figure is used in a board pack it should be traceable to the transactions behind it.

• Product, price and trial rules defined once and applied consistently
• Entitlement state kept authoritative so playback and billing cannot disagree
• Graceful handling of failed payments, cancellations and grace periods
• Reconciliation against the provider, with exceptions surfaced rather than absorbed
• Clear consent and data handling, and no personal data in the delivery path

Getting started

Start with a single content type and a single question: who is allowed to see this, and when. Working that out for one title usually settles the model for the rest. We write about content systems and accessibility in the Insights section, and you can get in touch to discuss a specific catalogue or platform problem.

Trust is the whole proposition

People give to organisations they believe will use the money well, and they check. That means the charity's own explanations have to be specific and current, the donation process has to be obvious about where the money goes, and the annual report has to be findable rather than buried in a PDF. Technology helps here mainly by removing friction and by making information easy to find, not by adding features.

It also means restraint. A charity website that collects extensive information about a supporter in the name of personalisation often reduces donations rather than increasing them, and it creates a data protection obligation that a small organisation may not have the capacity to manage. We start from the minimum information needed to process a gift or run a project.

The donation journey is worth more attention than it usually gets

Most lost donations are not refusals. They are abandoned forms, expired pages, unclear minimum amounts, an unexpected step between choosing an amount and paying, or a payment method the supporter did not have. Each of those is a small fix, and together they are usually the highest-return work available on a charity website.

• Suggested amounts alongside a free-text option, with the default clearly editable
• A single page between amount and payment wherever regulations allow
• Payment methods that match where supporters are, including mobile wallets
• A regular-giving option, which most charities under-use because it is easy to overlook
• No donation prompts above the content on a page someone came to read

Supporter data is valuable and easy to lose

Supporter records accumulate across a CRM, event spreadsheets, email platforms and inboxes, and every duplicate is a privacy problem as well as an operational one. Consolidating that data, agreeing what the organisation genuinely needs to keep, and putting in place a defensible deletion process usually takes less work than expected and improves the experience for supporters who are asked for the same information twice.

Consent has to be specific and recorded. A general permission to be emailed is not the same as permission for a particular campaign, and the record should be retrievable years later when someone asks what they agreed to.

Volunteer coordination is usually a spreadsheet

For most charities, volunteer coordination is one person with a spreadsheet and a lot of goodwill. The work is real: matching people to opportunities, tracking availability and hours, sending reminders, confirming attendance and recording what was done. A modest system that handles sign-up, scheduling, notifications and hour records removes the administrative load and produces the evidence that funders increasingly ask for.

The design constraint is that volunteers are not staff. They use a phone, they are not trained on internal systems, and they often have one task. That argues for very few fields, clear instructions, and reminders that arrive at a useful time rather than a stream of them.

Reporting for funders and boards

Impact reporting is usually assembled by hand from several systems, and it is the part of charity technology that creates the most work for the least visible benefit. Activity and outcome data collected during normal operations, rather than reconstructed afterwards, makes reporting a matter of formatting rather than archaeology. We are careful to present only what the organisation can actually evidence, since an unsupported figure in a funder report is a serious problem rather than a small one.

Working with a small team

The most common cause of failure in charity technology is a system that only one person understands. We design for that: fewer features, a content model the communications team can manage, plain-language documentation, and a handover session with the people who will actually run it. We are also honest about what not to build. A small organisation is usually better served by a well-configured existing platform with a focused improvement than by a bespoke system that needs a developer for every change.

Getting started

Start with the journey that matters most to the organisation, usually either giving or volunteering, and look at where people currently get stuck. That is a small enough project to scope honestly and usually produces a visible result. We have written about donation journeys and accessible design in the Insights section, and you can get in touch to talk it through.

Most businesses do not have a technology problem to begin with

When an organisation outside the usual categories describes its difficulties, the symptoms are recognisable. One person knows how the process really works. A spreadsheet does a job nobody intended it to do and fails quietly. Enquiries sit in inboxes with no shared status. Reporting takes a week and cannot be produced on request. Software was bought some years ago by someone who has since left.

None of that is fixed by buying a platform. It is fixed by understanding the work first, agreeing what should change, and then removing the manual steps one at a time. That approach is slower to start and considerably faster to finish than the alternative, because it avoids building a system nobody wanted.

Follow the work, not the department

Organisational charts rarely match how the work actually flows. The fastest way to find the real constraints is to follow one piece of work end to end and write down every step: who does it, what they are looking at, what they copy from where, and where it breaks. Done properly for two or three representative pieces of work, that exercise identifies most of the worthwhile changes and removes the guesswork from what to build first.

The output is usually unglamorous. Cleaning a data source. Removing a duplicate entry point. Making a status visible. Automating a message that currently gets sent by hand every Friday. These produce more reliable improvement than a new front end, and they are quick to prove.

Fewer systems, used properly

Every system in use costs maintenance, and most organisations carry more than they need. Consolidating where two tools do the same job, or where a heavyweight system handles a process that a simpler tool manages better, is usually more valuable than adding anything. The test is whether a member of staff can do their job well with the system in front of them, not how many systems appear on a diagram.

When something genuinely needs to be built, we keep it small. A focused internal tool that one team uses every day is easier to justify, easier to maintain and easier to hand over than a platform intended to serve every department, and it can grow into the rest if it proves useful.

Making the digital basics reliable

For a lot of organisations the highest-value work is not new software but fixing what is already there. A website that loads quickly on a phone, works with a keyboard and a screen reader, and gives a visitor a clear way to make contact. Email that arrives, DNS and hosting that stay up, backups that have been tested by restoring one, and monitoring that alerts a human when something breaks rather than logging it quietly.

• A clear, accessible website that explains what the business does and how to reach it
• Managed hosting with monitoring, backups and a tested restore
• A shared enquiry and order record instead of separate inboxes
• Documented processes for the work that currently depends on memory
• A maintenance plan that names who does what and how often

What we would tell you first

If we were reviewing a business in this position, we would want to see: how work arrives and what happens to it, the systems it passes through, the reports that get produced and how long they take, and the tasks that people describe as a nuisance. Those four things usually contain the whole answer, and the first project usually turns out to be smaller than the organisation feared.

Getting started

There is no advantage in waiting until the requirement is fully defined. A short conversation and a look at the current systems is enough to identify a sensible first step, and you are welcome to bring a problem rather than a brief. You can read how we work in the Insights section, or get in touch to arrange it.