Web Application Development

Website or web application?

A website mostly shows the same content to everyone: pages, posts, products. A web application does work for the person using it. People log in, see their own data, change it, and the system reacts: it sends an email, updates a record, calculates a quote or notifies someone on your team.

The line is not always sharp. A WordPress site with a members area is part website, part application. A useful test: if the most important screens are different for every user, or the system has to follow your business rules (who approves what, what happens when an order arrives), you are building an application, and it deserves to be designed as one rather than bolted onto a website with plugins.

If what you need is mainly a marketing site, see website development instead.

What we build

• Customer portals and member areas: a place where your customers log in to see orders, documents, bookings or account details, instead of emailing you for them.
• Internal tools and admin dashboards: replacing the spreadsheet that five people edit at once with a proper tool that has roles, history and validation.
• Lead capture and quote forms: multi-step forms that calculate a price or qualify a lead, connected to your CRM or email platform.
• Automations: connecting the tools you already use (forms, email, CRMs, spreadsheets, payment providers) so that data moves between them without someone copying and pasting.
• Status pages, monitoring and reporting: one screen that shows what is happening across your systems, with alerts when something needs attention.

Technology we use

We pick proven, widely used tools so that your application is not tied to us or to a niche framework:

• Front end: React and Next.js for interactive interfaces that work in any modern browser, on desktop and phone.
• Back end: Node.js and PHP, exposing REST APIs that the front end (and later a mobile app or a partner system) can use.
• Data: SQL databases for anything that must stay consistent, such as customers, orders and money.
• Integrations: the APIs of the services you already pay for, rather than rebuilding what they do.

Building the back end as an API from day one has a practical benefit: if you later want a mobile app, it can talk to the same API. See mobile app development and our guide Mobile app or web app? How to decide.

Start small: the first version

Most software projects that go wrong do so by trying to build everything at once. We work the other way round: find the one workflow that saves the most time or earns the most money, build that first, and put it in front of real users early.

A good first version:

• Solves one problem completely, rather than five problems halfway.
• Is used by real people for their real work within weeks, not months.
• Is built on a foundation (data model, user accounts, API) that later features can grow on.
• Gives you evidence for what to build next: what people use, where they get stuck, what they ask for.

After that, we extend it in small, regular releases based on what users actually do.

Security and data

A web application usually holds information about your customers and your business, so security is part of the design, not a final checklist. We use the OWASP Top 10, the standard list of the most common web application security risks, as a baseline. In practice that means:

• Access control checked on the server for every request, so a user can only see and change what they are allowed to.
• Passwords stored with modern hashing, and sign-in protected against guessing.
• All input validated and all database queries parameterised, which closes off injection attacks.
• Encrypted connections (HTTPS) everywhere, and secrets such as API keys kept out of the code.
• Dependencies kept up to date, and only the personal data you actually need collected and kept.
• Regular backups, tested by restoring them.

How the project runs

1. Discovery: we map the workflow as it works today, who is involved, and where time or money is lost.
2. Scope the first version: agree the one workflow to build first and what "done" means for it.
3. Design: the key screens, clicked through as a prototype before code is written.
4. Build in short cycles: working software you can try on a staging environment every week or two, not a big reveal at the end.
5. Launch: data imported from spreadsheets or the old system, users invited, and support close at hand for the first weeks.
6. Iterate: the next features chosen from real usage.

Hosting and running the application

We run the applications we build on servers we manage, with monitoring, backups and security updates handled for you. That means one team is responsible for the code and the place it runs, so when something goes wrong there is no finger-pointing between a developer and a host. If you would rather run it on your own cloud account, we can talk that through during discovery.

Frequently asked questions

Should we use an off-the-shelf tool instead?

Often, yes. If a mainstream product does what you need, it is usually cheaper than building your own. Custom software makes sense when your process is what sets you apart, when you are paying for several tools and gluing them together by hand, or when no product fits without awkward workarounds. We will tell you if an existing tool would do.

Can you connect the application to the tools we already use?

Usually, as long as the tool has an API or an export. Most CRMs, email platforms, payment providers, accounting packages and spreadsheet tools do. We check the specific tools during discovery before promising an integration.

Can you take over an application someone else built?

Yes. We start with a review of the code, the hosting, the data and the security, then tell you plainly what is sound, what is risky and what we would change first. Sometimes the answer is to keep it and improve it step by step; sometimes it is to rebuild one part at a time.

Who owns the code?

Code ownership and licensing should be agreed in writing before any work starts, whoever builds it; make sure it is in the proposal so there are no surprises later. Building on widely known open-source tools also means another team could pick the application up if they ever needed to.

Will it work on phones?

Yes. We design web applications to work in mobile browsers as well as on desktop. For many tools that is enough; when you need push notifications, offline use or device hardware, a native or cross-platform app can be added on top of the same API.