Custom Web & Mobile Apps

Buy it first, if you can

Most requests for custom software start in the same place. Someone in the business has a job that keeps going wrong — quotes assembled by hand, a schedule that lives in one person’s head, customers emailing to ask what an order is doing — and somewhere along the way they decided the answer was an app.

Sometimes it is. Often the honest first answer is a product you can subscribe to. Booking systems, CRMs, form builders, help desks and the Shopify App Store between them cover a great deal of what small and growing businesses describe to us, for a monthly fee smaller than a week of development. Owning software means owning its maintenance for as long as you rely on it, and that cost does not appear on the first invoice.

So the first conversation is about the job, not the build. What has to happen, who does it, how often, and what it has to connect to. If an existing product does most of it, we will say so and name it. Custom software earns its cost when the missing part is the part your business actually competes on — the quoting logic nobody else has, the process that makes your service better than the next one — or when the subscriptions needed to approximate it would cost more each year than the thing itself.

What we build

Four shapes cover most of the work.

Web applications are browser-based software that does a specific job: a quoting tool, a booking flow, a configurator, a marketplace for a niche. They are the right shape for most first builds, because there is nothing to install and no store review between you and your users.

Customer portals give your customers a login and somewhere to find their own orders, documents, bookings and history. Done properly, a portal removes a category of email rather than adding a channel.

Internal tools and admin dashboards are the screens your team works in all day. They usually replace a spreadsheet, and the measure of success is that nobody opens the spreadsheet again.

Mobile apps are for work that happens away from a desk, or for customers who will open the thing several times a week. We build iOS and Android together, React Native by default, and publish under your own developer accounts.

Underneath all four sits an API, and usually integrations: into a Shopify store, a WordPress site, a payment provider, a CRM or an accounting system. That connective work is often most of the value, and it is scoped as its own item rather than hidden inside “build”.

Web app, mobile app, or both

Start with a web app unless there is a reason not to. It runs on every phone, tablet and laptop with a browser, it updates the moment you deploy, and it does not wait on Apple or Google to approve a change.

The reasons not to are real ones. The people using it are in vans, on site or on a shop floor, sometimes without signal. They need the camera, location or push notifications. They will open it many times a day and expect it to be one tap away. Any of those points towards a mobile app, and none of them is “it would be nice to be in the App Store”.

Many businesses end up needing both. The way to make that cheap later is to design the API properly for the first one, so the second is a new front end on a back end that already exists rather than a second project.

The stack, and why it is deliberately unremarkable

On the web we build in React and Next.js, in TypeScript. On mobile, React Native by default — one codebase for iOS and Android, sharing language, patterns and often code with the web app, with native modules where a device feature needs them. Where a business already runs on .NET, we build the back end in ASP.NET rather than handing your team a second stack to support.

None of these is a fashionable choice, and that is the point. They are widely used, well documented and easy to hire for, which matters more than anything else on the day you want another team, or your own, to pick the software up. An application built on an obscure framework is an application with one possible maintainer.

How a build runs

The specification is written down and approved before application code is written. It names the screens, the user roles, the data model, the integrations and the acceptance criteria, with a clickable prototype of the core flow. That prototype is where most misunderstandings surface, and they are far cheaper to fix there than in code.

The build is billed in milestones, each against something you can use. You get a working link, or a test build on your own phone, in the first milestone. It will be incomplete. It is still the most reliable way to discover that the requirement everyone agreed on is not quite the requirement the business has.

Before launch, the people who will use the software every day work through it on real data and real devices. Then it goes live: a production deployment for the web, and App Store and Google Play submission for mobile, review correspondence included.

After launch, and who owns it

Software does not stay finished. Apple and Google ship new operating systems every year, Google Play raises the Android version that updates must target, browsers change, and every library underneath the app releases security fixes. We track the changes that touch your software and tell you before they break it, on a retainer or by the hour.

And it is yours throughout. The source sits in your repository from the first commit, the hosting is in your name, the apps are in your developer accounts, and the runbook explains how to deploy, roll back and restore. If you take it in-house or hand it to someone else, there is nothing to extract and nothing to negotiate.