Apps your customers will actually use
Most business apps fail for boring reasons: they are slow on the phone the customer actually owns, they break on bad signal, or nobody could find them. We build for those conditions first.
An app is not a success because it launched. It is a success because people open it twice. That sounds obvious, and it is still where most business apps fall over - built for a demo on office wi-fi and a new device, then shipped to customers on three-year-old phones with two bars of signal.
We build web and mobile apps that hold up under real conditions. That means performance as a requirement rather than an afterthought, offline and poor-connection behaviour designed rather than discovered, and accessibility built in because a meaningful share of your customers need it and the law increasingly requires it.
Web app, native app, or progressive web app?
This is the first decision and the one most often made for the wrong reasons. The answer depends on what the app has to do with the device, how users will find it, and whether you want to be inside an app store relationship at all.
Here is how we actually decide:
| Approach | Choose it when | The trade-off |
|---|---|---|
| Web app | Users arrive from a link, search or email; you need instant updates and no install friction | Limited access to deep device features; no app store presence |
| Progressive web app | You want an icon on the home screen, offline use and push, without app store review | Some iOS limitations; users need prompting to install |
| Native or cross-platform | You need camera, Bluetooth, background location or heavy offline sync | App store review cycles, two platforms to maintain, slower releases |
Performance is a feature, not a polish step
Speed is the single most under-rated feature in business software. It changes whether people finish a booking, whether your team uses the tool you paid for, and whether Google shows you to anyone. Core Web Vitals are a ranking factor, but more importantly they are a decent proxy for whether the thing feels good to use.
We set a performance budget at the start and hold to it, rather than measuring at the end and discovering the problem is architectural. In practice that means server rendering where it helps, sending as little JavaScript as the job needs, images sized and served properly, and fonts that don't block the page.
Budgets up front
Agreed targets for load and interaction before any code is written, so performance is a constraint rather than a wish.
Tested on real conditions
Mid-range devices and throttled connections, because that is what your customers are on.
Server-rendered where it matters
Content that needs to be indexed and fast on first load is rendered on the server, not assembled in the browser.
Measured after launch
Field data from real users, not just a lab score on launch day.
Apps that search engines and AI assistants can read
A lot of app frameworks produce pages that look fine to a person and are close to empty to a crawler. If any part of your app should bring in customers - a public listing, a service area, a product page, a booking flow - it has to be server-rendered with real content in the HTML.
The same is now true for AI assistants. When someone asks ChatGPT or Perplexity to recommend a supplier, those systems read the page the same way a crawler does. Content buried behind JavaScript is content that doesn't exist to them. We build the public surface of an app so that both can read it, and we structure the data so it can be quoted accurately.
Accessibility, because it is the right call and the legal one
Around one in five people has a condition that affects how they use software. Building for them is not charity - it is a straightforward widening of who can become your customer, and it usually improves the experience for everyone else too. Keyboard navigation, sensible contrast and clear focus states make an app better to use in a van, in bright sunlight, or one-handed.
It is also increasingly a legal requirement rather than a nice-to-have, in both the UK and the US. We build to WCAG 2.2 AA as standard rather than treating it as an extra line item, because retrofitting accessibility costs several times what building it in does.
Deliverables
Every engagement includes these as standard, not as line items to negotiate.
- A recommendation on web, PWA or native with the reasoning written down
- Agreed performance budgets, measured before and after launch
- WCAG 2.2 AA accessibility as standard
- Server-rendered public pages that search engines and AI assistants can read
- Analytics that answer real questions rather than vanity dashboards
- App store submission and release handling where relevant
Where we have done this
NearOps
Service businesses run their bookings, dispatch, payments and payouts through NearOps under their own brand. Matching engineers to jobs by coverage area rather than a radius is the part that turned out to be hard.
Read the case studyJF Automotive
For an automotive business, almost every enquiry starts with the same question - what car have you got? Answering it on the page instead of in an email changes the whole conversation.
Read the case studyQuestions people actually ask
Do I need a native app or is a web app enough?
Most business apps don't need to be native. If your users arrive from a link, an email or a search result, a fast web app removes all the install friction and lets you ship updates the same day. Native earns its cost when you genuinely need deep device features - background location, Bluetooth hardware, heavy offline sync. We'll tell you which one your project actually needs before you commit to the more expensive path.
How do you make sure the app is fast?
We agree performance budgets before writing code and treat them as a constraint, which is very different from measuring at the end and trying to optimise your way out of an architectural problem. Practically that means server rendering where it helps, minimal JavaScript, properly handled images and fonts, and testing on mid-range devices and throttled connections rather than a new phone on office wi-fi.
Will my app show up on Google?
Only if its public pages are server-rendered with real content in the HTML, which many app frameworks don't do by default. We build the public surface so crawlers and AI assistants can read it properly, with structured data so the content can be quoted accurately. Pages behind a login are a different matter and are deliberately kept out of the index.
Can you take over an existing app?
Often, yes. We start with a short technical review of the codebase, dependencies and infrastructure, and give you an honest assessment - including the case for a rebuild if that is genuinely cheaper than continuing. Inheriting someone else is normal work and we would rather tell you the truth about what you have than sell you the more profitable option.
What about app store approval?
We handle submission and the review process for both Apple and Google, including the parts that catch people out - privacy declarations, data-use disclosures, account deletion requirements and screenshots at the right sizes. Review timelines are outside anyone's control, so we plan releases with that built in rather than promising a launch date the stores have to agree to.
Where to go next
Custom Software
Most businesses outgrow their tools long before they replace them. Custom software is what you build when the spreadsheet, the shared inbox and three subscriptions have quietly become the process.
Websites with Built-in Software
Most business websites are a brochure with a contact form. The ones that earn their keep let the customer do something - book, get a price, look something up, check a status.
Software for Field Service and Trades
Field service has a problem office software never solves: the work is at the customer, the person doing it is in a van, and the signal is unreliable.
Tell us what is slowing you down
A short conversation is usually enough for us to tell you what it would take to fix it, and what it would cost you to leave it alone.