Web applications and integrations

A website shows people information. A web application lets them do something: log in, book, search, configure, submit, see what’s theirs. Most businesses need a bit of both, and the line matters mostly because they’re priced and built differently. If someone has to be logged in for it to make sense, it’s an application.

That’s the starting assumption. We build against what you already run on, whether that’s a CRM, a booking system, a finance package or something built for you years ago. Replacing it is a last resort rather than the opening suggestion, and if it genuinely can’t do what you need, we’ll tell you in week one rather than year three.

Fairly common, and usually still solvable. There’s normally a scheduled export, a database view or a middleware route that gets you most of the way. What we won’t do is build something fragile and let you find out later, so if the only honest answer is that it can’t be connected properly, that’s what you’ll get.

Quoted per project, because the range is enormous. A listings feed that populates itself is a different job from a member portal with logins and permissions. What we can do quickly is tell you roughly which end of the range you’re at, before anyone writes a specification.

You own it. Documented, handed over, on your hosting, with no licence back to us. If you want another developer to take it on later, they can, and they’ll be able to read what’s there. We’d rather you stayed because it’s working than because leaving is difficult.

The site keeps working. Every connection is built with a plan for the day the other end stops answering, so a page shows the last known good version or a sensible message rather than an error. Integrations that assume both ends are always up are the ones that embarrass people.